フレームワーク活用ガイドひとことで言うと#
DORA Metricsを軸に、品質・プロセス・開発者体験の指標を組み合わせて開発組織の健全性を多角的に測定するフレームワーク。
押さえておきたい用語#
- DORA Metrics
- Deployment Frequency・Lead Time・Change Failure Rate・MTTRの4つのデリバリー指標を指す。
- Lead Time for Changes
- コードをコミットしてから本番にデプロイされるまでの所要時間を指す。
- Change Failure Rate（変更失敗率）
- デプロイのうちインシデントやロールバックを引き起こした割合。品質の代理指標として使われる。
- MTTR（Mean Time to Recover）
- 障害発生から復旧までの平均時間。レジリエンスの指標である。
- Goodhart’s Law（グッドハートの法則）
- 「指標が目標になると、良い指標ではなくなる」という測定の罠。メトリクスのゲーミングが起きる原因。
エンジニアリングメトリクスの全体像#
こんな悩みに効く#
- 「開発チームの生産性はどうか」と聞かれても定量的に答えられない
- DORA指標を入れたが数字が良くなっても障害が減っていない
- メトリクスを導入したら開発者が数字を良くするためだけの行動を取り始めた
基本の使い方#
具体例#
エンジニア50名のBtoB SaaS。DORA指標を計測したところ、4指標すべてが「Medium」に分類された。
| 指標 | 計測値 | Elite基準 |
|---|---|---|
| デプロイ頻度 | 週1回 | オンデマンド（日複数回） |
| リードタイム | 5日 | 1日未満 |
| 変更失敗率 | 18% | 5%未満 |
| MTTR | 6時間 | 1時間未満 |
ボトルネック分析でリードタイムの大半がPRレビュー待ち（平均2.8日）と判明。ペアプロ + レビューSLAの導入で、6ヶ月後にリードタイムが 5日 → 1.2日 に短縮。連動してデプロイ頻度も 週1回 → 日1回 に改善した。
エンジニア200名の大手EC。デプロイ頻度をKPIに設定したところ、チームが小さな変更を大量にデプロイする「粒度ハック」が発生。デプロイ頻度は 週3回 → 日5回 に改善したが、変更失敗率が 8% → 22% に悪化した。
Goodhart’s Lawの典型例と認識し、単一指標KPIを廃止。DORA 4指標 + バグ密度 + 開発者満足度のスコアカードに切り替え、指標間のバランスで評価する形に変更した。結果、デプロイ頻度は日3回に落ち着いたが変更失敗率が 22% → 7% に改善。バランスのとれた状態に収束した。
エンジニア35名の受託開発会社。「開発が遅い」というクライアントからのクレームが四半期に 4件 あったが、感覚的な反論しかできていなかった。
DORA指標とバグ密度のダッシュボードをクライアントと共有。リードタイムが1.8日、変更失敗率が**3%**と業界水準を大幅に上回っていることを可視化した。
問題は開発速度ではなく要件定義フェーズの長さだと数字で示せたことで、クレームがゼロに。さらに「メトリクスベースの品質保証」を差別化ポイントとして提案に含められるようになり、受注率が 40% → 55% に向上した。
やりがちな失敗パターン#
- 個人単位でメトリクスを比較する — 「Aさんのコミット数はBさんの半分」のような使い方をすると信頼関係が壊れる。チーム単位で計測し、個人評価には使わない
- 指標を一度に大量に導入する — 20個の指標を同時に追い始めても見きれない。DORA 4指標から始め、四半期ごとに1〜2個追加する
- ダッシュボードを作って満足する — 数字を見るだけでは改善しない。月次レビューで「この指標が悪化している原因は何か」を議論し、具体的なアクションに落とす
- コンテキストを無視して組織横断で比較する — 新規開発チームとレガシー保守チームではメトリクスの水準が当然異なる。同じ基準で比較してランキングを作らない
まとめ#
エンジニアリングメトリクスはDORA指標を起点に品質・開発者体験を加えた3層で開発組織の健全性を測定する。単一指標への過度な依存はGoodhart’s Lawによるゲーミングを招くため、複数指標のバランスで判断する。チーム単位で計測しダッシュボードで可視化したうえで、月次の改善サイクルを回すことが継続的な改善につながる。