変更失敗率とDORA四指標の数理

DORA四指標は「速度×安定性」の2軸

DORA（DevOps Research and Assessment）の四指標は、ソフトウェアデリバリの性能を速度2つ・安定性2つの組で測ります。重要なのは、これらが独立した4つのKPIではなく、互いを牽制し合う2軸として設計されている点です。

DORAの研究が示した反直感的な発見は、速度と安定性は両立するということです。素朴には「速く出せば壊れる」と思われがちですが、実データでは速い組織ほど安定もしている。小さなバッチで頻繁に出すと、1回の変更差分が小さく、原因切り分けが速く、ロールバックも容易になるためです。つまりDFを上げる行為がLT・CFR・MTTRをも改善する正のループを作ります。

なぜ平均値が指標を壊すのか

DORA四指標のうちLTとMTTRは時間であり、レイテンシと同じく右に長い裾を引く分布になります。下限はゼロ付近に張り付き、上限はレビュー待ち・依存待ち・難障害などでいくらでも伸びる。この非対称分布に対して算術平均を取ると、少数の極端な値に引きずられて中央値よりはるかに大きく出ます。

右に裾を引く分布では順番が固定:
  最頻値  <  中央値  <  平均
平均がメンバーの体感より悪く見えるのはこのため

たとえばLTが「ほとんど2時間だが月に1件だけ依存待ちで2週間」というチームの平均LTは、その1件に汚染されて何日にも膨れます。これを見て「遅い」と判断するのは誤りで、実態はp50=2時間、p90=4時間、まれな外れ値が1件です。パーセンタイル統計 と同じ原理で、平均は分布の形を1点に潰してしまい、最も重要な「裾」の情報を消します。

変更失敗率は「比率」であることを忘れない

変更失敗率（CFR）の定義は単純に見えて、母数の扱いで誤解を生みます。

CFR = 障害を招いたデプロイ数 ÷ 本番デプロイ総数

ここで分母がデプロイ総数である点が決定的です。デプロイ頻度を上げると分母が増えるため、障害の絶対数が同じでもCFRは下がります。逆に「失敗が怖いから月1回しか出さない」チームは、分母が小さく、1回コケただけでCFRが跳ね上がる。つまりCFRを単独で見ると、頻繁に小さく出す健全なチームほど有利に見える——これは罠ではなく、小バッチ化を正しく評価する設計です。

二項試行としてのCFRには統計的な揺らぎもあります。月20デプロイで失敗1件なら観測CFRは5%ですが、これは真の失敗率の点推定にすぎません。試行数 n が小さいと信頼区間が広く、CFRが10%→5%に「改善」して見えても、母数20件では偶然の範囲内ということが起こります。小さなチームのCFRの月次変動を過剰に解釈しないことが肝心です。

デプロイ頻度と分布の数え方

デプロイ頻度（DF）は一見シンプルですが、いつのトラフィックで割るかで値が変わります。チーム全体で均すと「1日3回」でも、内訳は「営業日に集中・週末ゼロ」かもしれない。平均レートはバースト性を隠します。

DF を素朴に平均すると:
  30日で90デプロイ → 3.0/日
だが実際は 22営業日に集中 → 4.1/営業日、週末は0

DORAが頻度を「平均回数」ではなく「オンデマンド／週次／月次」という順序カテゴリで測るのも、デプロイ間隔の分布が指数分布的に偏るためです。間隔の中央値（連続デプロイの間が何時間空くか）を見るほうが、平均レートより実態に近いことが多い。デプロイ戦略 でカナリアや段階リリースを採ると、1つの変更が複数の「デプロイイベント」に分割され、数え方の定義次第でDFが数倍ぶれる点にも注意が要ります。

計測の落とし穴と相関の誤読

四指標を正しく集計するうえで、統計的な落とし穴がいくつもあります。

とりわけ「サブチームごとのp90を平均して全体のp90とする」のは典型的な誤りです。パーセンタイル統計 で見たように、パーセンタイルは順序統計量であり加算も算術平均もできません。全体のp90が必要なら、各チームの生データかヒストグラムをマージしてからパーセンタイルを引き直す必要があります。

まとめ

• DORA四指標は速度（DF・LT）と安定性（CFR・MTTR）の2軸。小バッチ化により両立し、正のループを作る。
• LT・MTTRは右に裾を引く時間分布。平均は外れ値で崩れるので、中央値・p90か「閾値内割合」で語る。
• CFRは分母にデプロイ総数を含む比率。頻度と切り離して単独で読むと、健全な小バッチチームを誤評価する。
• パーセンタイルは加算・平均不可。サブチームを束ねるときは分布を統合してから算出する。
• 指標間の連動は多くが共通原因（小バッチ）由来の相関。介入の評価は4指標を同時に観察して行う。