なぜベースライン = 意思決定権なのか#

ベースラインのないDORAメトリクスは単なる綺麗なダッシュボード。ゼロ点があって初めて、リーダーは投資判断の論拠を得る — Lead Time短縮にどれだけかかるか、特定の変更がいくらに触れるか、どこに最も安いレバーがあるか。

第1週 — インストルメンテーション#

1.1 生イベントの収集#

GitHub/GitLabのwebhookを、push、pull_request、deployment、incidentを記録するシンプルなエンドポイントに繋ぐ。まだSaaSは要らない — Vercel KV、Cloudflare D1、S3上のJSONファイルで十分。

1.2 定義の選択#

「障害」を監査可能な形で定義する。最も一般的なヒューリスティック: 24時間以内のロールバック OR インシデント中にデプロイされたhotfix OR ポストモーテムで明示されたデプロイ。

第2週 — 最初の読み取り#

直近14日のローリングウィンドウで値を計算し、SMBベンチマークと比較する。Google向けDORAレポートの「Elite」と自分を比べてはいけない — エコシステムが違う。第2週末の目標: 4指標それぞれに1つの数字と、ボトルネックに関する1つの仮説。

第3週 — 最初の介入#

1つのボトルネックを選び、測定可能な効果を持つ1つの変更を提案する。よくあるのは:

• Lead Time高 → コードレビュー自動化、PRバッチサイズ削減
• CFR高 → CIに品質ゲート導入（テスト、静的解析、脆弱性スキャン）
• MTTR高 → ランブック + デプロイプレビュー + ワンクリック・ロールバック
• Deployment Frequency低 → trunk-based開発 + feature flag

第4週 — テーブルでのレビュー#

4つの数字 + 1つの仮説 + 1つの介入を提示する。経営層に見せるのは「ダッシュボード」を買うのではなく、四半期後にエンジニアリング時間の具体的な節約を返す学習システムを買うのだという認識。

ベースラインはゴールではない。次のエンジニアリング時間をどこに投じるかの交渉の出発点だ。