「Platform Engineeringは高い」と言われる前に測る
- 年、プラットフォームエンジニアリング投資の正当化はCTO・VP Engineeringの最重要課題になった。大手企業で2,000〜8,000万円、巨大組織では年間数億円の投資になるため、経営陣から「で、何が改善したの？」と問われる頻度は確実に上がっている。答えを返せない組織は縮小再編の対象になり始めた。
問題は、Platform Engineeringの成果が「開発者の日常体験」に埋め込まれているため、単純なKPIでは捕捉しにくいことだ。デプロイ頻度が上がっても、それが本当にPlatformの貢献なのか、他のリファクタリング成果なのか、単にリリース基準を緩めただけなのかが曖昧になりがちだ。この問題を解く鍵が「複数のフレームワークを使い分ける」運用設計にある。
DORA: 依然として「最低限これは測る」の地位
DORA四指標（Deployment Frequency、Lead Time for Changes、Change Failure Rate、Mean Time to Restore）は、Nicole Forsgrenらの`Accelerate`（2018）以降、デリバリー能力の標準指標として定着した。2026年のState of DevOps Report第10回版でも中核指標として維持され、Eliteクラスの閾値はほぼ変わっていない。デプロイ頻度は1日複数回、リードタイムは1日未満、CFRは5%未満、MTTRは1時間未満である。
DORAの限界は「開発者個人の体験を測らない」ことにある。たとえば同じElite水準でも、開発者が夜中に緊急デプロイを繰り返して達成している組織と、自動化されたPipelineで淡々と達成している組織では持続性がまったく違う。この盲点を埋めるために、2020年以降にSPACEとDevExが登場した。
SPACE: 5次元でチームの健全性を見る
SPACEフレームワーク（Forsgren, Storey, Maddila, Zimmermann, Houck, Butler、2021）は、Satisfaction and Well-being、Performance、Activity、Communication and Collaboration、Efficiency and Flowの5次元で開発者生産性を捉える。単一指標ではなく「必ず複数次元を組み合わせる」というルールが特徴で、Activity（コミット数など）だけを追うアンチパターンに警鐘を鳴らした。
SPACEの実装では、各次元に2〜3指標を選び定期的に測る。たとえばSatisfactionは四半期Developer Experience Surveyと離職率、Performanceはサービス稼働率とフィーチャーのアダプション率、Activityはプルリクエスト数と有意義なコミット率、Communicationはコードレビュー所要時間とメンター指名率、Efficiency and Flowはフロー時間比率と中断頻度、といった具合だ。重要なのは「数字を個人評価に使わない」コミットメントである。これを破ると途端にGoodhart's Law（指標が目標化すると指標として機能しなくなる）に飲まれる。
DevEx Framework（2023年）: Feedback Loops、Cognitive Load、Flow State
Nicole Forsgrenらが2023年に発表したDevEx Frameworkは、Platform Engineeringが直接改善できる3領域（Feedback Loops、Cognitive Load、Flow State）を軸に置く。SPACEが「チーム健全性」の俯瞰であるのに対し、DevExは「Platformが触れる領域」にフォーカスしている点が差別化要素だ。
Feedback Loopsは、「コード変更から結果を知るまでの時間」を指す。ローカルビルド時間、CIパイプライン時間、PRレビュー所要時間、ステージング反映時間、本番観測までの時間の連鎖で、Platform Engineeringの改善がもっとも直撃する領域である。Cognitive Loadは、「開発者が何を覚えておかねばならないか」の負荷で、オンコールドキュメントの質、内部APIの発見容易性、環境構築手順の自動化度などで測る。Flow Stateは、「集中して作業できる時間がどれだけ連続するか」で、通知頻度、会議密度、中断回数の関数になる。
DevEx Frameworkはperception（主観）とworkflow（実測）の両方を組み合わせるのが公式推奨で、四半期Surveyと日次テレメトリーを並走させる。
Developer Experience Index（DXI）: 単一指数への統合
現場で頻繁に問われるのが「結局、うちは良くなっているのか？」への単純明快な答えだ。この要請に応えるのがDXI（Developer Experience Index）で、DX社（Abi Noda CEO）が2023年に提唱し、2026年時点で大手エンタープライズ200社超が採用している。
DXIは14問のSurvey質問をlikert 5段階で測り、加重平均で0〜100スコアを算出する。質問は Deep Work Time、Ease of Deploy、Confidence in Making Changes、Quality of Internal Documentationなど、Platform Engineeringが影響を与えやすい項目で構成される。DX社の内部ベンチマークでは、中央値は68、Top Quartileは80以上、Bottomは55以下という分布だ。
DXIの魅力は「1点の上昇で何円の生産性向上」をざっくり話せる点だ。DX社のMetaアナリシスでは、DXI 1点上昇で開発者1人あたり週0.5時間の生産性改善という相関が出ており、これを人件費ベースで金額換算するとボードに説明しやすい。過度な単純化のリスクはあるが、経営との対話装置として有効だ。
測定ツールの選定: Opsera、Faros AI、Jellyfish
フレームワークは決まっても、データ収集・集計・可視化は道具がいる。2026年主要3製品の特徴を整理する。
Opseraは「DevOps Intelligence」の名で知られ、パイプライン中心のデータ収集に強みを持つ。Jenkins、GitHub Actions、Azure DevOps、GitLab CIからDORA指標をほぼノーコードで算出する。CI/CDの運用状態を最優先で可視化したい組織に向く。SOC2 Type II、FedRAMP Moderate認証済みで、規制産業でも採用しやすい。
Faros AIは「Engineering Operations Platform」として包括的なデータモデルを提供し、Jira、Git、CI、Incident、Calendarの統合に強い。DORA・SPACE・DevExの同時測定が可能で、AIベースのBottleneck Detectionが2025年に追加された。データウェアハウス（Snowflake、BigQuery）への書き出しもサポートされ、社内BI統合を重視する組織に好まれる。
Jellyfishは「Engineering Management Platform」のカテゴリーで、投資配分（Feature / KTLO / Tech Debt / Innovation）の可視化が最大の強みだ。DORA・SPACEは標準対応で、Finance部門との対話に有効な「エンジニアリング投資額対成果」の数字が自動生成される。取締役会向けレポーティングを重視する組織に適合する。
選定の目安は、パイプライン最適化優先ならOpsera、全体最適・AIインサイト重視ならFaros AI、Finance連動・投資配分可視化ならJellyfishである。日本市場での実装実績は2026年時点でOpsera約30社、Faros AI約15社、Jellyfish約20社。いずれも日本語UIは部分対応で、完全日本語化は2026年後半予定である。
組織成熟度モデル: Stage別に測る指標を変える
一つの落とし穴は「全指標を最初から測ろうとする」失敗だ。成熟度に合わない指標は形骸化し、逆効果になる。以下の段階モデルが実務的に機能する。
Stage 1 - Ad-hoc（Platformチーム発足直後）: まずDORA四指標のうちDeployment Frequencyと Lead Timeだけを測る。計測自体の仕組み作りが目的で、精度は二の次。
Stage 2 - Foundational（Platformチーム12〜18ヶ月目）: DORA四指標 + DXI Survey年2回。Platform採用率（Catalog登録サービス数、Golden Path利用率）を追加。
Stage 3 - Intentional（Platform製品として運用できる段階）: DORA継続 + DXI四半期 + SPACE複数次元 + DevEx FrameworkのFeedback Loops実測。Platform NPSを四半期で。
Stage 4 - Optimized（プラットフォームがProfit Centerに近い位置付け）: 上記すべて + 金額換算ROI + 投資配分分析。取締役会へ四半期報告。
Stage 5 - Transformative: Platform自体が他社向けプロダクト候補、または業界ベンチマークへの貢献フェーズ。Platform Engineering DayやKubeConでの登壇、OSS還元を含む外部可視化へ。
「ROIを出す」ための現実的な言語化
経営説明で効く表現は、単純なほど強い。DXI 5点上昇で年間相当時間◯万時間、金額換算で◯億円。P1インシデント月間◯件減、SRE On-call疲労指数◯%改善。Golden Path採用サービス◯個、平均初回デプロイまでの時間が◯日から◯時間へ。これらをダッシュボードで見せるのでなく、PPT 1枚に絞る。
- 年のPlatform Engineeringは、「開発者体験をよくします」だけでは予算を守れない。測るべきものを測り、経営と共通の言葉で語ること。それがPlatform Engineeringを文化インフラとして定着させる最短ルートである。