■ 1. 計測の概要
- 著者は3ヶ月間で62件のPRから300件のレビュー指摘を収集し、分類と評価を実施
- 分類軸はConventional Commentsを参考に6カテゴリを設定:
- Style: インデントなどの体裁
- Naming: 命名規則の一貫性
- Bug: nullエラー、無限ループなどの論理欠陥
- Architecture: 層構造の適切性
- Refactor: コード整理の効率化
- Spec: 仕様書との整合性確認
- 評価指標は後追い採点による3種類:
- 品質寄与（0/1/2段階）
- 速度寄与（−2〜+2で開発速度への影響を評価）
- 3ヶ月後欠陥相関（同種問題が本番バグとして再発したか）
■ 2. 6カテゴリ×3指標の分析結果
- カテゴリ別の計測値:
- Style: 96件、品質寄与0.4、速度寄与−0.8、欠陥相関0.04
- Naming: 58件、品質寄与0.7、速度寄与−0.3、欠陥相関0.07
- Refactor: 47件、品質寄与0.6、速度寄与−1.1、欠陥相関0.12
- Architecture: 31件、品質寄与1.6、速度寄与−0.4、欠陥相関0.18
- Bug: 42件、品質寄与1.9、速度寄与+1.2、欠陥相関0.51
- Spec: 26件、品質寄与1.7、速度寄与+0.9、欠陥相関0.43
- 重要な発見:
- Bug指摘の欠陥相関（0.51）はStyle指摘（0.04）の約13倍
- 同じコメント1件でも効き目が1桁異なる
■ 3. nit:が多いレビューほどコードが歪むという逆説
- レビュアーの認知容量は有限であり、スタイル指摘（nit:）が30件あるPRでは他カテゴリ、特にBug候補の検出感度が低下する
- 書き手側も「全部直さなければならない」という疲労から設計判断の思考が浅くなるというのが著者の仮説
- 根拠:
- Trisha Gee（Oracle）のコードレビューアンチパターン
- Google Engineering Practicesの優先順位付け（Design → Functionality → Complexity → Tests → Naming → Comments → Style → Documentation）でもStyleは最後に位置し、査読時の負荷分散の必要性を示唆
■ 4. 効果があったのはBugとSpecの2種類のみ
- Bug指摘の実例:
- PR #142の「空配列時に無限ループする」という1件のissue指摘が、3ヶ月後のCSVインポート機能の本番障害を未然防止
- 1指摘で本番障害1件相当の価値が発生
- Spec指摘の複利効果:
- 「タイムゾーン処理はサーバー基準か」という質問1件が、AGENTS.mdへの「全タイムスタンプはUTC保存・JST表示」という共通ルール追加につながった
- その後3ヶ月でタイムゾーン関連バグがゼロになった
- Spec質問は直接修正を生まないが、チームの共通理解を更新し、波及効果で複数PRに恩恵をもたらす
■ 5. 価値の低い4カテゴリの処遇
- PRレビューの場から外す戦略を採用:
- Style: Prettier/Biome/Ruffで機械強制（pre-commitフック）
- Naming: AGENTS.mdに規則を明記し、CodeRabbitに自動指摘させる
- Refactor: 別PRの
refactor:タスクとして扱い、同一PRでは指摘しない- Architecture: PR提出前の設計レビュー段階で検討する
- 分類後の効果:
- 3ヶ月のレビュー時間を平均42%短縮
- Bug/Spec指摘の密度はむしろ上昇
■ 6. Conventional CommentsのROI計測への活用
- ラベル体系を「指摘の角度の名前付け」だけでなく、ROI計測のグループキーとして運用する
- 3ヶ月蓄積後に各ラベルの出現頻度と修正サイクル寄与を可視化できる
■ 7. 実装の3ステップ
- Stage 1: 直近50件の指摘を分類する（10分）
- Stage 2: 3指標で採点する（3ヶ月のバグ報告と突き合わせる）
- Stage 3: 低ROI項目を場所替えする（自動化・規則化・前出し）
- 効果判定:
- 導入後2週間で判定可能
- 総コメント数の減少と「issue:」「question:」比率の上昇が成功指標
■ 8. 計測の限界
- 単一プロジェクト（n=300）における著者一人による主観的分類である
- 複数プロジェクト・複数レビュアーでの再現性は未確認
- 分類枠組み自体は転用可能であり、自チームのPRログで2週間で結論が得られる
■ 9. 結論
- 「全指摘を直すレビュー」から「BugとSpecの2種類だけを死守するレビュー」へシフトする
- これにより開発速度を回復させ、真に価値のあるフィードバックに集中できる