TestContainersでデータベースをサクッと立ち上げる。
LocalStackでAWSサービスをローカルで再現する。
現代のJava開発では、こうした便利なツールが当たり前になっています。
でも、実際の現場は違いました。
ある開発者が銀行のプロジェクトで経験した現実があります。
仮想デスクトップ経由でしか開発環境にアクセスできません。
Dockerは完全に禁止されています。
しかも開発環境は全チームで共有という状況です。
これ、実はレアケースではないんです。
なぜDockerが禁止されるのか
「セキュリティのため」と一言で片付けられがちです。
しかし、理由はもっと複雑なのです。
まず、IT部門の管理外でソフトウェアが動くことへの懸念があります。
開発者が自由にコンテナイメージをダウンロードできる環境。
それは管理者にとって悪夢でしょう。
どんなソフトウェアが動いているか把握できないからです。
次に、仮想デスクトップ内での仮想化の問題があります。
技術的には入れ子の仮想化（nested virtualization）と呼ばれる構成です。
この構成では、パフォーマンスが劇的に低下します。
そもそも多くの仮想デスクトップ環境では、この機能自体が無効化されています。
さらに、Docker Desktopの有料化も影響しています。
250人以上の従業員がいる企業では、有料ライセンスが必要です。
「たかが開発ツールにお金を払うの？」という上層部の反応は、想像に難くありません。
共有開発環境という別の問題
Dockerが使えないだけでも厳しい状況です。
それなのに、開発環境を全員で共有するという追い打ち。
誰かがデータベースのスキーマを変更したら、他の開発者のテストが軒並み失敗します。
ある開発者はこう述べています。
「朝出社したら、昨日まで動いていたコードが動かない。調べてみたら、別チームが共有データベースの設定を変更していた」と。
これではテストの信頼性も保てません。
CIパイプラインで自動テストを実行しても、環境の状態によって結果が変わってしまうのです。
実は一般的な光景
Quarkusの開発チームによると、問い合わせがよく来るそうです。
「Dockerが使えないからQuarkusは使えない」という内容です。
実際にはDockerなしでも動作します。
しかし、それほど多くの企業で同じ制限があるということでしょう。
金融機関や政府機関では特に顕著です。
これらの組織では、次のような制限が一般的に存在します。
内部Mavenリポジトリからしか依存関係を取得できない
新しいライブラリが必要なら、申請書を提出します。
そして承認を待つ必要があります。
場合によっては数週間かかることも。
管理者権限なしでソフトウェアをインストールできない
開発に必要なツールであっても、IT部門の承認と作業が必要です。
外部サービスへのアクセスが厳しく制限される
Maven Centralへの直接アクセスすら許可されないケースもあります。
開発者はどう対処しているか
制限があっても開発は続けなければなりません。
現場の開発者たちは様々な工夫をしています。
リモートDockerの活用
これが一つの解決策です。
開発者のローカルマシンから、ネットワーク経由で別のサーバー上のDockerを操作します。
ただし、これもネットワークポリシーで制限されることが多いです。
Podmanへの切り替え
Dockerとは異なる実装のコンテナランタイムです。
デーモンレスで動作するため、セキュリティ面での懸念が少ないとされています。
とはいえ、「仮想化禁止」という大きな壁の前では無力です。
モックやスタブの徹底活用
原始的な方法に戻る開発者もいます。
データベースやメッセージキューなど、外部サービスとの連携部分をすべてモックで置き換えるのです。
TestContainersの便利さを知っている開発者にとっては、時代を逆行しているように感じるでしょう。
内部リポジトリの功罪
すべてのライブラリを内部リポジトリ経由で取得する仕組み。
実は、これ自体は理にかなっています。
オープンソースのインフラへの負荷を軽減できる
最近、Maven Central、npm、PyPIなど主要なパッケージリポジトリが共同で声明を発表しました。
企業は自前のキャッシュサーバーを用意すべきだと。
セキュリティの観点でも重要
悪意のあるパッケージが紛れ込むリスクを軽減できます。
そして、使用しているライブラリのバージョンを組織全体で管理できます。
問題は承認プロセスの硬直性です。
「MITライセンスのライブラリなのに、エンタープライズ版が存在するから使用禁止」といった理不尽な判断。
これに遭遇した開発者もいます。
IT部門がライセンスを正しく理解していないケースです。
生産性への影響
こうした制限は確実に生産性を低下させています。
ローカルでの統合テストが実行できない
データベースやメッセージキューを含む実際の環境でのテスト。
これは共有環境でしか行えません。
環境構築に時間がかかる
新しい開発者が参加するたびに、環境設定で数日を費やすことになります。
デバッグが困難になる
問題が発生しても、切り分けが難しくなります。
自分のコードなのか。
他チームの変更なのか。
それとも環境の問題なのか。
これからの展望
企業のセキュリティ要件と開発者の生産性。
このバランスを取る必要があります。
完全に自由な環境は確かにリスクです。
しかし、過度な制限は競争力の低下を招きます。
一部の先進的な企業では、変化が始まっています。
開発者向けに隔離されたサンドボックス環境を提供し始めているのです。
そこではDockerも自由に使えます。
ただし、本番環境とは完全に分離されています。
クラウドベースの開発環境も選択肢の一つです。
GitHub CodespacesやGitpodのようなサービスがあります。
これらを使えば、ブラウザ上で完全な開発環境を利用できます。
ただし、これも「外部サービス禁止」の壁にぶつかることがあります。
まとめ
Dockerが使えない開発環境。
これは思っているより一般的です。
特に金融機関や政府機関では、セキュリティとコンプライアンスの観点から厳しい制限が設けられています。
開発者にとっては苦痛です。
しかし、組織のリスク管理の観点では理解できる部分もあります。
問題は、セキュリティを理由にした思考停止的な制限です。
技術的な代替手段は存在します。
Podman、リモートDocker、徹底したモック化など。
しかし、根本的な解決には、IT部門と開発部門の対話が必要でしょう。
「セキュリティか生産性か」という二者択一ではありません。
両立する方法を模索する。
それが、これからの企業IT部門に求められる姿勢ではないでしょうか。
制限だらけの環境で苦労している開発者の皆さん。
あなたは一人じゃありません。
世界中の多くの開発者が同じ状況で戦っています。
そして少しずつですが、状況は改善されつつあります。
諦めずに、より良い開発環境を求めて声を上げ続けましょう。
