4. プラットフォームエンジニアリング
定義
プラットフォームエンジニアリングは、チーム間の社会的相互作用と、自動化・セルフサービス・反復可能性の技術的側面が交差する社会技術的(sociotechnical)規律です。しばしば内部開発者プラットフォーム(Internal Developer Platform) と呼ばれるツールチェーン・ワークフローを設計・構築し、開発チームがアプリケーションを安全・信頼・コンプライアントに簡単にビルド・テスト・デプロイできるゴールデンパスを提供します。
インフラチケットの集まりではなく、開発者のための社内製品として理解すべきです。2025年時点で導入はほぼ普遍的で、90%の組織が内部開発者プラットフォームを使用し、76%が専任のプラットフォームチームを持っています。
DORA研究: プラットフォーム品質が高いとAI導入の組織パフォーマンス効果は強くポジティブ、低いとほぼ無視できる。
AIの視点
AIは増幅器です。組織は個々の開発者にAIツールを配ることに速さを競っていますが、DORAデータは個々の生産性向上が「下流の無秩序(downstream disorder)」に飲み込まれるリスクを示します。コーディング速度の向上は、テスト・セキュリティレビュー・複雑なデプロイのボトルネックに吸収されます。
高品質なプラットフォームは、AIのデリバリー・ガバナンス層として機能します。AI生成コードを一貫してテスト・保護・デプロイすることで、安定性を犠牲にせずAIの速度を組織的成果へ変換します。
実装方法
- プロダクトマネジメントのマインドセットを採用。 プラットフォームは社内製品、開発者は顧客。プロダクトマネージャーを配置してDevExとロードマップに注力し、主要なユーザージャーニー（「新サービスを立ち上げる」「本番インシデントをデバッグする」）をマッピングして摩擦を除く。
- 認知負荷を積極的に「shift down」。 開発者をKubernetes・ネットワーキング・セキュリティポリシーの専門家にさせず、複雑さをプラットフォームへ下ろす。2024年の研究: 開発者の独立性（イネーブリングチーム(enabling team)に頼らずに作業を遂行できる能力）はチーム・個人の生産性を5%高めた。
- 「最小機能プラットフォーム(MVP)」で始める。 最も一般的なワークフローのゴールデンパスを作り、そのジャーニーだけを確実に改善する。
- 拡張性をもって設計。 中央のプラットフォームチームがすべてを作れるわけではない。明確なAPI・貢献モデルで他チームが標準的な方法で貢献できるようにする。
- 明確なフィードバックを優先。 2025年データ: ポジティブなユーザー体験と最も相関が高いプラットフォームケイパビリティは 「自分のタスクの結果に関する明確なフィードバック」 である。
よくある落とし穴
- 「作れば来る」の罠: ユーザーリサーチなしに仮定でプラットフォームを作る → 低い採用。
- 「象牙の塔」アプローチ: 中央チームが協働なしに標準を押し付ける → シャドーITによる回避。
- 「チケットオプス」の罠: セルフサービスではなく受動的なインフラ自販機 → ボトルネック。
- 「ビッグバン」リリース: 完璧なプラットフォームを一度に構築しようとする高リスクな接近。
- 「画一的な」発想: データサイエンス・モバイルなど多様なニーズを無視する硬直した「黄金の檻」。
測定方法
DORAの研究によれば、プラットフォームは生産性と組織パフォーマンスを高めますが、慎重に管理しなければスループットと変更の安定性が低下する可能性があります。そのため、以下の指標をバランスよく併せて見る必要があります(balanced scorecard)。
ソフトウェアデリバリーパフォーマンス: 変更リードタイム、デプロイ頻度、失敗デプロイ復旧時間、変更障害率、デプロイ再作業率。プラットフォームチームは自チームの成果測定に、アプリケーションチームはプラットフォームが公開する指標に用いる。
開発者満足度(DevEx): CSAT・NPSで定期サーベイ。
採用・継続: H.E.A.R.Tフレームワークで新規チームのオンボーディング率・継続使用率。
タスク成功: プラットフォーム上で主要ワークフローを完了する効率・効果。
注意: Jカーブ
プラットフォームエンジニアリングはJカーブをたどります。初期の成果の後、複雑さの増大で下落し、成熟とともに高い水準で回復・安定します。期待値を管理してください。
出典
本記事はDORAのPlatform engineeringを要約したものです。原文 © Google LLC、CC BY 4.0。