DORA指標 2026：デリバリーを本当に測る4つの指標。

なぜDORA metricsが必要か、なぜ今なのか

なぜDORA指標か、なぜ今か

エンジニアリングチームのパフォーマンスをコード行数やstory pointsで測定するのは、車の速度をエンジン音で測るようなものだ。DORA metrics — GoogleのDevOps Research and Assessmentプログラムから生まれ、書籍Accelerateで広まった — は別のアプローチを提案する：本当に重要なこと、つまりチームが速く、壊さずに変更を届ける能力を見る4つの指標だ。

エンジニアリングチームの成果をコード行数やストーリーポイントで測るのは、車の速度をエンジン音で測るようなものです。DORA指標——GoogleのDevOps Research and Assessmentプログラムに由来し、書籍『Accelerate』で広まりました——は別のものを提案します。本当に重要なこと、つまり「壊さずに速く変更を届ける力」を見る4つの指標です。

その強みは簡潔さにある。4つの数値、2つの軸：速度（どれだけ速く届けるか）と安定性（届ける際にどれだけ壊すか）。この2つから選ばなければならないという神話は誤りだ — Eliteチームはより速く、かつより安定している。DORA metricsが可視化するのは、まさにこの事実だ。

その強みは無駄のなさにあります。4つの数字、2つの軸。スピード（どれだけ速く届けるか）と安定性（届ける際にどれだけ壊すか）。両者はトレードオフだという神話は誤りです。Eliteチームは速さと安定性を同時に達成しています。DORA指標はまさにこの事実を見える化します。

4つの指標、具体的に

4つの指標を具体的に

2つはスループットを、2つはレジリエンスを測定する。組み合わせることで、デリバリー全体の状況を語る。

2つはスループットを、2つは回復力を測ります。組み合わせると、デリバリーの全体像が見えてきます。

• Lead time for changes — commitがマージされてから本番環境にデプロイされるまでの時間。これが最も重要な指標だ：CI、テスト、環境、レビュープロセスの品質を集約している。Lead timeが数時間で測定されるなら、パイプラインは健全だ。
• Deployment frequency — 本番環境へのデプロイ回数。Eliteチームはオンデマンドで、1日に複数回デプロイする。頻繁なデプロイはバッチサイズを小さくし、デプロイごとのリスクを下げる。頻度は目的ではなく、小さく届けられるシステムの結果だ。
• Change failure rate — インシデント（rollback、hotfix、サービス劣化）を引き起こすデプロイの割合。プッシュする内容の品質を測定する。月に1回しかデプロイしない状況で低い率を達成しても、印象的ではない：常に頻度と合わせて読む必要がある。
• Mean time to restore (MTTR) — インシデント後、正常に戻るまでの平均時間。これは謙虚さの指標だ：インシデントは起こるという前提で、それに耐える能力を測定する。短いMTTRは、人為的にゼロのchange failure rateより価値があることが多い。

• リードタイム（Lead time for changes）——マージされたコミットから本番リリースまでの時間。最重要の指標です。CI、テスト、環境、レビュープロセスの質をすべて集約します。時間単位で数えられるリードタイムは、健全なパイプラインの証です。
• デプロイ頻度（Deployment frequency）——本番へのデプロイ回数。Eliteチームはオンデマンドで、1日に何度もデプロイします。頻繁なデプロイはバッチサイズを小さくし、1回あたりのリスクを下げます。頻度は目的ではなく、小さく届けられるシステムの結果です。
• 変更失敗率（Change failure rate）——インシデント（ロールバック、ホットフィックス、サービス劣化）を引き起こすデプロイの割合。届けるものの品質を測ります。月1回のデプロイで得た低い数値に意味はありません。常に頻度と並べて読みます。
• 平均復旧時間（MTTR）——インシデント後に正常へ戻るまでの平均時間。謙虚さの指標です。インシデントは起きるものという前提に立ち、それを吸収する力を測ります。短いMTTRは、ゼロでも見せかけの変更失敗率よりしばしば価値があります。

DORAはチームをLow、Medium、High、Eliteの4段階に分類する。重要なのはEliteバッジを獲得することではなく、自分たちがどこにいて、トレンドがどの方向を指しているかを知ることだ。6ヶ月でLowからHighに移行するチームは、固定されたスコアより多くを語る。

DORAはチームを4段階——Low、Medium、High、Elite——に分類します。狙いはEliteバッジの獲得ではなく、今どこにいて、傾向がどちらを向いているかを知ることです。半年でLowからHighへ進んだチームは、固定されたスコアよりもはるかに多くを物語ります。

過度な複雑化を避けて計装する

大掛かりな仕組みを作らずに計測する

典型的な間違い：最初の数値を得る前に、完全なobservabilityプラットフォームを構築しようとすること。我々は逆を行う。データはすでに存在し、手元にある3つのソースに分散している。

よくある失敗は、最初の数字を得る前に完全な可観測性プラットフォームを欲しがることです。逆をやりましょう。データはすでに、手元にある3つのソースに散らばって存在しています。

1. Gitとci/cdで速度を — mergeのタイムスタンプとパイプライン（GitHub Actions、GitLab CI、ArgoCD）のデプロイイベントから、lead timeとdeployment frequencyが直接得られる。開始するためにサードパーティツールは不要だ。
2. インシデントトラッカーで安定性を — 各インシデントをそれを引き起こしたデプロイに紐付けることで、change failure rateとMTTRを計算できる。チケットに簡単なタグ付け規則があれば十分だ。
3. 最小限のダッシュボード — 指標ごとに1つのグラフ、週次または月次のトレンドで読む。これで全てだ。専用ツール（LinearB、Swarmia、Sleuth）は、文化が定着してから導入する、その前ではない。

1. スピードはGitとCI/CDから——マージのタイムスタンプとパイプライン（GitHub Actions、GitLab CI、ArgoCD）のデプロイイベントから、リードタイムとデプロイ頻度が直接得られます。始めるのにサードパーティのツールは不要です。
2. 安定性はインシデント管理から——各インシデントを原因となったデプロイに紐づければ、変更失敗率とMTTRを算出できます。チケットへのシンプルなタグ付けルールで十分です。
3. 最小限のダッシュボード——指標ごとに1つのグラフ、週次または月次の傾向として読む。それだけです。専用ツール（LinearB、Swarmia、Sleuth）の出番は、文化が根付いた後であり、その前ではありません。

Abbealのルール：まず既存パイプラインから推測できるものを計装し、チームが毎週数値を見てさらに進みたいと思った時だけツールを追加する。見られるダッシュボードは、忘れ去られたプラットフォームより価値がある。

Abbealのルールは、まず既存のパイプラインから導けるものを計測し、チームが毎週数字を見てさらに先へ進みたくなったときだけツールを足す、というものです。実際に見るダッシュボードは、忘れられたプラットフォームに勝ります。

落とし穴：vanity metricsとgaming

落とし穴：虚栄の指標とゲーミング

指標が目標になった瞬間、それは良い指標ではなくなる — これはGoodhartの法則で、DORA metricsも例外ではない。どこにでも表示する前に知っておくべき、いくつかの歪み。

指標が目標になった瞬間、それは良い指標ではなくなります——これがグッドハートの法則であり、DORA指標も例外ではありません。あらゆる画面に表示する前に知っておくべき罠を挙げます。

• 単独の頻度はvanity metricだ。1日40回デプロイしても、半分がhotfixなら何も語らない。頻度は常にchange failure rateと合わせて読む必要がある。
• Gamingはすぐに起こる。頻度を増やすために人為的にPRを分割したり、change failure rateを守るために小さなインシデントを宣言しなかったり：数値を個人評価に変えた瞬間、これらは人間的な反射になる。
• 個人レベルでは決して使わない。DORA metricsはチーム単位、プロダクト単位、トレンドで読む。開発者を評価または比較するために使うと、数週間で信頼とデータ品質を破壊する。
• 写真は映画ではない。ある瞬間の数値は無価値だ。重要なのは方向性：改善しているか、次のステップを阻んでいるものは何か？

• 頻度単体は虚栄の指標です。半分がホットフィックスなら、1日40回のデプロイは何も語りません。頻度は変更失敗率と並べずに読んではいけません。
• ゲーミングはすぐ起きます。頻度を水増しするためにPRを不自然に分割する、変更失敗率を守るために小さなインシデントを申告しない——数字が個人の評価になった瞬間に現れる人間の反射です。
• 個人単位では決して使わない。DORA指標はチーム単位、プロダクト単位、傾向として読みます。開発者の評価や比較に使うと、数週間で信頼とデータの質を壊します。
• スナップショットは映画ではありません。ある一点の数字には価値がありません。重要なのは方向です。改善しているか、次の一段を阻んでいるものは何か。

本当の課題：プロダクトパフォーマンスとの関連

本質：プロダクト成果との関係

DORA metricsはエンジニアリングコンテストではない。そのビジネス上の意義は、組織のパフォーマンスと相関することだ：速く安定して届けるチームは、プロダクトのフィードバックループを短縮する。アイデアをテストし、測定し、調整する — 四半期に1回ではなく、週に複数回。

DORA指標はエンジニアリングの美人コンテストではありません。ビジネス上の価値は、組織のパフォーマンスと相関する点にあります。速く安定して届けるチームは、プロダクトのフィードバックループを短くします。アイデアを試し、測定し、調整する——四半期に一度ではなく、週に何度も。

短いlead timeは技術的な贅沢ではない：プロダクトがユーザーから学ぶ速度だ。管理されたMTTRは、家を危険にさらさずに何かを試せる自信だ。これがDORA metricsをエンジニアリングとプロダクト間の共通言語にする理由で、story pointsはエンジニアにしか語らない。

短いリードタイムは技術的な贅沢ではありません。プロダクトがユーザーから学ぶ速度そのものです。制御されたMTTRは、家を賭けずに何かを試せる安心感です。これこそが、ストーリーポイントがエンジニアにしか通じないのに対し、DORA指標をエンジニアリングとプロダクトの共通言語にしている理由です。

4つの鍵を超えて：reliabilityとSPACE

4つのキーの先へ：reliabilityとSPACE

4つの指標はデリバリーのスループットと安定性を測定する — 認識される運用信頼性、実際に生み出される価値、チームの健全性は測定しない。DORAは後に5番目の次元、reliability（SLO/SLIの系統でサービス目標を達成する能力）を追加し、本番稼働の死角を埋めた。

4つの指標はデリバリーのスループットと安定性を測りますが、運用上の信頼性、実際に生み出した価値、チームの健全性は測りません。DORAはその後、本番運用の死角を埋めるために5つ目の次元としてreliability（SLO/SLIに沿った、サービス目標を満たす力）を追加しました。

そして4つの鍵が見ないもの — 満足度、コラボレーション、認知負荷 — に対しては、SPACEフレームワークが自然な補完だ。DORA metricsは最良の出発点であり続ける：まずこれから始め、その後拡張する、決して逆ではない。

そして4つのキーが見ないもの——満足度、協働、認知負荷——を補う自然な相棒がSPACEフレームワークです。それでもDORA指標は最良の出発点です。まずDORAから始め、その後に広げる。逆ではありません。

Abbealがスクワッドでどう活用しているか

Abbealはスクワッドでどう使っているか

Abbealでは、DORA metricsは担当領域を引き受ける際のデフォルトの計器盤だ。Staff augmentationでもturnkeyデリバリーでも、印象ではなく数値化された現実でチームとクライアントを整合させる言語だ。

Abbealでは、ある領域のオーナーシップを引き受けるとき、DORA指標が標準のダッシュボードです。スタッフオーグメンテーションでも、ターンキーのデリバリーでも、印象ではなく測定された現実でチームとクライアントを揃える共通言語になります。

我々のFollow-the-Sunモデル — Paris、Montréal、Tokyoで同期されたハブ — は追加要件を課す：24時間進むロードマップは、ハンドオフがクリーンでデリバリーが継続的な場合にのみ機能する。Lead timeとdeployment frequencyは、タイムゾーン間のオーバーラップが機能しているか、隠れたキューを作っているかを正確に明らかにする数値だ。

私たちのFollow-the-Sunモデル——パリ、モントリオール、東京の同期されたハブ——は1つの要件を加えます。24時間365日進み続けるロードマップは、ハンドオフがクリーンで、デリバリーが継続している場合にのみ成立します。リードタイムとデプロイ頻度こそ、タイムゾーン間の重なりが機能しているのか、それとも見えない待ち行列を生んでいるのかを明らかにする数字です。

我々は要求の厳しい状況で経験している — 銀行、高トラフィックのリテール — デプロイごとに重要で、インシデントがユーロで測定される場所だ。Montréal/Parisハブを持つモビリティscale-upでは、observabilityとインフラ（GreenOps側）の作業がインフラコスト-30%とより良いレジリエンスに変換された：DORA metricsが可読化しビジネスに対して弁護可能にする利益だ。

これは要求の厳しい現場——銀行、トラフィックの多い小売——で実感してきました。1つ1つのデプロイが重く、インシデントがユーロで測られる世界です。モントリオール／パリのハブを持つモビリティのスケールアップでは、可観測性とインフラ（GreenOps側）への取り組みがインフラコスト30%削減とレジリエンス向上につながりました。DORA指標は、こうした成果をビジネスに対して読み取れ、説明できるものにします。

我々の信念：DORA metricsは経営陣を安心させるダッシュボードではなく、次に何を改善すべきかを決定するエンジニアのツールだ。スクワッドのデリバリー健全性を監査したり、クリティカルな範囲でこの運営を確立したいか？それはまさに我々が手掛けるタイプのプロジェクトだ。短い定義とLow/Medium/High/Eliteのレベルについては、用語集ページDORA metricsも参照：/fr/glossaire/dora。

私たちの信念はこうです。DORA指標は経営を安心させるためのダッシュボードではなく、次に何を改善するかを決めるためのエンジニアの道具です。スクワッドのデリバリーの健全性を監査したい、あるいは重要な領域でこうした舵取りを導入したい——それはまさに私たちが手がける仕事です。短い定義とLow/Medium/High/Eliteの段階については、DORA指標の用語集ページもご覧ください：/ja/glossaire/dora。