DORAの4指標は「速さ」を測る共通言語になりました。しかし指標だけを追うと現場は疲弊します。SPACE、DevEx、Platform as a Productまで含めて、日本のチームでどう使うかを一次情報で整理します。
01「速さ」を数字で語れるようにしたDORA
大手SIerやエンタープライズの現場で「デリバリーが遅い」「品質が不安定だ」という議論は絶えません。ところがその議論は、往々にして声の大きい人の印象論で決着してしまいます。DORA(DevOps Research and Assessment)が10年かけて確立した4つの指標は、この印象論に共通の物差しを与えました。シリコンバレーでは、経営層と現場が同じ数字を見て投資判断をする文化が先に定着しています。日本のエンタープライズにこれを橋渡しするのが本記事の狙いです。
DORAのFour Keys(4つの主要指標)は、大きく「スループット(速さ)」と「安定性」の2軸に分かれます。速さだけを追わず、安定性とセットで見る——ここが最初の勘所です。
- デプロイ頻度(Deployment Frequency)：本番へどれくらいの頻度でリリースできているか。スループット側。
- 変更のリードタイム(Lead Time for Changes)：コードをコミットしてから本番稼働までの時間。スループット側。
- 変更失敗率(Change Failure Rate)：本番反映のうち、障害・ロールバック・修正を要した割合。安定性側。
- 復旧時間(Failed Deployment Recovery Time)：不具合のあるデプロイから正常状態に戻るまでの時間。安定性側。旧称は「サービス復旧時間」です。
022024年DORAレポートが示した3つの意外な事実
DORAは毎年Accelerate State of DevOps Reportを公開しています。2024年版は調査10周年の節目で、実務者が知っておくべき示唆がいくつもありました。特に日本のエンタープライズが誤解しやすい点を3つ挙げます。
- AI導入は諸刃の剣：AIツールは個人の生産性・フロー・満足度を高める一方で、ソフトウェアデリバリーの安定性とスループットにはマイナスの相関が観測されました。「AIを入れたら速くなる」という単純な期待は、レポートの実データとは食い違います。
- 内製プラットフォームも万能ではない：内部開発者プラットフォーム(IDP)は個人・チーム・組織のパフォーマンスを押し上げる一方、変更の安定性とスループットを一時的に下げうると報告されています。導入初期の学習コストを織り込む必要があります。
- ユーザー中心性が効く：誰のために作っているかがチームに共有されているほど、パフォーマンスが高い傾向が示されました。技術論だけでなく「顧客に向いているか」が効くという、地に足のついた結論です。
さらに2024年版では、ユーザー向けの不具合対応で生じる計画外デプロイを測る「リワーク率(rework rate)」という新しい観点も紹介されました。速さの裏で、どれだけ手戻りが起きているかを可視化する発想です。
034指標だけでは足りない — SPACEという広角レンズ
DORAは強力ですが、測っているのは「デリバリーのパイプライン性能」です。開発者が実際に生産的か、満足しているかまでは捉えきれません。ここを補うのがSPACEフレームワーク(2021, ACM Queue)です。DORAの生みの親でもあるNicole Forsgren氏らが提唱した、5つの次元からなる考え方です。
- Satisfaction and well-being(満足度と健全性)
- Performance(成果)
- Activity(活動量)
- Communication and collaboration(コミュニケーションと協働)
- Efficiency and flow(効率とフロー)
SPACEの核心は「単一指標で生産性を測るな」という一点です。コミット数や消化ベロシティといった1つの数字だけを追うと、必ず現実が歪みます。SPACEは「複数の次元から、少なくとも定量と定性の両方を組み合わせて見る」ことを求めます。DORAが客観的なパイプライン指標なら、SPACEはそこに満足度や協働といった人間側の視点を足す広角レンズだと捉えると整理しやすいです。
04DevEx — 「体験」を改善レバーに変える
SPACEは「何を測るか」の枠組みですが、現場が本当に知りたいのは「では何を直せば速くなるのか」です。それに答えるのがDevEx: What Actually Drives Productivity(2023, ACM Queue)です。Abi Noda氏・Forsgren氏らが、開発者体験を3つの改善レバーに集約しました。
- フィードバックループ(Feedback Loops)：ビルド、テスト、レビュー、デプロイの応答がどれだけ速いか。CIが30分かかるチームは、それだけで待ちの時間が積み上がります。
- 認知負荷(Cognitive Load)：作業を進めるのに必要な頭の負担。複雑なデプロイ手順、散らばったドキュメント、把握しきれない依存関係が該当します。
- フロー状態(Flow State)：深い集中が保てるか。会議の細切れ、頻繁な割り込み、環境構築の失敗が集中を壊します。
DevExの実務的な価値は、「開発者が感じている摩擦(friction)」を起点に投資先を決められる点にあります。DORAのリードタイムが長い、という数字を見たとき、その原因がCIの遅さ(フィードバックループ)なのか、リリース手順の複雑さ(認知負荷)なのかで打ち手はまったく変わります。DevExの3レバーは、DORAの数字を「何を直すか」に翻訳する接続点になります。
05DORA・SPACE・DevExの関係を1枚で理解する
3つの枠組みは競合ではなく、レイヤーが違います。DORAはデリバリーの結果、SPACEは生産性の全体像、DevExは改善レバー。この重なりを押さえると、社内でどれを使うかの議論が噛み合います。
06Platform as a Product — 速さを組織で再現する
DevExの3レバー、とりわけ認知負荷とフィードバックループを組織的に下げる手段が、内製プラットフォーム(IDP)です。ただし箱を作れば終わりではありません。海外で定着した規律がPlatform as a Product(プラットフォームを製品として扱う)です。Thoughtworksが早くから提唱し、Team Topologiesの文脈でも中核概念になっています。
要点は、社内の開発者を「顧客」と見なし、外販プロダクトと同じ規律で運営することです。ゴールデンパス(推奨される標準的な進め方)を敷き、セルフサービスで使えるようにし、利用実態を見て継続的に改善する。「使われないプラットフォームは失敗」という当たり前の基準を、社内ツールにも適用します。第2章で触れたとおり、DORA 2024もIDPが初期に安定性を下げうると報告しており、プロダクトとして地道に磨く前提が要ります。
プラットフォーム観点の周辺トピックは、プラットフォームエンジニアリングの記事でも掘り下げています。
07日本のチームでどう使い始めるか
フレームワークを一度に全部入れる必要はありません。エンタープライズの現場で無理なく回すなら、次の順序が現実的です。
- まず4指標を1チームで計測：全社展開の前に、1つのプロダクトチームでDORAの4指標を可視化します。ツールを入れずとも、デプロイ記録とチケットから手作業で四半期集計するだけでも出発点になります。
- 数字を評価に直結させない：DORAをチーム間の順位付けや個人評価に使った瞬間、数字の操作(ゲーミング)が始まります。SPACEが警告する「単一指標の歪み」そのものです。あくまで改善のための対話材料に留めます。
- リードタイムの内訳をDevExで分解：遅さの原因がCI待ち(フィードバックループ)か、手順の複雑さ(認知負荷)か、割り込み(フロー阻害)かを切り分け、いちばん効くレバーから手を付けます。
- 定性の声を必ず1本足す：四半期に一度、開発者への簡単なアンケート(満足度、最大の摩擦)を取ります。定量ダッシュボードだけでは、現場の本当の詰まりは見えません。
- 横展開の段でIDPを検討：複数チームで共通の摩擦が見えてきたら、それをPlatform as a Productとして標準化します。順序を逆にして先にプラットフォームから作ると、使われない箱になりがちです。
DORAが日本で誤用される典型は「デプロイ頻度を上げろ」という号令だけが独り歩きするパターンです。速さは安定性・体験・組織の仕組みと一体で初めて再現します。指標は目的ではなく、対話と改善のための共通言語だと位置づけてください。運用・監視の指標設計全般は監視・アラート設計も参考になります。
—まとめ
DORAの4指標は「速さ」を語る共通言語を与えました。しかし速さだけを追えば、安定性も開発者体験も損なわれます。SPACEで多面的に俯瞰し、DevExで摩擦を改善レバーに翻訳し、Platform as a Productで組織に再現する——この4つを層として使い分けるのが、海外の先行事例から日本のエンタープライズに橋渡しできる実務知です。まずは1チームで4指標を測り、評価に直結させず、定性の声を1本添える。ここから始めれば無理がありません。