※本記事は、AWS re:Invent 2024のライトニングトーク「The enterprise development environment (DOP109)」の内容を基に作成されています。このプレゼンテーションは、AWSパートナーであるCoderによって提供されました。

登壇者： Ben氏 - Coderのプロダクトマネージャー。ソフトウェア開発への深い愛着を持ち、エンタープライズソフトウェア開発エコシステムに携わってきた経験を持つ。現在はCoderで4年以上にわたりプロダクト開発を主導し、大規模企業の開発環境の標準化と効率化に貢献している。

本記事では、プレゼンテーションの内容を要約・構造化しております。なお、本記事の内容は発表者の見解を正確に反映するよう努めていますが、要約や解釈による誤りがある可能性もありますので、より詳細な情報については、AWS re:Inventの公式サイト（https://go.aws/reinvent ）をご参照ください。また、AWSの他のイベント情報は https://go.aws/3kss9CP でご確認いただけます。

1. 現状の開発環境の課題

1.1. 従来のDevOpsライフサイクルと境界

私はCoderのプロダクトマネージャーのBenです。本日は、エンタープライズ開発環境とその課題、そして私たちの取り組みについてお話しします。

まず、会場の皆さんに伺いたいと思います。皆さんの組織で、アプリケーションがどのようにデプロイされているか理解している方はどのくらいいらっしゃいますか？これはパイプライン、承認プロセス、サーバーアーキテクチャなどを含みます。DevOpsライフサイクルの中でも、比較的シンプルな部分です。

さらに、アプリケーションが実際にどのように開発されているか理解している方はどのくらいいらっしゃいますか？これは開発者が毎日使用するツール、使用している言語、プルリクエストのワークフローなど、開発者が日々行っている作業全般を指します。

典型的な開発ワークフローは以下のようになっています：開発者はオフィスのPC、リモートラップトップ、または仮想デスクトップ上でコーディングを行い、Gitリポジトリにチェックインします。その後、CI/CDパイプラインを通じてクラウド環境にデプロイされます。

このワークフローの中で重要な点は、クラウドプロバイダーの境界線の存在です。この境界線の内側では、セキュリティスキャン、インフラのコード化、ガバナンスポリシー、そしてプロダクション準備状態を確認するためのテストスイートなど、様々なベストプラクティスを適用することができます。しかし、開発者のワークステーションは、この境界線の外側にあり、完全に別個のセキュリティ管理とエンドポイント管理が必要となります。ITチームは、エンドポイント管理や仮想デスクトップの管理など、クラウドプロバイダーとは異なる一連の手順で対応する必要があるのです。

1.2. 環境の分散化と複雑性

実際の企業環境では、開発環境は非常に断片化され複雑化しています。多くの場合、これは完全な「Wild West（無法地帯）」の状態です。

開発者のグループごとに異なるマシン環境が存在します。Windowsマシン、Intel搭載のMac、M1/M2/M3搭載のMacなど、ハードウェアプラットフォームは多岐にわたります。また、契約開発者は仮想デスクトップを使用して接続し、BYODモデルも存在します。さらに、一部の開発者は組織のAWSアカウント上にVMをプロビジョニングし、ローカルマシンがロックダウンされているため、そのVMに毎日接続して開発作業を行っています。

開発ツールの多様性も大きな課題です。Java開発ではIntelliJが好まれ、現在最も主流なエディタはVS Codeです。また、Eclipseや.NET開発向けのVisual Studioなどのレガシーエディタも依然として使用されています。これらのエディタは、クラウドにデプロイする一部のコンポーネントやデスクトップアプリケーションの開発に必要不可欠です。

さらに、開発者はローカルワークフローの中でクラウドサービスに接続する必要があります。データベースへのアクセス、シークレットの管理、パイプラインとの連携など、様々なクラウドサービスとの接続が必要です。

開発者ツールのエコシステムも複雑です。GitHub Copilot、Amazon Q、そして実際の開発に使用するPythonやJavaなど、開発者が日々使用するツールのサポートが必要です。プラットフォームエンジニアやITマネージャーにとって、これらの設定の組み合わせをサポートすることは非常に困難です。これほど多くの異なるツール、エディタ、クラウドワークスペースへの接続、そしてIDE拡張機能をサポートしなければならない状況では、理想的な開発パスを作成することはほぼ不可能なのです。

1.3. 標準化された環境の問題点

一方で、開発環境の標準化に取り組んでいる組織もありますが、そこにも大きな問題があります。多くの場合、標準化された環境は仮想デスクトップを採用していますが、これには重大な制限があります。

最も深刻な問題は、開発者が標準化された仮想デスクトップ上でモダンなクラウドネイティブワークロードを実行できないことです。また、開発者が様々な地域から接続する場合、低レイテンシーの問題が発生し、開発作業の効率を著しく低下させています。

さらに、開発者が新しいツールをインストールする必要がある場合、大きな課題が生じます。GitHub Copilot、Docker、Amazon Qなど、どのようなツールであっても、IT部門へのチケット申請が必要となります。この手続きには時間がかかり、クラウドネイティブワークフローの他の部分から完全に切り離されています。これは開発者の生産性を著しく低下させる要因となっています。

このように、環境の標準化自体は正しい方向性ですが、現在の仮想デスクトップを中心とした標準化アプローチでは、開発者の生産性とクラウドネイティブな開発スタイルの両立が困難な状況になっているのです。

2. クラウド開発環境の概要

2.1. 基本アーキテクチャ

これらの課題に対応するため、クラウド開発環境という新しいアプローチを導入します。このアプローチでは、ワークステーションは接続のためだけに必要となり、実際のコーディングはクラウド開発環境上で行われます。この環境では、ステージング、テスト、本番環境で使用されているのと同じツールとガバナンスを適用することができます。

クラウド開発環境の基本アーキテクチャは、シンプルながら効果的な構成となっています。主要なコンポーネントは以下の2つです：

1. エフェメラルコンテナ： 開発者が使用するツール（Python、Java、Docker等）が含まれたコンテナです。このコンテナは一時的なものであり、必要に応じて作成・破棄することができます。
2. パーシステントディスク： 開発者のパーソナライズ設定とソースコードを保存する永続的なストレージです。

このアーキテクチャは、Gitプロバイダーと統合されており、パイプラインへのコードの受け渡しがスムーズに行えます。また、コンテナレジストリとも連携しており、開発環境の一貫性を保つことができます。

重要な点は、このアプローチにより、セキュリティスキャン、ポリシー、コンテナレジストリなど、本番環境でのデプロイに使用している既存のクラウドネイティブパターンを開発環境にも適用できることです。これにより、特定のツールをインストールするためにIT部門と調整する必要がなくなります。なぜなら、すでにDockerアプリケーションやEKSへのデプロイのための自動化が確立されているからです。

2.2. クラウド開発環境の制限（20%の開発者のみ対応）

クラウド開発環境のモデルは、一見シンプルで効果的に見えますが、実際には重大な制限があります。私たちCoderでは、この基本的なクラウド開発環境のモデルが、G2K（グローバル2000社）の組織において、実際には20%の開発者にしか対応できていないという事実を発見しました。

一見すると、すべての開発者がコンテナベースの環境にすぐに移行できるように思えるかもしれません。しかし、実際にはそうではありません。特に大きな課題となっているのが、モノレポ（モノリシックリポジトリ）で作業を行う開発者への対応です。モノレポの規模や複雑性により、コンテナ環境での効率的な開発が困難になっています。

また、デスクトップアプリケーションの開発者も大きな制約に直面しています。クラウド開発環境では、デスクトップアプリケーションの開発に必要な特殊な要件や、ローカル環境との密接な連携が必要なケースに対応することが困難です。

さらに、多くの企業が保有するオンプレミスのシステムやサービスとの統合も重要な課題です。開発者は既存のオンプレミスインスタンスと連携する必要があり、これはクラウド開発環境の標準的なモデルでは十分にサポートできていません。

これらの制限により、クラウド開発環境は単独のソリューションとしては不十分であり、より包括的なアプローチが必要とされています。

2.3. エンタープライズ開発環境への進化

これらの課題に対応するため、私たちはエンタープライズ開発環境という、より包括的なアプローチを提案しています。クラウド開発環境の基本的なコンポーネント（コンテナとディスク）は維持しつつ、より広範な統合と機能を提供します。

シークレット管理は重要な要素です。開発者は作業中にシークレットにアクセスし、クラウドAPIと通信する必要があります。これには、OpenAIのAPIキーや内部のアプリケーションゲートウェイとの通信に必要な認証情報が含まれます。これらのリソースは、開発者のためにコンテナとディスクと共にプロビジョニングされ、開発者が退職した際には適切にデプロビジョニングされる必要があります。

VMサポートも重要な要素です。私たちの経験では、モノレポで作業する多くのユーザーが、コンテナよりもVMを好んで使用しています。VMは適切に分離され、起動と停止が容易です。また、毎日のVM停止やナイトリーパッチの適用などのコスト削減機能により、クラウド開発環境に適したアプローチとなっています。

MLエンジニアのためのリモートデータセットへのアクセスも重要です。開発者はローカルマシンでトレーニングを実行する必要がなく、セキュリティ運用チームとしても、クラウドから開発者のワークスペースへのデータ移動を制限できます。

Windows環境のサポートも不可欠です。特にQA目的でWindowsへのアクセスが必要なケースが多く見られます。私たちは、オンプレミスでのCoderの展開やAIアシスタントの実装においても、この要求を頻繁に目にしています。

最後に重要な点として、2025年においては、コードを書くのはソフトウェアエンジニアだけではありません。典型的なソフトウェア開発ライフサイクルは素晴らしいものですが、データサイエンティスト、外部契約者、MLエンジニア、アナリスト、クオント、DevOpsなど、他にも多くのライフサイクルが存在します。エンタープライズ開発環境は、典型的なソフトウェア開発ライフサイクルだけでなく、MLOpsワークフローなども含めた、より広範なニーズに対応する必要があると考えています。

3. 顧客プロファイルと知見

3.1. クラウドネイティブ技術企業（例：Netflix）

Coderでの4年間の経験を通じて、私は2つの異なる顧客プロファイルと協働する機会を得ました。単純化のため、まずクラウドネイティブ技術企業について説明します。

Netflixのような企業は、すでにある程度クラウド開発環境に類似したものを独自に構築・運用していました。しかし、彼らはもはやホイールを再発明したくないと考え、Coderのようなプラットフォームに移行を決断しました。

これらの企業の特徴的なアプローチは、モノレポでの開発スタイルです。大規模なモノリシックリポジトリを使用して開発を行っており、各開発者にVMを提供する方式を採用しています。彼らが独自の開発環境からCoderに移行を決めた背景には、環境管理の効率化と標準化への要求がありました。

既存の開発環境からの移行は慎重に行われ、VMを基盤とした環境を提供することで、モノレポでの開発に必要な計算リソースと柔軟性を確保しています。この移行パターンは、特に大規模なコードベースを持つ企業にとって効果的であることが分かっています。

3.2. 規制対象企業の要件

2つ目の顧客プロファイルは規制対象企業です。これらの企業はクラウドネイティブ技術企業とは異なる要件を持っていますが、クラウド開発環境の柔軟性からは同様に恩恵を受けています。

これらの企業の最大の関心事はデータ主権です。開発環境をどこで運用するか、どのようにデータを管理するかについて、厳格な規制要件に従う必要があります。そのため、開発環境はエアギャップ環境で運用されるか、ゼロトラストクラウド環境で実装される必要があります。

一見すると、クラウドネイティブ企業と規制対象企業は正反対の要件を持っているように見えるかもしれません。しかし、実際には両者が必要とする要件には多くの共通点があります。特に、環境の一貫性、セキュリティ、そして開発者の生産性向上という点で、両者は同様の課題を抱えています。

私たちの経験では、クラウド開発環境の柔軟性は、これらの異なる要件に対応する上で大きな利点となっています。エアギャップ環境であっても、ゼロトラストクラウド環境であっても、基本的なアーキテクチャとワークフローを維持しながら、それぞれの規制要件に適合させることが可能です。

3.3. 4年間の経験から得られた導入パターン

過去4年間、私たちは開発環境の導入に関して多くの教訓を得てきました。特に、開発者のワークフロー変更を求めることは、非常に困難な課題であることが分かっています。

私たちは当初、いくつかのアプローチを間違った方法で試みましたが、現在では何が効果的かを理解しています。Coderでの経験を通じて、効果的な導入パターンを確立することができました。

まず第一に、開発者に対して一気に環境を変更することを求めるのではなく、段階的なアプローチが効果的です。クラウド開発環境の基本的なリファレンスアーキテクチャ（コンテナとディスク）を使用し、プラットフォームエンジニアとして、現在のデスクトップイメージに似た「ユニバーサルイメージ」を作成することから始めます。これは「one size fits most（ほとんどの人に合うサイズ）」というアプローチで、クラウド開発環境の魅力を示すことができます。

第二に、チームが独自の依存関係をプラットフォームに持ち込むことを許可し、Coderがそれらのライフサイクルを管理できるようにすることです。特にdevcontainer仕様は、ローカル開発や他のCDEプラットフォームを使用している人々にとって効果的です。

第三に、組織が追加のクラスターを自分たちのワークロードに取り入れたいというケースに対応できるようにしました。各チームが独自のクラスターやVMプールを持っている場合でも、Coderのプラットフォームでそれらをサポートできます。

最後に、コンテナ化されたワークフローでは一般的に考えられないような開発ケース（Windows開発、Android開発、Mac OS/iOS開発など）もサポートする必要性を認識しました。エンタープライズ開発環境は、あらゆる種類のソフトウェア開発をサポートする必要があるのです。

この4年間の経験を通じて、最も重要な教訓は、組織ごとに異なるニーズと要件を持っているものの、開発環境の標準化という共通の目標に向かって進んでいるということです。

4. エンタープライズ開発環境の実装戦略

4.1. ユニバーサルイメージの活用

シンプルに始めることが、クラウド開発環境導入の成功への鍵です。私たちは、最初のステップとして、クラウド開発環境の基本的なリファレンスアーキテクチャ（コンテナとディスク）を活用しています。

ユニバーサルイメージのアプローチは、現在のデスクトップイメージ管理と同様の考え方に基づいています。プラットフォームエンジニアとして、「one size fits most（ほとんどの人に合うサイズ）」のアプローチを採用し、クラウド開発環境の魅力を効果的にデモンストレーションすることができます。このアプローチでは、すべての開発者に対して、コードベースやワークフローの移行を要求することなく、クラウド開発環境の利点を示すことができます。

ユニバーサルイメージを作成する最良の方法は、開発者人口に対してサーベイを実施し、どのようなツールを使用しているかを把握することです。特に、ローカルでの使用が煩雑なツールは、クラウド開発環境への移行の動機付けとして効果的です。Python、Java、Docker、Goなど、開発者が日常的に使用するツールを含めることで、上司がプラットフォームにログインしてPythonスクリプトを書くような場合でも、すぐに使用できる環境を提供できます。

Microsoftが提供するdevcontainerイメージは、この取り組みの良い出発点となります。彼らは各人気言語向けのイメージを提供しており、これらを自社のレジストリに取り込み、組織固有のパターンに合わせて修正することができます。

4.2. 依存関係の自己管理（devcontainer仕様）

devcontainer仕様は、開発者が必要なプロジェクトと言語、ツールをGitリポジトリ内で指定できる効果的な方法です。この仕様を活用することで、開発者は自分たちのプロジェクトに必要な環境を宣言的に定義することができます。

具体的には、Gitリポジトリ内でdevcontainer.jsonファイルを作成し、そこにPython 3やJava 4などの必要な環境を指定します。このdevcontainer定義をCoderプラットフォームに取り込むことで、特定のユースケースや技術スタック向けの宣言的な開発環境を構築することができます。

この仕組みの重要なポイントは、組織のアーティファクト管理や脆弱性スキャンとの統合です。開発者に必要なツールの自己管理を許可しつつも、それらをアーティファクト管理システムから提供することで、不適切なバージョンの混入を防ぐことができます。これにより、開発者は必要なツールを自由に選択できる一方で、組織はセキュリティと一貫性を維持することができます。

このアプローチは、ローカル開発や他のCDEプラットフォームを使用している開発者にとって特に効果的です。devcontainer仕様は広く採用されており、開発者にとって馴染みやすい標準となっています。

4.3. マルチクラスター対応

2000ユーザー以上の大規模導入を実現している先進的なCoder利用組織では、複数のクラスターやプラットフォームチームを基本的なユースケース以外にも展開したいというニーズが出てきています。これは、特に大規模組織において重要な要件となっています。

典型的な例として、データサイエンス組織が独自のクラスターと名前空間を持ち、彼らのパイプラインに合わせた環境をプロビジョニングしたいというケースがあります。このような場合、組織の別のクラスターにCoderのプロビジョナーをインストールすることで、開発者は元々Coderで管理していたクラスターとは異なる場所に、ワンクリックで環境を構築することができます。

これは、開発環境と本番環境の一貫性を確保する上で非常に重要です。開発者が使用する環境を、ステージング、テスト、本番、QAなど、他の環境と同じ場所にプロビジョニングすることで、環境間の一貫性を維持することができます。私たちはこのアプローチを通じて、組織全体での開発プラクティスの標準化を実現しています。

このマルチクラスター対応は、特にデータサイエンスチームのような特殊な要件を持つグループに対して効果的です。彼らは独自のリソース要件やセキュリティポリシーを持っていることが多く、専用クラスターの提供によってそれらの要件に適切に対応することができます。

4.4. エッジケースへの対応

現在のリモート開発環境には、多くのエッジケースが存在しています。Windows開発、iOS開発、CIでのステージング環境の利用など、これらは従来のコンテナベースの開発環境では十分にカバーできない領域です。

興味深いことに、私たちが想定する前に、多くのユーザーが独自にこれらのユースケースに対応するための工夫を行っていました。例えば、Windows開発のためにCoderの周辺でスクリプトを作成したり、組み込み開発向けに独自の方法を編み出したりしています。具体的には、ローカルマシンでコーディングを行いながら、一貫性のある環境でビルドを実行するためにCoderワークスペースにリーチアウトし、その結果をワークスペースに同期するという方法です。

また、AIやリモート拡張開発、AI支援開発といった新しいユースケースも登場しています。ただし、現状ではこれらの実現には多くのスクリプティング、ポートフォワーディング、ローカル同期が必要となります。

将来的には、Coderでこれらのユースケースをよりネイティブにサポートし、プラットフォーム内での一級市民として扱えるようにしていきたいと考えています。例えば、MacOSのコンパイルをサポートすることで、iOS開発もより直接的にサポートできるようになるでしょう。これらのエッジケースへの対応は、開発環境の包括的なソリューションとしての価値を高めることにつながります。

5. 成功事例と今後の展望

5.1. 代表的な導入事例

エンタープライズ開発環境は、様々な組織で具体的な成果を上げています。私たちのウェブサイトで公開している3つのケーススタディでは、これらの成功事例が詳しく紹介されています。

最も印象的な成果の一つは、大規模企業での導入事例です。ある企業では、わずか4ヶ月という短期間で1,000人の開発者の移行を完了することができました。この迅速な移行は、私たちが提案する段階的なアプローチと、ユニバーサルイメージの活用が効果的であったことを示しています。

また、クラウドコストの削減効果も顕著です。導入企業では平均して30%のコスト削減を達成しています。これは主に、VMの自動シャットダウンやナイトリーパッチの適用など、リソース管理の最適化によるものです。

さらに、開発環境の起動時間も50%削減されました。これは開発者の生産性向上に直接的な影響を与えています。標準化された環境の提供と、効率的なリソース管理の組み合わせが、この成果につながっています。

これらの成果は、エンタープライズ開発環境が理論的な構想段階を超えて、実際の企業環境で具体的な価値を提供できることを示しています。

5.2. 他社（Slack、Uber）の実装例

Coderを使用していない企業の実装例も参考になります。特に、SlackとUberの両社は、リモート開発環境に関する優れたブログ記事を公開しています。これらの記事は、各組織が独自のアプローチでどのように開発環境を構築しているかを詳しく説明しています。

興味深い点は、各組織が異なるパターンでリモート開発を実現していることです。SlackとUberは、それぞれの組織の特性や要件に合わせて、独自の実装アプローチを選択しています。彼らの知見は、リモート開発環境の構築に関する様々な選択肢と、それぞれのアプローチのメリット・デメリットを理解する上で非常に参考になります。

特に注目すべきは、これらの組織がCoderとは異なる方法で同様の課題に取り組んでいるという点です。しかし、最終的な目標は私たちと同じであり、開発環境の標準化と効率化を目指しています。彼らの実装例は、リモート開発環境の構築に関する代替的なアプローチとして、貴重な参考事例となっています。

5.3. 共通の目標と多様な実装パターン

エンタープライズ開発環境は、ソフトウェアエンジニアのための典型的な開発ライフサイクルだけでなく、MLOpsワークフローなど、より広範なニーズに対応する必要があります。このプラットフォームは、3つの主要な目標を達成するためのソリューションとして位置づけられています。

第一に、モダンでセキュアなツーリングを、クラウドネイティブベストプラクティスの一部として展開することが可能です。これにより、開発者は組織の標準化されたツールチェーンを効率的に利用できます。

第二に、既存のクラウドネイティブベストプラクティスを開発者の日常的なワークフローに適用できます。セキュリティスキャン、ポリシー、コンテナレジストリなど、本番環境で使用している手法を開発環境にも展開することで、一貫性のある開発プラクティスを実現できます。

第三に、開発環境の標準化を実現する方法は組織によって異なります。興味深いことに、各組織はわずかに異なるパターンで実装を行っていますが、それらは全て同じ目標を達成するためのものです。これは、エンタープライズ開発環境が柔軟性を持ち、各組織の特性に合わせて適応できることを示しています。

この多様性と柔軟性こそが、エンタープライズ開発環境の強みであり、様々な組織のニーズに対応できる理由となっています。