DORA Metrics は、DevOps Research and Assessment(DORA)チームが長年の研究を通じて確立した、ソフトウェアデリバリーのパフォーマンスを測定するためのフレームワークです。スループット(Throughput) と 安定性(Stability) の両面からチームを評価し、ビジネス成果との相関を可視化します。
もともとは「Four Keys」と呼ばれる 4 指標で構成されていましたが、現在の DORA 公式ガイドでは Deployment Rework Rate が追加され、5 つの指標で構成されています。
| 指標 | 概要 | カテゴリ |
|---|---|---|
| デプロイ頻度(Deployment Frequency) | 一定期間内のデプロイ回数、またはデプロイ間隔 | スループット |
| 変更のリードタイム(Change Lead Time) | 変更が commit されてから本番環境にデプロイされるまでの時間 | スループット |
| デプロイ失敗からの復旧時間(Failed Deployment Recovery Time) | 即時対応が必要となった失敗デプロイから復旧するまでの時間 | スループット |
| 変更失敗率(Change Fail Rate) | デプロイ後に即時対応(ロールバックやホットフィックスなど)が必要となった割合 | 安定性 |
| デプロイ手戻り率(Deployment Rework Rate) | 本番のインシデントが原因で発生した計画外デプロイの割合 | 安定性 |
組織が本番環境へどれだけ高頻度にデプロイできているかを示す、スループットの指標。
- 定義: 一定期間内のデプロイ回数、またはデプロイ間隔
- 測定内容: 本番環境へのデプロイがどれくらいの頻度で実施されているか
- 意味すること: 小さな変更を継続的に届けられているか。リリースが大きく低頻度になると、品質や復旧時間にも悪影響が出やすい
コードが書かれてからユーザーに届くまでのスピードを測る、スループットの指標。
- 定義: 変更が commit されてから本番環境にデプロイされるまでの時間
- 測定内容: コード変更が commit されてから本番環境で稼働するまでにかかる時間
- 意味すること: CI/CD、レビュー、テスト、デプロイの各工程がスムーズに流れているか
失敗したデプロイからどれだけ早く立ち直れるかを測る、スループットの指標。
- 定義: 即時対応が必要となった失敗デプロイから復旧するまでの時間
- 測定内容: 失敗デプロイ発生から復旧までにかかる時間
- 意味すること: 障害は必ず起きる前提で、ロールバック・モニタリング・オンコール体制が機能しているか
旧称は「サービス復元時間(Time to Restore Service)」で、当時は安定性側に分類されていました。現在のガイドではスループット側へ再整理されています。
リリースの品質を測る、安定性の指標。
- 定義: デプロイ後に即時対応(ロールバックやホットフィックスなど)が必要となった割合
- 測定内容: 本番で即時対応を要したデプロイの比率
- 意味すること: 速度を優先するあまり品質が犠牲になっていないか、テスト・レビュー・段階的リリースが機能しているか
本番運用中に顕在化した問題から発生する「計画外デプロイ」を測る、安定性の指標。最新の DORA ガイドで追加された 5 番目の指標です。
- 定義: 本番のインシデントが原因で発生した計画外デプロイの割合
- 測定内容: 計画されたリリース以外で、本番障害起因に押し出されるデプロイの比率
- 意味すること: リリース時のテストや運用設計が、本番で起きる問題をどれだけ事前に捕捉できているか
5 つの指標は「スループットの 3 指標」と「安定性の 2 指標」をセットで見ることに意味があります。どちらか一方だけを最適化しても、もう一方が犠牲になりやすいためです。
| 軸 | 指標 |
|---|---|
| スループット(Throughput) | デプロイ頻度 / 変更のリードタイム / デプロイ失敗からの復旧時間 |
| 安定性(Stability) | 変更失敗率 / デプロイ手戻り率 |
DORA の研究では、速度と安定性はトレードオフではなく、ほとんどのチームで相関している ことが繰り返し示されています。ハイパフォーマンスチームは 5 指標すべてで優れ、ローパフォーマンスチームは全体的に低い、というのが代表的な傾向です。
ただし、5 つの指標を改善しても、それだけでは組織の成果には直結しません。2022 年の State of DevOps Report では、DORA Metrics 改善の効果に重要な前提条件があることが示されています。
組織のパフォーマンスに対するソフトウェア デリバリーの影響は信頼性に基づいています。信頼性が高い場合、高パフォーマンスのソフトウェア デリバリーから、組織にとってより良い成果が予測できます。一方、信頼性が低いと、ソフトウェア デリバリーを改善しても組織の成果には何らの影響もなく、場合によってはマイナスの効果さえ生じます。
つまり、DORA Metrics を測って改善する取り組みは、サービスとしての信頼性(Reliability) が一定水準で担保されている土台の上で初めて成果に結びつきます。デリバリーの速度・安定性を磨く前提として、信頼性指標の状況もあわせて確認することが重要です。
- 可用性(Availability)
- レイテンシ(Latency)
- 正確性(Accuracy)
など
DORA は、メトリクス導入時にチームが陥りやすい典型的な落とし穴として以下 7 つを挙げています。
- メトリクスを目標化してしまう — グッドハートの法則を無視して「年内に全アプリで 1 日複数回のデプロイ」のような大雑把な目標を掲げると、チームが数値合わせに走りやすくなる
- 単一の指標に依存する — 複雑なシステムを単一指標で測るのは誤り。互いに健全な緊張関係を持つ複数の指標を選ぶ(組織目標に合った計測フレームワークを選ぶ)
- 業界を理由に改善を諦める — 例: 規制の厳しい業界のチームが「コンプライアンス要件があるため現状を変えられない」と主張するケース
- 異質なアプリ同士を比較する — 指標はアプリケーション／サービス単位で適用するもの。性質の大きく異なるアプリ（例: モバイルアプリとメインフレーム）の数値を比較するのは誤解を招く
- オーナーシップをサイロ化する — 5 指標を開発・運用・リリースの全チームで共有することで、協働とデリバリープロセスへの共同オーナーシップが育つ。チームごとに特定の指標を割り当てて分断すると、摩擦や責任のなすり合いを招く
- チーム間で競争させる — 目的は他チームや他組織との競争ではなく、時間をかけて自チームのパフォーマンスを向上させること。指標は成長領域の特定と進歩の称賛のためのガイドとして使う
- 改善を犠牲にして計測に注力する — 指標に必要なデータは今日では様々な場所から入手できる。正確なデータを得るために複数システムとの連携を構築するのは初期投資に見合わないかもしれず、まずは話し合い・DORA Quick Check・連携機能が組み込まれたソースアベイラブル／商用製品から始めるほうがよい
DORA の研究 は本ガイドの 5 指標だけにとどまらず、高パフォーマンスを支えるさまざまなケイパビリティ(capabilities) を扱っています。各ケイパビリティがソフトウェアデリバリーに与える影響については、以下のページから掘り下げられます。
- Capability catalog — ハイパフォーマンスに寄与するケイパビリティのカタログ
本ガイドで取り上げた 5 指標を改善する一般的なアプローチは、アプリケーションの 変更バッチサイズの縮小 です。変更が小さいほど、合理化しやすく、デリバリープロセスを通すのも失敗時の復旧も容易になります。各変更をできる限り小さく保つことが、変更のスループットと安定性の両方に寄与します。
効果的なやり方は、優先順位付け・構築・デリバリー・運用に責任を持つクロスファンクショナルなチームを集めて、ソフトウェアデリバリーのパフォーマンス改善について話し合うことです。チームが集まったら、以下のステップを進めます:
- ベースラインを設定する — DORA Quick Check でアプリケーションの現状を把握する
- 対話する — デリバリープロセス上の摩擦点について話し合う。デリバリープロセスをマッピングすると議論が進めやすい
- チーム全体で改善にコミットする — 最も大きな制約・ボトルネックに対して
- そのコミットメントを計画に落とし込む — ソフトウェアデリバリー指標のリード指標として機能する具体的な計測項目（例: コードレビューの所要時間、テストの品質）を含めてもよい
- 実行する — 近道はほとんどなく、進歩のためにはチームの働き方を変える必要があるかもしれない
- 進捗を確認する — DORA Quick Check・対話・チームのレトロスペクティブを使って検証する
- 繰り返す — 学習と改善を継続するためにプロセスを繰り返す
組織で DORA メトリクスを実践するためのディスカッションは、DORA Community で日々行われています。