デリバリープロセスが実際に改善しているかを示す4つの指標
最近、デプロイの頻度が上がった。チームは生産性が高まったと感じている。パイプラインはすべてグリーンだ。しかし、本番インシデントを見てみると、何かがおかしい。デプロイは速くなったが、数回に一度は何かが壊れ、復旧に何時間もかかっている。本当に改善しているのか、それとも間違った方向にただ速くなっているだけなのか？
これはエンジニアリングチームによくある盲点だ。デリバリーの成熟度を測る手段がなければ、活動を進歩と誤認しやすい。毎日リリースしていることに満足しても、それぞれのデプロイに高いリスクと遅い復旧が伴っているなら、まだ成熟していない。ただ忙しいだけだ。
幸いなことに、デリバリーの成熟度を測定するのに高価なツールや複雑なダッシュボードは必要ない。業界が長年の研究を通じて検証してきた4つの指標がある。これらはDORA（DevOps Research and Assessment）によるState of DevOps Reportに由来し、数千ものチームが自らの立ち位置と次に改善すべき点を理解するために活用してきた。
デプロイ頻度：どれくらいの頻度でリリースしているか
デプロイ頻度は、チームが本番に変更をプッシュする頻度を測定する。これはデリバリー能力を示す最もわかりやすい指標だ。月に一度しかリリースしないチームと、1日に複数回デプロイするチームでは、運用方法が根本的に異なる。
デプロイ頻度が低いと、各リリースは大きくなりがちだ。1ヶ月分の変更が一度に出ていく。つまり、リスクが高く、デバッグが難しく、フィードバックループが長くなる。頻度が高いと、各変更は小さくなる。単一の機能、バグ修正、設定変更が独立してリリースされる。何かが壊れた場合、原因を正確に特定できる。
高いデプロイ頻度は、スピードそのもののためではない。各変更のサイズを小さくするためだ。小さな変更はレビューが容易で、テストが簡単で、ロールバックもしやすい。また、ユーザーや監視システムからのフィードバックも早く得られる。
チームが週に1回未満しかデプロイしていないなら、何がより頻繁なリリースを妨げているのかを問いかけてみよう。手動承認プロセスか？長いテストサイクルか？何かを壊すことへの恐れか？その答えが、次のボトルネックを示してくれる。
変更のリードタイム：コミットから本番まで
リードタイムは、コードの変更がコミットされてから本番で実行されるまでにかかる時間を測定する。これはデプロイ頻度とは異なる。毎週デプロイしていても、各変更がマージされるまでレビューで何日も滞留しているかもしれない。
リードタイムが長い場合、通常はパイプライン内に待ちポイントが存在する。コードレビューに時間がかかりすぎている。CIパイプラインが遅い。デプロイの承認に誰かの手動ゲートが必要だ。それぞれの待ちポイントが、デリバリーサイクルに数時間から数日を追加する。
成熟したチームでは、リードタイムは時間または分単位で測定される。開発者がコードを書き、プッシュし、自動チェックが実行され、同じ日内に変更が本番に反映される。これは品質を犠牲にするということではない。品質チェックが自動化され、高速であることを意味する。
リードタイムが週単位で測定されているなら、実際に時間がどこで費やされているかを調べよう。レビュー待ちか？テスト待ちか？デプロイ承認待ちか？それぞれの待ちポイントは、自動化またはプロセス変更の候補となる。
変更失敗率：デプロイがどの程度問題を引き起こすか
この指標は最初の2つのバランスを取る。高いデプロイ頻度と速いリードタイムは、3回に1回のデプロイで本番が壊れるなら意味がない。変更失敗率は、デグレーションや停止を引き起こすデプロイの割合を測定する。
低い変更失敗率は、テスト、レビュー、デプロイ戦略が機能している証拠だ。変更は本番に到達する前に検証されている。カナリアリリースやフィーチャーフラグのようなデプロイ戦略は、障害の影響範囲を縮小する。
高い変更失敗率は、品質プロセスに何か問題があることを意味する。テストが実際の問題を捉えていないのかもしれない。デプロイが大きすぎるのかもしれない。本番環境がステージング環境と大きく異なるのかもしれない。
目標はゼロ障害ではない。それはほとんどのチームにとって非現実的だ。しかし、失敗率はデプロイプロセスを信頼できる程度に低くなければならない。デプロイするたびに不安を感じるなら、変更失敗率が高すぎる。
復旧時間：どれだけ早く復旧できるか
何かがうまくいかなかった場合、正常に戻るまでにどれくらいかかるか？復旧時間は、障害が検出されてからシステムが完全に復旧するまでの時間を測定する。
復旧が遅いのは、準備不足の兆候であることが多い。チームに明確なロールバック手順がない。データベースマイグレーションの巻き戻しが難しいため、ロールバック自体に時間がかかる。または、チームが手動で以前のバージョンを再ビルドして再デプロイしなければならない。
迅速な復旧は準備から生まれる。自動化されたロールバックスクリプト。再デプロイせずに問題のある機能を無効にできるフィーチャーフラグ。段階的なロールバックを可能にするデプロイ戦略。オンコールエンジニアに何をすべきかを正確に伝える明確なランブック。
復旧時間が時間または日単位で測定されているなら、最も一般的な障害シナリオを文書化し、それぞれに対して自動化された復旧手順を準備することから始めよう。
これらの指標がどのように連携するか
4つの指標は独立しているわけではない。頻繁にデプロイしても失敗率が高いチームは成熟していない。リードタイムが速くても復旧に日数がかかるチームは成熟していない。真のデリバリー成熟度とは、4つの指標すべてで同時に良好なパフォーマンスを発揮することを意味する。
以下は、成熟したチームの姿だ：
以下の図は、4つの指標がどのように相互に関連し、強化し合うかを視覚化している。
- デプロイは1日に複数回行われる。
- リードタイムは時間単位で測定される。
- 変更失敗率は低く、15%を大幅に下回る。
- 復旧時間は分単位で測定される。
以下は、改善中のチームの姿だ：
- デプロイは月1回から週1回になった。
- リードタイムは週単位から日単位に短縮された。
- 失敗率は安定しているか、減少している。
- 復旧時間は日単位から時間単位に短縮された。
絶対的な数値よりも方向性が重要だ。すべてのチームはどこかからスタートする。重要なのは測定し、最も弱い指標を特定し、それを改善することだ。
測定を始める簡単な方法
これらの指標を追跡するために専用のプラットフォームは必要ない。シンプルなログから始めよう。各デプロイについて以下を記録する：
- デプロイの日時
- デプロイが問題を引き起こしたかどうか
- 問題があった場合の復旧にかかった時間
- コミットからデプロイまでの時間
数週間後、パターンを確認する。どの指標が最も弱いか？それがスタート地点だ。次の指標に移る前に、その1つの指標の改善に集中する。
本当の目標は数値ではない
これらの指標を測定するのは、恣意的な目標を達成するためではない。チームのデリバリー能力を理解し、次に何を改善すべきかについて情報に基づいた決定を下すためだ。数値はシグナルを与える。改善は自信を与える。
頻繁にデプロイし、迅速に復旧し、めったに壊さないチームは、ユーザーニーズに応え、バグを素早く修正し、恐れずに実験できるチームだ。それがデリバリー成熟度の真の成果だ。指標は単なるスコアボードに過ぎない。