DORAメトリクスとは？開発チームが知るべき4つの指標

DORAメトリクスとは？開発チームが知るべき4つの指標

DORAメトリクスについて聞かれたら、シンプルな答えがある：これはソフトウェアデリバリーのパフォーマンスを測定する4つの指標だ。デプロイメント頻度、変更のリードタイム、変更失敗率、サービス復旧時間。Nicole Forsgren、Jez Humble、Gene Kimによって開発され、数万のエンジニアリングチームで検証され、2018年にGoogleに買収された。このガイドでは各メトリクスが何を追跡するか、実際のベンチマークがどのように見えるか、そしてこのモデルの限界がどこにあるかをカバーする。

DORAメトリクスが生まれた背景と研究が重要である理由

DORA プログラムは2014年に始まった。1つの問いかけからだ：高いパフォーマンスを発揮するソフトウェアチームは他のチームと何が違うのか？リサーチチームは毎年、業界全体の数万人の開発者にアンケートを実施し、強いソフトウェアデリバリーの成果を予測する慣行を探していた。

研究を象徴づけた発見は直感に反していた。トップチームはスピードと安定性をトレードオフしていなかった。彼らはより速くリリースし、本番環境でのインシデントはより少なかった。その結果は、リリースサイクルを遅くすることの標準的な言い訳（デプロイが少なければ、問題も少なくなる）を覆した。

データは逆を示していた。頻繁にデプロイするチームはより良いフィードバックループを構築し、問題をより早く検出し、何かが間違ったときにはより速く復旧した。スピードと安定性は対立していなかった。むしろ相関していた。

Googleは2018年にDORAプログラムを買収した。チームは今、毎年State of DevOps Reportを公開し、2025年にモデルを5番目のメトリクス（Rework Rate）で更新し、dora.devでオープンイニシアチブとして研究を維持している。

4つの測定指標と各々が実際に追跡するもの

モデルは2025年にRework Rateを5番目のメトリクスとして追加するために更新されたが、元々の4つの主要指標は今なお、ほとんどのツーリングとチームの議論における基本線のままである。

デプロイメント頻度（Deployment Frequency）

チームが本番環境にプッシュする頻度。これが定義の全てだ。

トップチームはオンデマンドでデプロイする：何かが準備できたら、1日に複数回。低パフォーマンスチームは月1回以下、時には数ヶ月ごと。ソロビルダーなら、一貫性のある週単位のリリースペースなら、この単一の測定だけでも十分にハイパフォーマー層に入る。

デプロイメント頻度はパイプラインの自信度の代理指標だ。頻繁にデプロイしないチームは通常、脆弱なインフラ、重い手動テストゲート、リリースを低速化する組織的な承認チェーンを持っている。1日に複数回リリースするチームはそれらのボトルネックの大部分を自動化で取り除いている。頻度は原因ではなく、症状だ。

変更のリードタイム（Lead Time for Changes）

コミットがバージョン管理に到達してから、その同じ変更が本番環境でライブになるまでの時間。

この期間の大部分はコード書きではない。待機だ：プルリクエストキューがクリアされるのを待つ、CI/CDパイプラインが終了するのを待つ、デプロイスロットを待つ、リリースをトリガーするアクセス権を持つ誰かを待つ。数時間のリードタイムはワークフローがタイトで大部分が自動化されていることを意味する。数週間単位で測定されるリードタイムは、1つ以上のハンドオフポイントで構造的な摩擦を加えていることを意味する。

ソロ開発者にとって、リードタイムはコミットをプッシュしてからユーザーが結果を見るまでの間に立つもの何もかもだ。時にはそれは12分かかるデプロイパイプラインだ。時にはそれは変更が安定かつシップ可能かについての内部的な躊躇だ。

変更失敗率（Change Failure Rate）

ホットフィックス、ロールバック、またはインシデント対応を必要とするほど深刻な問題を引き起こすデプロイメントの割合。

これはDORAモデルにおける品質シグナルだ。2024年のState of DevOps Reportではトップチームが約5%の変更失敗率にある。低パフォーマンスチームは46〜63%で実行している。デプロイの約半分が即座の介入を必要とするなら、テストカバレッジとレビュープロセスに大きな構造的ギャップがある。

変更失敗率は抽象的なコード品質を測定しない。本番環境でも期待通りに動作するかを測定する。ローカルではパスするが本番で失敗するインテグレーションパスをカバーしていないテストスイートはこの数字を動かさない。

サービス復旧時間（Time to Restore Service）

デプロイメントがインシデントを引き起こした場合、サービスが復旧するまでどのくらいの時間がかかるか？

これはもともとMean Time to Recovery（MTTR）とラベル付けされていた。DORAチームは2025年にフレーミングをFailed Deployment Recovery Timeに更新し、インフラストラクチャの障害や第三者の停止ではなく、デプロイメント起因のインシデントからの復旧を具体的に追跡している。この区別は重要だ。デプロイメント起因のインシデントはチーム完全にコントロール下にあるため、プロセス改善の正当なターゲットだからだ。

トップチームは1時間以内にサービスを復旧させる。低パフォーマンスチームは数日から1週間かかることもある。ソロビルダーなら、このメトリクスはあなたがモニタリング体制を整えているかのほぼ全てだ。アラート基盤を持たないチームはユーザー苦情から障害を知る。これは復旧時間に数時間を加える。

パフォーマンス層が実際にどのように見えるか

State of DevOpsレポートはチームをDORA数値に基づいて4つのティアにグループ分けしている。2024年レポートからの大まかな範囲は以下の通りだ。

トップティアのチームは1日に複数回デプロイし、リードタイムは1時間未満、変更失敗率は5%未満、復旧時間は1時間未満だ。高パフォーマンスチームは日〜週単位でデプロイ、リードタイムは1日〜1週間、失敗率は5-10%、復旧時間は1日未満。中程度のチームは週〜月単位でデプロイ、リードタイムは1週間〜1ヶ月、失敗率は10-15%、復旧時間は1日〜1週間。低パフォーマンスチームは月1回以下のデプロイ、リードタイムは1〜6ヶ月、失敗率は46-63%、復旧時間は1週間〜6ヶ月だ。

トップと低の間のギャップは漸進的ではない。2024年レポートによれば、低パフォーマンスチームはトップチームよりもデプロイに180倍以上の時間がかかり、インシデント復旧には2500倍以上の時間がかかる可能性がある。これは周辺的な違いではない。

トップティアに到達することはCI/CD自動化、テストカバレッジ、観測可能性ツーリングへの継続的な投資で達成可能だ。コードをより速く書くことでは起きない。コミット後のデプロイから本番環境での信頼性ある実行の間の手動ステップと待機時間を取り除くことで起きる。

AI開発ツールが2026年のDORA数値をどのようにシフトさせているか

2026年までに、AIコーディングツールは十分に一般的になり、DORAメトリクスに追跡する価値のある方法で影響を与えている。

Cursor、GitHub Copilot、または類似のツールを使用するチームはコードをより速く書いており、これはデプロイメント頻度を上げる傾向がある。リードタイムも多くのチームで短縮された。開発者1人当たり1週間でより多くのコードが生成されるということは、パイプラインを通過するコミットが増えるからだ。

変更失敗率は双方向に動いている。強いレビュープロセスとテストカバレッジを持つチームは、より多くをシップしながら失敗率を安定させている。適切なレビューなしでAI生成コードをシップするチームは失敗率の上昇を見ている。DORAモデルはコードがどのように書かれるかを気にしない。本番環境にデプロイされた後に何が起きるかを測定する。

DORA 2024 State of DevOpsレポートは、調査された回答チームの41%がAI支援開発ツール使用を報告していることを見出した。それらのチーム、AI採用が自動テストとレビューパイプラインとペアになったときに、変更失敗率に見合った増加なしにより高いデプロイメント頻度を示した。

実際のところでつまずくこと：AIはパイプラインのフロントエンドを大幅に加速させる。DORAはその加速が下流でクリーンに吸収されているか、不安定性を作成しているかを教えてくれる。

DORAメトリクスを追跡するツール、スタックを過度に構築しない

ほとんどのチームはDORAメトリクスを測定し始めるため、すでに使用しているツールからデータを引く：デプロイメントイベントとコミットタイムスタンプ用のGitHubまたはGitLab、復旧時間データ用のPagerDutyまたはOpsGenie、変更失敗率カウント用のインシデント管理システム。

複数のプラットフォームはこれら4つのメトリクスの周りに特にDORAダッシュボードを構築している。

ツーリング予算なしのソロビルダーなら：各本番デプロイメントと各復旧イベントのタイムスタンプをログする小さなスクリプトで、インフラコストなしでデプロイメント頻度と復旧時間が得られる。リードタイムはGitログのコミットタイムスタンプから概算できる。

DORAメトリクスが本当の限界を持つ場所

DORAの測定は有用だ。それを完全なエンジニアリングパフォーマンス像として扱うことは、名付ける価値のある複数の特定のブラインドスポットを作成する。

**技術的負債の蓄積。**高いデプロイメント頻度と低い変更失敗率は時間とともにコードベースが扱いにくくなっているかについて何も教えてくれない。チームはトップレベルのDORA数値にヒットしながら、新しいフィーチャーのシップをより遅くする種の負債を着実に蓄積することができる。DORAはデリバリー出力を測定する。デリバリーしているものの状態は測定しない。

**成果アラインメント。**デプロイメント頻度は出力を測定し、結果は測定しない。1日5回のシップは、それらの変更が製品またはビジネスが気にする指標を動かさなければ問題ではない。フィーチャーフラグ、A/Bテストインフラ、ビジネスメトリクスのトラッキングはDORAモデルの完全に外側にある。

**サスティナビリティ。**DORAリサーチチームは2023年にフレームワークに開発者体験の側面を追加し、トップレベルのパフォーマンスを達成することは別の場所で燃え尽きていないエンジニアを必要とすることを認めた。4つのコアメトリクスはトップ層の数値を達成することが他の場所で代価を払っているかどうかは追跡しない。

DORAをベースラインの診断ツール、スコアボードとしてではなく使用しよう。メトリクスが発起する問いかけはしばしば数字そのものより実用的だ。30%の変更失敗率はどのタイプの変更が最も失敗するかと理由を知ることより有用でない。

これまでこれらを一度も追跡していない場合、どこから始めるか

DORAデータのない6ヶ月齢のサイドプロジェクトは標準だ。ほとんどの小さなチームとソロビルダーはこれのいずれも測定したことがない。

ゼロから開始するなら、デプロイメント頻度とリードタイムを最初に選びなさい。両者ともGitコミットタイムスタンプとデプロイメントログから簡単に抽出でき、パイプラインが不必要な摩擦を持つかどうかについて即座のフィードバックをくれる。書き込み時間に40分を要した3日のリードタイムは調査する価値のあるシグナルだ。

変更失敗率と復旧時間はインシデントが蓄積してから数字が意味を持つまで必要とする。本番で何かが壊れたら、検出されたタイムスタンプとそれが解決されたタイムスタンプをログしよう。そのデータは時間とともに増加する。

実用的な習慣：本番インシデント後、2つの質問をしよう。この問題を検出するのにどのくらいかかったか？検出から解決までどのくらいか？それら2つの数字は復旧時間の入力だ。それらを一貫して6ヶ月間追跡すれば、復旧プロセスが改善しているか平坦のままかを知るために十分な履歴が得られる。

ソロ開発者としてもDORAメトリクスを測定する3つの理由、気にしない1つの理由：メトリクスは見えない摩擦を見える状態にしている、自動化投資に対する責任を作成している、フィーチャーワーク間で改善する具体的なものをあなたに与えている。気にしない理由：本番ユーザーなしのプレ発売ならば、数字は今のところ意味がない。本当のユーザーに定期的にシップするようになったら測定を開始しよう。

3つの理由がDORAメトリクスを測定する価値がある：メトリクスは見えない摩擦を目に見える形にする、自動化投資への責任を生成する、フィーチャーワークの間で改善する具体的なものを与える。気にしない理由1つ：本番ユーザーなしのプレローンチなら数字は今のところ意味がない。本当のユーザーに定期的にシップしているときに測定を開始しよう。

これは完璧なアイデアではない。実行可能なアイデアだ。