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を作れるようになります。