第11章：メトリクス設計（Lead time / Review time / 差し戻し率）
この章で扱うこと
- 計測対象（Lead time / Review time / Reopen 率 等）
- 計測→改善サイクルを運用手順として定義する
メトリクス設計の目的
エージェント導入は「速くなった気がする」で終わりがちです。 メトリクスは、改善を 再現可能な運用 に落とすための仕組みです。
計測対象（例）
最低限、次のような指標を定義します（定義と計測方法のセットで持つ）。
- Lead time：Issue 作成（または着手）からマージまで
- Review time：PR 作成から承認まで
- Reopen 率：クローズ後の再オープン比率（仕様不足/品質不足のシグナル）
- 差し戻し率：レビューでの大きな手戻り（差分肥大/テスト不足のシグナル）
収集方法（最小）
重要なのは「完璧な計測」より 継続可能 な収集です。
- GitHub の Issue/PR メタデータを使う（作成日時、マージ日時、レビュー、ラベル等）
- 定義のブレを抑える（ラベル運用、テンプレ必須項目、DoD の固定）
- サンプリング（重要リポジトリ/重要ラベル）から開始し、対象を広げる
改善サイクル（運用手順）
- 収集（週次/月次など頻度を固定）
- 解釈（どの指標が悪化し、なぜか仮説を立てる）
- 施策（テンプレ改善、Rules 調整、CI 強化、Skill 追加など）
- 検証（次サイクルで効果を確認し、記録する）
メトリクスは単独最適化すると副作用が出るため、複数指標と定性レビューをセットで運用します。
導入チェックリスト（ドラフト）
- 計測項目と収集方法（データソース/定義）が定義されている
- 計測の前提（ラベル運用、テンプレ必須項目、DoD）が整備されている
運用チェックリスト（ドラフト）
- 改善サイクル（頻度/担当/レビュー観点）が運用できている
- 施策→効果検証→記録が継続できている（指標と定性の両方）