セキュアなクラウド開発環境（CDE：Cloud Development Environments）が、プラットフォームエンジニアリングを支援し、ユーザー環境の自動構築と設定、開発者体験のパーソナライズ、データセキュリティポリシーの定義と適用、チームの大規模オンボーディングの効率化をどのように実現するかをご紹介します。
なぜコーディングフェーズにプラットフォームアプローチを導入すべきか？
DevOps とプラットフォームエンジニアリングは、どちらも現代のソフトウェア開発ライフサイクルの一部ですが、それぞれが解決しようとする課題は異なります。
DevOps は、統合と継続的デリバリー（CI/CD）に焦点を当てており、チームは「コードのデプロイ頻度」「変更にかかるリードタイム」「変更の失敗率」などの指標を重視します。
一方、プラットフォームエンジニアリング は、DevOps を支える基盤プラットフォームの設計と運用に取り組み、より広い範囲を対象とします。そのため、主に「CI/CD プラットフォームの稼働時間」「リソース使用率」「ツールの採用率」「プロセスの自動化レベル」などが測定指標となります。
プラットフォームエンジニアリングは、単なるインフラ提供の枠を超えて、Internal Developer Platform（IDP） などの包括的なセルフサービス型プラットフォームの構築へと急速に進化しています。実際の運用において、以下の領域はプラットフォーム視点からますます重要となっています：
- セキュリティ：開発ライフサイクル全体にセキュリティ対策を組み込むことで、インフラとコードの両方の安全性を向上させる必要があります。
- 開発者体験（DX）：インフラの複雑さを解消し、開発者がソフトウェアの構築に集中できる環境づくりが求められています。
- アナリティクス：リソースの最適化や問題の予測を支援する、AIを活用した予測的／処方的分析、そしてインテリジェントな自動化が求められています。
一般的に、プラットフォームエンジニアリングのコーディングフェーズへの貢献は、デプロイ・モニタリング・運用と比べると間接的なものです。
しかし、たとえば以下のような手段を通じて、その効果を発揮しています：
- コンテナレジストリ経由の標準化された開発環境の提供
- CI/CD サービスの構築
- セルフサービス型のリソース・サポートポータル
- ドキュメント化された API や SDK
- パイプラインへのセキュリティチェックの組み込み
本記事では、こうしたプラットフォームエンジニアリングの考え方を、コード開発プロジェクト全体の定義にまで拡張する方法について解説します。
具体的には、開発者のノートPC環境、必要な開発リソースやアプリケーション、インフラ・コードに関するセキュリティポリシー、オンボーディングに関連する組織ポリシー（予算計画や予測型ガバナンス情報など）を含みます。
これにより、開発プロジェクト全体のセットアップと展開を自動化できる仕組みが実現され、開発効率と組織全体の統制力を大きく高めることが可能になります。
このアプローチは、前述の3つの軸に明確に対応しています：
- コードがビルドパイプラインに到達する前の段階で、インフラとコード両面からセキュリティおよび組織のコンプライアンスポリシーを適用することで
- 組織が開発者に提供する各開発端末レベルで、開発者体験をパーソナライズすることで
- プロジェクトが始まる前の段階から、ガバナンスとコンプライアンスのために分析機能を活用することで
こうした課題にプラットフォームエンジニアリングが対応するためには、**セキュアなクラウド開発環境（CDE）**の機能を活用するのが有効です。
CDEは、私がこれまでの記事でたびたび取り上げてきた新興技術であり、私の所属する企業もその分野をリードしています。
セキュアなクラウド開発環境（CDE）の広がり
CDE（クラウド開発環境）の技術は、Gartner の 2023年 Agile & DevOps レポートにおいて、新興技術として位置づけられています。
ここではまず、CDE とセキュアCDE の違いを簡単に説明します。
CDEとセキュアCDEは、いずれも開発プロセスを管理するためのアプローチですが、それぞれが生産性、セキュリティ、ガバナンスの向上を目的にしています。
どちらも、これまでローカルで行われてきたソフトウェア開発の活動をクラウドへと移行させるプラットフォームを提供し、さまざまなメリットをもたらします（詳しくは本記事内で紹介します）。
一方、セキュアCDEは、従来のCDEが持つ利点を取り入れつつ、特にセキュリティ対策を強化している点が大きな特徴です。
このアプローチは、知的財産や機密データを、データの持ち出し（エクスフィルトレーション）や侵入（インフィルトレーション）といった脅威から守るために極めて重要です。
プラットフォームエンジニアリングのアプローチを支援し、開発チーム全体のオンボーディングプロセスを自動化するという文脈において、セキュアCDEが他のCDEと比べて持つ最大の利点は、より広範な課題に対応できることです。
特に、開発者体験、DevOpsの生産性、セキュリティといった領域において、その違いが顕著です。
またこちらの記事では、セキュアCDEが DevOps の中核的な原則――フロー、フィードバック、継続的学習――に新たなアプローチを提供していることも解説しています。
したがって、セキュアCDEの影響は単なるプラットフォームエンジニアリングの自動化にとどまらず、DevOpsそのものの再構築にもつながるのです。
なお、セキュアCDEを提供するセキュアなクラウド開発プラットフォームの全体アーキテクチャについては、ここで詳述すると本題から逸れてしまうため、興味のある方はぜひこちらの記事をご参照ください。
デスクトップ・モノリスからの脱却
プラットフォームエンジニアリングの目的は、主に開発者の認知負荷を軽減し、生産性と集中力を高めることにあります。そのために、ツールやプロセスの標準化と単純化を促進するのが一般的なアプローチです。
主な利点としては：
- コア業務への集中強化
- 品質と一貫性の向上
- コラボレーションの活性化
- そして、個人的に最も重視しているのがイノベーションの促進です。これは、思考リソースを解放することで新たなアイデアに取り組む余裕が生まれるためです。
ここで、前述のリストには含めませんでしたが、認知負荷の軽減という観点からもう一つ重要な目標があります。それが、オンボーディングの迅速化です。
これはプラットフォームエンジニアリングが標準化された開発環境を提供することで対処してきた課題ですが、実際にはプロジェクトチーム全体をオンボードするには、開発者やサポートチームが数多くの初期セットアップ作業を手動で行う必要があります。
たとえば、開発環境を個人の好みに合わせてカスタマイズしたり（環境ファイル、ツール設定など）、お気に入りのツールを構成したりする作業があります。さらにサポートチームは、すべてのセキュリティおよびコンプライアンス対策が適用されていることを確認しなければなりません。
たとえば、社内チームとオフショアチームでは適用すべきリスクコントロールが大きく異なることもあるでしょう。
このような場面で、セキュアCDEはより細かな制御が可能であり、組織の要件から各開発者の個別の設定に至るまで、安全かつコンプライアンス対応のオンボーディングを自動化するための基盤となります。
これまでにも私は、セキュアCDEおよび実質的にはセキュアなクラウド開発プラットフォームの活用によって、「セキュアな開発者用ノートPC」を抽象化し、ワークスペースとして提供することが可能であると説明してきました。
この「ワークスペース」は、知的財産保護といったセキュリティ面での懸念に対応しつつ、セキュアCDEならではの生産性とセキュリティの利点を同時に提供します。
下図では、この抽象化されたワークスペースが、開発者体験、リソース使用量とデータアクセス制御、チームの運用に関するセキュリティポリシーなど、さまざまな懸念事項をどのようにカバーしているかを示しています。
つまり、このセキュア開発者ノートPCの仮想的な姿を担うワークスペースの主なステークホルダーは、開発者、プラットフォームエンジニアリングチーム、セキュリティチームであると言えます。
セキュアCDEをテンプレートで構成することは、プラットフォームエンジニアリングにおけるAPIベースのプログラマティックな自動化を実現し、開発チーム全体のオンボーディングを完遂するための鍵となります。
本質的には、「チームをコードとして管理する（Team-as-Code）」というコンセプトを実装する手段です。
テンプレートの具体的なパラメーターはプラットフォームごとの実装に委ねられますが、ここでは Strong Network が提供するプラットフォームで対応している主な要素について紹介します。
特に当社では、テンプレートを YAML形式のテキストベースで表現しており、これによりテンプレートの編集やバージョン管理が容易に行えるようになっています。
Team-as-Code を構築・提供する方法
主要な技術コンポーネントが整ったところで、次は Team-as-Code アプローチを実装するうえでのプロセス自動化について解説します。
プラットフォームエンジニアリングの実装では、**一連の操作をAPI経由でオーケストレーション（自動連携）**するケースが一般的です。
ここでもこのアプローチが有効であり、開発チーム全体のオンボーディングおよびセットアッププロセスは、以下のように自動化できます：
- チームをホストする組織内にプロジェクトを作成する
- 各ユーザーを、それぞれのロールとともにプロジェクトにオンボードする
- 事前に作成されたテンプレートから一連のワークスペースを作成し、データアクセス制御やセキュリティポリシーを反映させる
- 各ワークスペースを個別ユーザーに割り当てる
- 各ユーザーを、自分のワークスペースに紐づくリソースに対して認証する
- 各ユーザーの好みに基づいてワークスペースをパーソナライズする
※これらのステップの一部は実際には同時に処理されますが、理解しやすくするために分けて記載しています。
なお、この一連のプロセスは、Azure、AWS、GCPなどの主要なクラウド環境であれば1分未満で完了します。
すべてのワークスペースが起動すると、ユーザーはプラットフォームにログインしてすぐにコーディングを開始できます。
さらに、こうした API実行シーケンスは、Atlassian の Jira や ServiceNow といったプロジェクト／ITSMツールからトリガーすることも可能です。
以下の図では、プロジェクト管理ツールを通じてAPI経由でチーム環境を構築する例を示しています。
もうひとつの例として、今回は**処方型アナリティクス（Prescriptive Analytics）**をご紹介します。それが「プロジェクトに必要なリソースの適正サイズの算出」です。つまり、特定のプロジェクトに必要なコンピューティングリソースを見極めるということです。
このケースにおいて、当社プラットフォームの特長のひとつは、ワークスペースのアクティビティ中にリアルタイムで各種指標を収集できる機能です。
これらの計測データを活用することで、組織はたとえばプロジェクト期間中におけるビルド時間の平均値などの指標を比較しながら、必要なリソースを推定し、アイドル時間を最小化するようなベストプラクティスに沿って、生産性の期待値と運用を調整することが可能になります。
