レビュー不能なPRを出す人の心理と、レビュアー側の防衛策
まとめ
- PR本文が空（テンプレのプレースホルダーのまま）のPRは、レビュアーが判断材料を持てないので「レビュー不能」になる
- 原因は能力ではなく「受け手視点の欠落」。作者は文脈を全部持っているので、書く必要を感じない（知識の呪い）
- 変更が大きいほど本文の説明が要るのに、この型の人は規模が変わっても本文を書かない。むしろ悪化する
- 個人へのフィードバックより「動作確認・チェックリストが空のPRはレビュー着手しない」という構造で縛るほうが効く
レビュー不能なPRとは何か
コードレビューを依頼されたとき、diffを開く前に本文を読む。ところがその本文が、テンプレートのコメント（<!-- ここに概要を書く -->）が一つも埋まっていない状態で出てくることがある。
- 概要: 空
- 対応内容: 空
- 動作確認: 空
- チェックリスト: 全部チェックなし
この状態のPRは、レビュアーから見ると「何を・なぜ・どう変えたのか」がゼロだ。diffだけを頼りに、作者の意図を推測しながら読むことになる。これは本来レビュアーの仕事ではない。作者が持っている文脈を、レビュアーがdiffから逆算して再構築させられている。
とくにインフラ系のリポジトリで、状態ファイル（terraformのstateなど）をコミットに含めてしまうケースは深刻だ。本質的な変更が数十行なのに、自動生成される状態差分が数百行乗っかり、レビュアーは本題を目視で拾わされる。差分の大きさと、レビューすべき内容の大きさが一致しなくなる。
なぜ空のPRを出せるのか
指摘すると意外に思うかもしれないが、これは手抜きというより認識のズレだ。作者本人の中では、そのPRは「完了形」になっている。
- 作者は変更の意図も背景も全部わかっている
- だからわざわざ書く必要を感じない
- レビュアーがゼロから読む、という状況が想像できない
これは「知識の呪い（curse of knowledge）」と呼ばれる認知バイアスそのものだ。自分が知っていることを、相手も知っている前提で振る舞ってしまう。悪意はない。むしろ「ちゃんと出した」つもりでいる。だから「本文が空だ」と指摘されると「動いてるのに何が問題？」という反応になりやすい。
テンプレートのコメントを「埋める対象」ではなく「消すと体裁が崩れる枠」だと捉えているケースもある。この場合、テンプレを貼れば様式は満たしたと認識している。
規模が大きいほど悪化する
厄介なのは、この型がPRの規模に依存しないことだ。数ファイルの小さな変更でも、100ファイルを超える大規模な変更でも、本文の埋まり方は変わらない。
むしろ大規模な変更こそ本文が要る。たとえば「不要コードの一括削除」のような、レビュアーが1行ずつ追えないタイプの変更を考えてみる。ここで必要なのは、
- 「この削除は本当に安全」だと言える根拠（検出ツールの出力、CIの結果、呼び出し元の全文検索結果）
- 主要な導線が壊れていないことのエビデンス
ところが本文が空だと、根拠は「ツールが検出した」と「精査済み（自己申告）」だけになる。レビュアーは「作者を信じる」以外の選択肢を奪われる。そしてそういうPRに限って、そのまま承認されてしまう。
規模が大きいほど、本文の空白が持つ危険は跳ね上がる。なのに作者は規模に反応しない。これはもう、うっかりの注意力不足ではなく、固定された行動の型だ。
「空でも通る」が型を固定する
もう一つ見落としがちなのが、環境側の責任だ。空の本文のPRが承認されてマージされるという成功体験を積むと、作者にとって「本文は書かなくていいもの」という認識が強化される。
- 作者: 「動く／精査した、以上」で完結する
- 周り: 変更が大きすぎて実質フルレビュー不能 → 信頼ベースで承認 → 空本文が正当化される
この状態が続くと、いくら個人に注意しても型は変わらない。「空でも通った」という事実のほうが、口頭の指摘よりずっと強いからだ。
レビュアー側の防衛策
では、こういうPRに繰り返し当たる側はどうすればいいか。個人の心境を変えようとするのは、たいてい徒労に終わる。効くのは仕組みで縛ることだ。
1. 受け入れ基準を明文化する
「動作確認が空、チェックリストが未記入のPRはレビューに着手しない」を運用ルールにする。作者の心境を変えなくても、レビュアー側の負担を切れる。基準を機械的なゲートにするのがポイントで、「本文が薄い気がする」のような主観にしない。
2. 状態ファイルやビルド生成物をdiffから外す
自動生成物はバージョン管理から除外するか、少なくともレビュー対象のdiffに混ざらないようにする。本質的な変更だけがdiffに残る状態を作れば、本文が薄くても被害が小さくなる。
3. 抱え込まず上に投げる
同じ問題が繰り返されるなら、個人対個人で拾い続けない。「何回目か」を記録して、判断できる立場の人に材料として渡す。空のPRを黙って拾い続けることは、作者の「空でも通る」を強化するだけだ。
レビューは口で誤魔化せない場所
コードレビューが組織で象徴的なのは、そこが成果物そのものを突き合わせる場だからだ。会議や口頭の報告は、話術で実態以上に見せられる。しかしPRの本文とdiffは、自分で書かなければ空のまま残る。
だからPRの質は、その人が「受け手のために手を動かせるか」を映す鏡になる。作れることと、作ったものを他人が使える形で渡せることは別の能力だ。前者だけあって後者が欠けている人は、レビューの場で必ずそれが出る。
私見
ここまでは分析。ここからは私の思いだ。
正直に言えば、こんなものはルールに書くことじゃない、普通にやってほしい、と思う。テンプレの空欄を埋める、動作確認を一言添える、それだけの話だ。同じ職種で長くやってきた人間なら、言われなくてできて当然だと感じる。
ただ、思うのと変わるのは別だ。「普通にやってくれ」と願っている限り、拾う側がコストを払い続ける構図は変わらない。願望は願望として持ちつつ、実務は仕組みで守る。感情と対処は分けておく、というのが今の落としどころだ。