PRレビューが遅くなるのはなぜか？

とあるプロジェクトで、レビューが溜まってしまうことが課題として挙げられていました。

今回は、下記の論文をもとに、改善点を整理してみます。

出典: Zhang et al., “Pull Request Latency Explained: An Empirical Overview,” Empirical Software Engineering (2022).
（以下「Zhang+2022」と表記）

まずはポイント

• PRが Open されてから Close（マージ／クローズ）されるまでの経過時間（= PRレイテンシ）は、“いつ・どんな状況で測るか”によって効いてくる要因がガラッと変わる。
• PRを開いた直後（提出時点）では、PRの規模（コード変更量）、説明文の長さ、投稿者の経験、レビュワー側の未処理PR数（ワークロード）など“準備段階”の要因が強く効く。
• PRが閉じる段階（クローズ時点）では、コメント往復・追加コミット・CI結果といった“レビュー過程”で発生する動的要因が効いてくる。
• コメントが付いたPRでは「初回レスまでの時間」がレイテンシを大きく左右。早い一次応答が重要。
• CIを使っているプロジェクトでは「ビルド所要時間」「CI失敗の再実行」が遅延要因。CI高速化はレビュー高速化でもある。

この論文について

現場感覚でも“レビューが詰まっている”“誰も見てくれない”といった課題は多いですが、レイテンシは複数フェーズ（提出 → レビュー → 修正 → マージ/却下）で発生するため、どこがボトルネックかを定量化して初めて改善できます。

Zhang+2022は、そのボトルネック要因を網羅的に洗い出し、文脈別に比較しています。

対象は、リポジトリ数11,230、分析PR数3,347,937、検討要因63種類（コード規模、経験、コメント、CI、プロジェクト負荷 など）に及んでいます。

文脈別：主要因ランキング

以下は論文で示唆された「相対的重要度が高かった上位因子」を、実務で扱いやすい形に訳したものです。

1. 提出時点（PR Open 時）

2. クローズ時点（最終段階）

3. コメントが付いたPR（has comments = true）

• 初回コメントまでの時間**が決定的。誰かが最初に反応するだけで心理的・実務的に処理が進みやすい。
• コメント総数／コードコメント数が増えるとレイテンシも伸びやすい（議論長期化）。

即効施策

• Botや自動ラベルで「レビュー受け付けました」即時応答。
• 初回軽量レビュー（表面チェック）と本格レビューを段階分離。

4. CIを利用しているPR

• CIビルド時間が長い**ほどレイテンシ増。
• ビルド失敗→再実行**のループが遅延を悪化。

即効施策

• キャッシュ・並列化・テスト分割でCI高速化。
• フレーク対策（再試行自動化、失敗分類）。
• Pre-push / pre-PRローカルチェックで初期不良を減らす。

5. 提出者と統合者（マージ権限保持者）が異なるPR

OSSや外部コントリビューションで典型的なケース。相手とのコンテキスト共有が薄いほどコメント往復が増えレイテンシが伸びる傾向。

即効施策

• PRテンプレートで「背景・再現手順・スクリーンショット・リリース影響」を必須化。
• 自動ラベルで担当チームを早期特定。
• メンテナの“レビュー受付時間帯”をREADMEで明示。

レイテンシ改善チェックリスト（現場向け）

以下はZhang+2022の知見をベースに、筆者が現場適用しやすい形に整理したチェックリストです。導入優先度は★で示します（★=効果小～★★★★★=効果大見込み）。

A. PRを小さく・明瞭に（★★★★★）

• 1機能1PR。巨大なリファクタ＋機能追加は分割。
• “What / Why / How / Testing” の4段構成テンプレ。
• 変更が多い場合はスクリーンショットやGIFで差分共有。

B. 初動レス高速化（★★★★★）

• PR作成時に自動でレビュワー割当。
• 「24時間以内に一次反応」SLA。
• Botで“レビュー受領・CIキック済み”を即コメント。

C. CI待ち時間削減（★★★★☆）

• 差分テスト（changed pathsだけ実行）。
• キャッシュと分散ビルド。
• フレークテスト隔離と自動再試行。

D. レビューキュー可視化（★★★★☆）

• ダッシュボードで未処理PR数・平均待ち時間を共有。
• SLA超過PRをハイライト。

E. コントリビュータ育成（★★★☆☆）

• 新規参加者向けに「最初のPRガイド」。
• Coding Style / Lint / テストガイドを簡潔に。

F. コメントノイズ削減（★★★☆☆）

• 自動整形（Prettier/clang-format）。
• Lint違反はBotでまとめて指摘（人間レビューを本質議論に集中）。

実装アイデア：メトリクスでボトルネックを見える化