500行のPRを投げて、レビューが1週間返ってこない

初めての機能実装を終えた新人が、渾身のPRを提出しました。

Files changed: 23
+847 −312

「よし！頑張って全部まとめたぞ！」
…3日後。レビューが返ってきません。5日後。まだ返ってきません。Slackでそっと催促すると、先輩からこう返ってきました。
「ごめん、差分が大きすぎて、レビューする気力が湧かない…」
これは先輩が怠けているのではありません。人間の集中力には限界があるのです。

「PRの大きさ」と「レビュー品質」の残酷な関係

GoogleのCode Review研究チームの調査によると、以下の傾向があります。

変更行数     │ レビュー品質
────────────┼──────────────
~200行       │ ✅ 指摘が具体的で深い
200-400行    │ ⚠️ 表面的な指摘が増え始める
400行以上    │ ❌ 「LGTM（問題なさそう）」で通されがち

皮肉なことに、PRが大きければ大きいほど、バグが見逃されやすくなるのです。
先輩は「全部見ないといけない」プレッシャーに押しつぶされ、結果として流し読みになります。

新人が得ること × 先輩が得ること

【200行以内のPR】
新人の利益：
  ✅ レビューが数時間以内に返ってくる（学習サイクルが速い）
  ✅ 指摘が具体的で、一つずつ学べる
  ✅ コンフリクトが起きにくい
先輩の利益：
  ✅ 昼休み前の10分でレビューが終わる
  ✅ 全体像を把握しやすく、本質的な指摘ができる
  ✅ 「レビューしなきゃ…」のストレスが消える

大きなタスクを「小さなPR」に分割するテクニック

「でも機能が大きいのに、どうやって小さく分けるの？」
これが新人が最初にぶつかる壁です。コツは**「動く状態を保ったまま、薄くスライスする」**ことです。

❌ 機能を丸ごと1つのPRで出す
   → PR1: ユーザー登録機能（API + バリデーション + DB + テスト + UI）= 800行
✅ レイヤーごとにスライスする
   → PR1: DBマイグレーション + モデル定義（50行）
   → PR2: APIエンドポイント（100行）
   → PR3: バリデーションロジック（80行）
   → PR4: フロントエンドのフォーム（120行）
   → PR5: テスト追加（100行）

各PRが独立して動作確認でき、レビュー可能な単位になっています。

明日からできるアクション

新人へ：git diff --stat でPRを出す前にファイル数と行数を確認する。200行を超えていたら「もう1段階分けられないか？」と自問する。
先輩へ：レビューで「PRが大きい」と指摘するだけでなく、「こう分割するといいよ」と分割の仕方を一緒に考える。その1回の投資で、新人は自然に小さなPRを作れるようになります。