先に結論
DORA指標 は、ソフトウェア開発と運用のパフォーマンスを、どれだけ速く届けられるか と どれだけ安定して届けられるか の両面から見るための指標です。
有名なのは昔からの「4指標」ですが、DORAの整理では現在は5指標モデルとして説明されています。
ざっくり分けると、こうです。
| 観点 | 何を見るか |
|---|---|
| Throughput | どれだけ早く、どれだけ流せるか |
| Instability | どれだけ失敗や手戻りが起きるか |
重要なのは、DORA指標は 開発速度だけを上げるための数字 ではないことです。
速いのに壊れやすい状態も、安定だが全然出せない状態も、どちらも偏っています。DORA指標は、そのバランスを見るためのものです。
この記事では、2026年4月23日時点で DORA 公式の
DORA’s software delivery performance metrics、A history of DORA’s software delivery metrics、Google Cloud の関連資料を確認しながら整理しています。
DORA指標とは何か
DORA は DevOps Research and Assessment の略で、ソフトウェアデリバリーのパフォーマンスを研究してきた取り組みです。
その中で広く知られるようになったのが、ソフトウェアを 速く 安定して 届けられているかを見る指標群です。
昔はよく「Four Keys」として、次の4つで語られてきました。
ただし、DORA公式の最近の整理では、指標の定義や構成が少し進化しています。
現在は5指標モデルとして、Throughput と Instability の2軸で説明されています。
いまのDORA指標
Throughput 側の3つ
1. 変更リードタイム
コード変更が本番へ届くまでの時間です。
コミットから本番デプロイまでをどれだけ速く進められるかを見る、と考えると分かりやすいです。
長すぎる場合は、レビュー待ち、テスト待ち、承認待ち、デプロイ作業の重さがボトルネックになっていることがあります。
2. デプロイ頻度
どれくらいの頻度で本番へ変更を出せているかです。
毎日出せるのか、週1なのか、月1なのかを見るイメージです。
ここで大事なのは、回数が多ければ無条件で良いわけではないことです。
意味のない小出しではなく、必要な変更を小さく安全に出せているかを見る方が実務向きです。
3. Failed Deployment Recovery Time
DORA公式の最近の整理では、昔の MTTR に近い位置づけとして failed deployment recovery time が使われています。
本番変更が失敗したときに、どれくらいの時間で回復できるかを見る指標です。
つまり、速く出せるだけでなく、失敗したときに素早く戻せるかも見ています。
Instability 側の2つ
4. 変更失敗率
本番へ出した変更のうち、問題を起こして介入が必要になった割合です。
ロールバック、ホットフィックス、緊急修正の発生率をイメージすると分かりやすいです。
速く出せても、この数字が高いなら運用はかなり苦しくなります。
5. Deployment Rework Rate
最近のDORA整理で追加されたのがこれです。
本来の計画変更ではなく、本番障害や不具合対応のために発生した やり直しデプロイ の割合を見る考え方です。
変更失敗率だけでは拾い切れない 手戻りの多さ を見ようとしている、と理解すると分かりやすいです。
なぜDORA指標がよく使われるのか
DORA指標の良いところは、速度と安定性を一緒に見られることです。
現場では 速く出したい と 壊したくない がいつもぶつかります。
でもDORAの考え方では、これは単純な二者択一ではありません。
変更を小さくする、レビューやテストを改善する、デプロイを自動化する、切り戻しを整える、といった改善は、速度にも安定性にも効くことがあります。
つまり、速いチームは雑、安定したチームは遅い と決めつけず、両方を良くする余地を見つけるために使いやすいです。
実務でどう見るのか
ここはかなり大事です。
DORA指標は、会社全体の気合い指数ではなく、まず 1つのサービスやアプリケーション 単位で見る方が使いやすいです。
たとえば、次のような見方をします。
こうすると、改善の打ち手が具体化しやすくなります。
よくある誤解
1. DORA指標は開発者の成績表
これはかなり危ない使い方です。
DORA指標は、個人評価よりもシステム全体の流れを見るためのものです。
個人評価に直結させると、数字を良く見せるためにデプロイ定義を変えたり、失敗を隠したり、小さな修正を分割したりして、本来の改善からずれやすくなります。
2. デプロイ頻度が高ければ強い
高頻度でも、失敗率や手戻りが高ければつらいだけです。
逆に低頻度でも、ビジネス事情やサービス特性に合っていれば一概に悪いとは言えません。
3. 4つだけ覚えれば十分
Four Keys は今も入口として強いですが、最新のDORA整理では5指標で見ています。
特に リワーク率 や 失敗後の回復時間 の見方は、最近の実務感にかなり近いです。
DORA指標を使うときの注意点
1. まず定義をそろえる
デプロイとは何か 失敗とは何か 回復完了とは何か がチームでずれていると、数字だけ集めても比較できません。
2. 数字だけで殴らない
指標は、改善の会話を始めるための材料です。
数字が悪いときに犯人探しを始めると、現場はすぐ防御的になります。
3. 小さく改善する
いきなり全部の指標を上げようとするより、まずボトルネックを一つ減らす方が現実的です。
レビュー待ち、手作業デプロイ、切り戻し手順不足、テスト不安定など、具体的な詰まりを潰す方が効きます。
何から始めればよいか
最初は次の順で十分です。
- 1サービスだけ対象を決める
- デプロイ、失敗、回復の定義をそろえる
- まず4指標か5指標のざっくり値を出す
- 一番つらいボトルネックを1つ選ぶ
- 1か月単位で変化を見る
このくらいから始めると、指標収集が目的化しにくいです。
まとめ
DORA指標 は、ソフトウェアを 速く 安定して 届けられているかを見るための指標です。
昔のFour Keysで知られていますが、最近のDORA公式整理では5指標モデルへ進化しています。
大事なのは、個人評価の材料にすることではなく、開発と運用の流れのどこが詰まっているかを見つけることです。
デプロイ頻度、リードタイム、失敗率、回復時間、リワーク率を通して、速さと安定性のバランスを見たいときにかなり役立ちます。