プラットフォームを使うチームはスループットが8%、変更の安定性が14%低かった — DORAのデータを因果として読んではいけない理由

はじめに — 「導入率90%」という数字をまず分解する
DORA 2024が実際に見つけたもの — 良い知らせと都合の悪い知らせ
DORA自身が出した3つの仮説 — 3つ目が重要だ
2025年、DORAは「効果」という語を捨てた
「プラットフォームの品質」は何で測られたのか
ベンダーリサーチの読み方 — Puppet 2026編
このデータで言えることと言えないこと
だから月曜日に何をするか
おわりに
参考資料

はじめに — 「導入率90%」という数字をまず分解する

2026年半ばの現在、プラットフォームエンジニアリングをやるべきかと問う人はあまりいません。論争は終わったように見えます。DORAの2025年リポートは、プラットフォーム章の中核的な発見をこうまとめています — 「プラットフォームの導入はほぼ普遍的だ:90%」。専任のプラットフォームチームを持つ組織は76%で、今や支配的な組織モデルだと書かれています。

しかし、この数字が何を数えたものかをまず見る必要があります。DORAが調査で使ったプラットフォームの定義は、付録にこう書かれています — プラットフォームとは「複数のアプリケーションやサービスにまたがって共有される能力の集合」であり、一社に重なり合う複数のプラットフォームが存在しうるが、それらをまとめて「そのプラットフォーム」と呼ぶ、というものです。

この定義であれば、全社で共有する一つのJenkinsもプラットフォームです。共有Kubernetesクラスタもプラットフォームであり、社内共通のCIテンプレートもプラットフォームです。2024年リポートはこの点をもっと露骨に書いています — 今年の調査では内部開発者プラットフォームの定義を「かなり広く(quite broad)」取ったところ、回答者の89%が内部開発者プラットフォームを使っているという結果になった、と。

つまり「導入率90%」は「90%の組織がBackstageのようなポータルとゴールデンパスを備えている」という意味ではありません。「90%の組織に何か共有されるものがある」に近いのです。この差を押さえておくことで、残りの数字が正しく読めるようになります。

そして本当に興味深いのはその先です。同じ研究プログラムが、プラットフォームを使う側のほうが、処理量と安定性でむしろ悪かったと報告しているという事実です。

DORA 2024が実際に見つけたもの — 良い知らせと都合の悪い知らせ

2024年DORAリポートは、プラットフォームエンジニアリングに丸ごと一章を割きました。その年の調査には、世界中から約3,000人の実務者が回答しています。リポートの表現をそのまま移すとこうです。

良い知らせのほうから:

内部開発者プラットフォームの利用者は個人生産性が8%高かった。
チーム成果は10%高かった。
組織のソフトウェアデリバリー・運用パフォーマンスは、プラットフォームを使うと6%高くなる。

ここまでは、私たちが期待していた通りの絵です。ところが、その直後の文はこう続きます — 「しかし、この利得は無代価では得られない。処理量と変更の安定性はそれぞれ8%と14%減少しており、これは驚くべき結果であった。」

リポートはこの箇所に「予期しなかった欠点(The unexpected downside)」という小見出しまで別に付けています。数字をもう一度分解すると:

処理量。 プラットフォームを使わない側と比べて約8%減少。
変更の安定性。 14%減少。リポートはこれが何を意味するかも丁寧に説明しています — 「変更失敗率と手戻り率が、プラットフォームを使うと有意に増加する」という意味です。

さらにもう一段あります。プラットフォームを「アプリケーションのライフサイクル全体を通じて必ずプラットフォームだけを使って」作業するよう求められていると答えた回答者では、処理量がさらに6%低くなっていました。プラットフォーム利用を義務化した側のほうが遅かった、ということです。

そして最も都合の悪い組み合わせ — リポートは、不安定さとプラットフォームが結びつくと燃え尽きの水準がさらに高まるという連関を見つけたと書いています。ただし、すぐに釘を刺しています — 「だからといって、プラットフォームが燃え尽きを引き起こすという意味ではない」と。

この一文が、本稿全体の核心です。

DORA自身が出した3つの仮説 — 3つ目が重要だ

ここでDORAを評価すべき点が出てきます。自分のデータが自分の主張と食い違う結果を出したとき、リポートはそれを隠したりごまかしたりせず、「私たちも理由を完全には分かっていない」と書いた上で仮説を並べています。

第一に、仕組みが増える。 デプロイの前に変更が通過すべき段階が増えた、という説明です。リポートの表現では、内部開発者プラットフォームでビルド・デプロイすると、システム間の — そして暗黙にはチーム間の — 「ハンドオフ」の数がたいてい増えます。コードをコミットすると、テスト・セキュリティ検査・デプロイ・モニタリングを担う異なるシステムが順番に受け取っていきます。各ハンドオフは時間が入り込む機会であり、そのため処理量は下がるが、「仕事を終わらせる能力そのものは純増する」というわけです。

第二に、強制された排他性。 上で見た6%の減少です。プラットフォームがその作業に適していなくても必ず使わなければならないなら、増えた遅延はそのままコストになります。

第三 — そしてこれが決定的です — 逆因果仮説。 リポートの原文をそのまま移すとこうです — 変更の不安定性と燃え尽きの水準が高いチームほど、安定性を改善し燃え尽きを減らそうとしてプラットフォームを作る傾向がある。さらにもう一文 — 「この仮説が正しいなら、プラットフォームエンジニアリングは燃え尽きと変更の不安定性を抱えた組織の症状(symptomatic)である。」

噛みしめるべき点です。これが事実なら、矢印は逆です。プラットフォームが不安定さを作ったのではなく、不安定な組織がプラットフォームを作った。病人が多い病院があるからといって、病院が病気を作ったわけではないのと同じです。

そして、このアンケートデータだけでは両方向を区別する方法がありません。 ある一時点のスナップショット一つでは、「プラットフォーム → 不安定」と「不安定 → プラットフォーム」はまったく同じ相関に見えます。

安定性の低下についても、リポートは同様に複数の分かれ道を開けたままにしています。一つは楽観的な解釈です — プラットフォームがあれば悪い変更が出ても素早く復旧できるという自信が生まれ、チームがより実験的に、より頻繁に変更を押し込むようになる。この場合、上がった変更失敗率は悪い兆候ではなく、実験が増えた結果です。もう一つは悲観的な解釈です — プラットフォームが自動化されたテスト実行を提供しているのに、アプリケーションチームが肝心のテストを改善せず処理量だけを優先すると、悪い変更がそのまま通過して手戻りとして返ってくる。

同じ数字が正反対の2つの物語を支えています。これはデータの欠陥というより、この種のデータが元々言える範囲の限界です。

もう一つ、2024年リポートにはあまり引用されない有用な発見があります。プラットフォームの年齢を併せて見ると、曲線がJ字を描きます — プラットフォーム施策の初期に成果が上がり、その後下落と回復を経てプラットフォームが成熟していく。リポートはこれを「初期の利得を実現した後に困難にぶつかる」典型的な変革施策パターンだと呼んでいます。長期的には生産性の利得が維持されるとも書かれています。2年目に数字が悪化したからといってプラットフォームチームを解散しようとする組織があれば、このJカーブを見せることが助けになるかもしれません。

そして、何が利得を生むかについての発見も具体的です。開発者の独立性 — 「開発者がイネーブリングチームに依存せず、アプリケーションのライフサイクル全体で自分の作業を遂行できる能力」と定義されます — が確保されると、個人・チームの両方で生産性が5%向上します。一方、専任プラットフォームチームの存在は個人生産性への影響がわずかで、チームレベルでのみ6%の利得がありました。そして、プラットフォームへのフィードバックを収集しないことはマイナスの影響を与えると明記されています。

2025年、DORAは「効果」という語を捨てた

2025年リポートは2025年9月に出ました。標本は4,867人(リポートの表現では「ほぼ5,000人」)で、100時間を超える定性データも併せて集められています。

このリポートで最も注目すべき箇所は、プラットフォーム章ではなく脚注です。20番の脚注をそのまま移すとこうです。

昨年、私たちは「効果(effects)」という表現を使いました。しかし今年は「比較(comparisons)」の言葉で語ろうと思います。因果的に語れる条件を作ろうと努めてはいますが、私たちが背後の因果構造を理解しているという誤った確信を与えたくありません。時に因果的な表現を使うこともありますが、突き詰めれば私たちがしているのは比較です。

そしてその根拠として、ゲルマンとヒルの『Regression and Other Stories』を引用しています — 観測されたのは観測的パターンであり、「回帰の最も安全な解釈は比較として見ることだ」と。

これはよくあることではありません。毎年数千人を調査してリポートを売る研究プログラムが、自らの表現の強度を自分から一段下げたのです。ところが、このリポートを引用する記事やカンファレンススライドは、ほぼ例外なく「プラットフォームが組織成果を高める」という因果文に置き換えます。原文が「比較」だと明確に釘を刺しているにもかかわらず、です。

プラットフォーム章の内容も誠実です。2025年リポートは2024年の発見をこうまとめています — プラットフォームは組織成果と生産性にプラスの影響を与えるが、「その利得にはトレードオフが伴った:ソフトウェアデリバリーの不安定性の増加と処理量の減少。」

そして2025年のデータでも、このパターンは消えていません。リポートはこう書いています — 「過去の研究と一貫して、より優れたプラットフォームはソフトウェアデリバリーの不安定性のわずかだが信頼できる増加と関連しており、これはより高い変更失敗率と手戻りの増加を意味する。」

DORAの解釈は今回、楽観の方向へ傾いています — この不安定性の増加は「健全で高速なシステムの特徴でありうる」というもので、プラットフォームが失敗からの復旧を速く安く可能にするために、チームがより実験し、些細な失敗をより許容する一種のリスク補償(risk compensation)だという説明です。もっともらしい解釈です。ただし、これも解釈であって測定結果ではありません。

「プラットフォームの品質」は何で測られたのか

2025年リポートの見出しとなる発見はこうです — 高品質な内部プラットフォームは、AI導入の効果を増幅する。より正確には、プラットフォーム品質が低いときAI導入が組織成果に与える影響は無視できる水準で、プラットフォーム品質が高いときは強くプラスに働く。Google Cloudのブログが「高品質な内部プラットフォームとAIから価値を実現する能力との間に直接的な相関がある」と宣伝した、あの発見です。

では「プラットフォームの品質」はどう測られたのでしょうか。リポート本文はこう説明しています — プラットフォーム品質は、回答者が自分のプラットフォームが備えていると答えた12の特性の個数を表す単一のスコアとして測定される。

付録にその項目が載っています。「あなたのプラットフォームは、次の特性をどの程度示していますか」という質問に紐づく項目です。

- プラットフォームが、信頼できるアプリケーションとサービスを構築・運用する助けになる
- プラットフォームが、安全なアプリケーションとサービスを構築・運用する助けになる
- プラットフォームのUIが明瞭で整理されている
- プラットフォームが、独立して働くために必要な道具と情報を提供する
- プラットフォームが、私が予想する通りに動作する
- プラットフォームが、必要なプロセス(コードレビュー、セキュリティ承認など)に従う助けになる
- プラットフォームが、私の作業結果について明確なフィードバックをくれる
- プラットフォーム上で行う作業がよく自動化されている
- プラットフォームチームが、私が出したフィードバックに沿って動く
- プラットフォームが使いやすい
- プラットフォームが、下位インフラの複雑さを効果的に抽象化している

読めば分かるとおり、これらは全て主観的な認識です。「プラットフォームが使いやすい」「私が予想する通りに動作する」— これは測定された指標ではなく、開発者が感じたことです。ここに悪い意図はありません。開発者体験はそもそも主観的なものであり、それを尋ねること自体は正当です。

問題は、結果変数のほうも同じく主観的だという点にあります。付録の「結果をどう評価したか」の節を見ると、組織パフォーマンス(organizational performance)はこういう問いで測定されています — 「過去1年間、あなたの組織は目標に対して次の指標でどうでしたか?」そして項目は、組織全体のパフォーマンス、全体の収益性、組織・ミッション目標の達成、顧客満足、運用効率、製品・サービス品質です。

つまり、監査済みの財務諸表ではありません。回答者が、自社の収益性が目標に対してどうだったかをリッカート尺度で答えたものです。生産性もコード品質も個人の有効性も、全て「self-assessed(自己評価)」だと付録に明記されています。

すると「高品質プラットフォームが組織成果を高める」という文の実際の中身はこうなります — 自分のプラットフォームを高く評価する人は、自分の会社も高く評価する傾向がある。 これはそれでも意味のある発見です。しかし、因果の主張とは程遠いものです。会社の業績が良かったからプラットフォームに投資する余裕があったのかもしれませんし、単に会社を肯定的に見ている人がすべての項目に甘く答えただけかもしれません(共通方法バイアスと呼ばれるものです)。

標本の集め方も見ておく価値があります。リポートの方法論の章が自ら明かしている通り、DORAは2つの経路で回答者を集めます — ブログ・メール・ソーシャルメディアを通じた「有機的(organic)」な経路で、これにはコミュニティに拡散を頼むスノーボールサンプリングが含まれます。そして、それを補うパネル経路があります。確率標本ではありません。DORAのソーシャルメディアやコミュニティの届く範囲内にいる人、つまり既にDevOpsの議論に関わっている人が過大に標本化されます。定性インタビュー側の偏りはさらに顕著です — リポート自らが明かす通り、78人のインタビュー対象者のうち76人が米国在住であり、リポートはこれをインタビュアーの言語能力とスケジュール上の制約によるものだと説明しています。

最後に、このリポートの発行主体も押さえておく必要があります。2025年DORAリポートはGoogle Cloudが発行しており(著作権表示は「Google LLC」、CC BY-NC-SA 4.0)、リサーチパートナーとしてIT Revolution、GitHub、GitLab、SkillBench、Workhelixが名を連ねています。クラウドと開発者ツールを売る企業が、「プラットフォームとAIに投資せよ」という結論が出る研究を後援したわけです。DORAの方法論がこの業界でも誠実な部類に入ることと、この利益相反が存在することは、両方とも事実です。両方とも覚えておく必要があります。

ベンダーリサーチの読み方 — Puppet 2026編

比較対象があると基準線が定まります。2026年に出たPuppet(Perforce)のState of DevOps Report: Platform Engineering Edition 2026を見てみましょう。見出しの数字はこうです。

プラットフォームエンジニアリングが成熟した組織の73%が、その成熟度がAI成功を導いていると答え、成熟度の低い組織では44%だった。
組織の66%がインフラのワークフローにAIを適用しているが、完全自律運用を報告したのはわずか31%で、標準化された内部開発者プラットフォーム環境では44%に上がる。
プラットフォーム成熟組織の79%が成熟したガバナンスを報告し、未成熟組織では14%だった。
成熟した組織の81%がAIを信頼すると答え、未成熟組織は48%だった。標準化されたIDP環境では92%、公式なガバナンスがある組織では94%まで上がり、その場しのぎのガバナンスでは51%だった。

数字自体は正確です。私自身がページの原文で確認しました。問題は、これらの数字が何を語りうるかです。

まず標本から。方法論ページを開くとこう書かれています — 「本調査は、820人のグローバルIT意思決定者(ITDM)、購買インフルエンサー、DevOps実務者を対象とした20分間のオンライン調査として実施された。」

購買インフルエンサーが標本に明示的に含まれています。インフラ自動化製品を売る企業が、購買決定に影響を与える人々に、プラットフォーム成熟度が良いことかどうかを尋ねました。これは即座に数字が間違っているという意味ではありません。ただ、この標本は「開発者がプラットフォームをどう体験しているか」よりも「購買担当者が何を信じているか」にはるかに近いものです。

そして同じページの「Limitations」節全体が、この一文です — 「結果は自己報告された慣行と認識を反映している。」

一文です。DORAが因果言語について脚注を付け、ゲルマンを引用し、自ら表現の強度を下げている一方で、ここでは820人調査の限界がたった一行で処理されています。これがベンダーリサーチを読むときの実用的な信号です — 限界節の長さは、その研究をどこまで信頼すべきかの、かなり良い近似値です。

内容の面でも注意すべき点があります。「プラットフォーム成熟組織の79%が成熟したガバナンスを報告し、未成熟組織は14%」という文で、成熟度とガバナンスを判定したのは誰でしょうか。同じ回答者です。そして、成熟度モデルがガバナンスを成熟度の構成要素として含んでいるなら、この相関は発見というより定義に近くなります。私はPuppetの成熟度モデルの定義を最後まで確認できなかったので、そうだと断定はしません。ただ、こうした形の「成熟した組織はXも得意だ」という文に出会ったら、常に問うべきです — Xはすでに成熟度の定義の中に入っていないか?

「73%が成熟度がAI成功を導いていると答えた」も同様です。これはAI成功についての測定ではなく、人々の信念についての測定です。この2つは別のものです。

このデータで言えることと言えないこと

まとめます。

言えること:

プラットフォームと呼べる共有能力は、今やほぼ全ての組織にある(広い定義基準で90%)。専任プラットフォームチームも76%で支配的なモデルだ。
プラットフォームを使うと答えた人は、自分の生産性とチーム成果をより高く評価する傾向がある(2024年基準で8%、10%)。
同時に、プラットフォームを使うと答えた人は、処理量と変更の安定性をより低く報告した(8%、14%)。このパターンは2025年も方向性が維持された。
自分のプラットフォームを高品質と評価した人は、AI導入と組織成果の関連をより強く報告した。
開発者の独立性は繰り返し現れる信号だ。イネーブリングチームなしで作業を終えられるとき、生産性が5%高かった。

言えないこと:

「プラットフォームを導入すると処理量が8%落ちる。」矢印の方向は確定していません。DORA自身が逆因果仮説を明示的に開けたままにしています。
「高品質プラットフォームが組織成果を高める。」DORAは2025年に、まさにこの表現を避けることを選びました。これは比較であって効果ではありません。
「プラットフォーム成熟度がAI成功を作る。」これは、成熟していると自己評価した人々がそう信じているという報告です。
「自社も8%上がるだろう。」確率標本ではなく、あなたの会社は標本に含まれていません。

もう一つ付け加えると、これらの数字は全てリッカート尺度の標準化された差を百分率に変換したものであり、ストップウォッチで測ったものではありません。「処理量8%減少」は、デプロイ回数を数えて8%少なかったという意味ではなく、処理量に関する項目の回答がそれだけ低かったという意味です。

だから月曜日に何をするか

本稿は「プラットフォームエンジニアリングをやめろ」ではありません。導入率が90%の状況で、それは無意味な助言です。ただし、これらの研究をきちんと読み解くと、実務で使えるものがいくつか出てきます。

自分たちのデータを測定してください。 これが最初にして最も重要な項目です。DORAの標本にあなたの会社は入っていません。そして調査の「処理量」と、あなたのCIログのデプロイ回数は別物です。幸い後者は直接数えられます。プラットフォーム導入の前後でチームごとのデプロイ頻度と変更失敗率を実際に測定すれば、他人のリッカート尺度よりはるかに良い根拠が得られます。

排他性を強制しないでください。 データの中で最も行動可能な項目です。プラットフォームだけを使うよう求められた回答者は、処理量6%減少を報告しました。ゴールデンパスは最も楽な道であるべきで、唯一の道である必要はありません。プラットフォームを迂回できるようにしておき、迂回が必要になる瞬間こそがロードマップへの入力です。

ハンドオフを数えてみてください。 DORAの第一の仮説は、処理量の低下をハンドオフの増加で説明しています。これは検証可能です。コミットから本番までの間にシステムとチームの境界を何回越えるか、各境界での待ち時間がどれくらいかを実際に描いてみてください。待ち時間が実行時間を圧倒しているなら、それがあなたの8%です。

開発者の独立性を指標にしてください。 繰り返し現れる信号です。「イネーブリングチームなしでこの作業を終えられるか」は調査なしでも尋ねられますし、チケットシステムから代わりに数えることもできます — プラットフォームチームに入ってくる「これをやってください」チケットの比率が、そのまま独立性の逆数です。2024年リポートがフィードバック収集そのものを成功要因とし、未収集をマイナス要因と挙げているのも同じ文脈です。この話はBackstageでIDPを構築する 1 — ソフトウェアカタログがすべて編でツールの観点から別途扱いました。

不安定性が増えたなら、どちら向きかを見極めてください。 DORAは2つの解釈を両方とも開けたままにしています — 実験が増えて些細な失敗が増えたのか(健全なリスク補償)、それとも悪い変更がそのまま通過しているのか(テストを放置した結果)。これはあなたの組織で確認可能です。失敗した変更の復旧時間とユーザー影響を見てください。早く復旧してユーザーが気づかなかったなら前者に近く、ロールバックが長くて顧客がチケットを開いたなら後者です。

2年目の下落に驚かないでください。 Jカーブは予測されたパターンです。ただし、Jカーブをあらゆる不振の言い訳にするのも問題です — 回復がいつ頃見えるべきかを事前に書き留めておき、その時点で正直に確認してください。

おわりに

本稿で言いたいことは一つです。私たちの業界で最も頻繁に引用されるプラットフォームエンジニアリングの根拠は、アンケートです。自己報告された認識を、確率標本ではない集団から、ある一時点で集めたものです。そして、そのアンケートを作った人々自身が、私たちよりもはるかによくその事実を分かっているので、2025年には「効果」という語を一切使わないことにしました。

ところが、そのリポートがカンファレンススライドや社内提案書に移されるときは、いつも因果文になります。「DORAによれば、プラットフォームは組織成果を6%高めます。」原文にはそうは書かれていません。

同時に、逆方向の過剰補正にも警戒すべきです。「アンケートだから無意味だ」というのも間違いです。5,000人の実務者が一貫して同じ方向を報告していること自体が情報です。プラットフォームと不安定性の関連が2024年と2025年にわたって再現されたことも情報です。ただ、その情報は「何が何を引き起こしたか」を教えてはくれない、というだけです。

最も誠実な態度は、DORA自身の態度をそのまま借りることのようです — 私たちは比較をしており、因果構造は分からず、仮説は複数あり、そのうちの一つは矢印が逆かもしれない。その上で私たちがすべきことは、他人のアンケート数字を引用する代わりに、自分の組織で数えられるものを数えることです。