第11回 差分でレビューする（見る量を減らし、見る質を上げる）

見る量を減らし、見る質を上げる。1文字ずつのキーストロークを追う見方は、もうやめる。

第10回で、許可の境界を先に決めた。安全な範囲は自動で進み、破壊的な操作だけが立ち止まる。承認疲れで思考停止する場面は、これでかなり減ったはずだ。だが摩擦が減ったからといって、見なくていいわけではない。むしろここからが本番だ。承認の数は減っても、レビューすべき成果物の数は逆に増える。2体、3体と体数が増えていくのだから当然のことだ。

だとすれば、レビューのやり方そのものを変えるしかない。ここで固めるべきは、何を見て、何を見なくていいかの型だ。

何を見るかを変える：プロセスでなく結果

見るべきは、プロセスではなく結果だ。

細部を任せるということは、細部を追わないということだ。途中の試行錯誤、書いては消した行、一時的に通らなかったテスト。それらは有能な同僚に仕事を頼んだときと同じで、そもそも見る対象ではない。

見るべきは、最終的に残った差分。第7回の検証ループが「動くかどうか」を確認し終えたあとに、人間が確認するのは「これが本当に頼んだ範囲か、質は保たれているか」という別の軸になる。

その「動くかどうか」の収束は、1回では終わらないのが普通だ。

レビューに届く差分は、この4〜5回の反復をすでに経たあとの結果だ。エージェント自身が書き直した跡を、人間がさらに一からたどり直す必要はない。見るべきは、その反復の末に残ったものが依頼の範囲に収まっているかどうかだ。

差分レビューの型：3つの質問

差分を開いたときに、順番に確認する質問を固定しておくと、見落としが減る。

月次レポートのレビューを思い浮かべてほしい。先月からの経過を最初から全部読み返す担当者はいない。数値がどう変化したか、施策がどう変わったか、変化点だけを追う。差分レビューもこれと同じ発想で、変わった箇所にだけ集中力を割く。

何を書くかを決める判断力の価値

書くコストが下がるほど、読む価値の置き所も変わる。

これはそのまま、レビューにも当てはまる。書くコストが下がるほど、書かれたものすべてを均等に読む価値は下がる。価値が上がるのは、どこを重点的に読むべきかを判断する力のほうだ。

最終的にマージするかどうかを判断するのは、いつでも人間の側に残る。この責任の所在については、終章であらためて扱う。

差分レビューを助ける道具

差分の種類によって、見るべき道具は違う。意識するだけで、レビューの抜け漏れが減る。コードの変化はgit diff、UIの変化はスクリーンショット比較、動作の変化はテスト結果の差分で確認する。

$git diff --stat
src/api/upload.ts | 42 +++++++++---src/api/auth.ts | 3 +-2 files
changed, 42 insertions(+), 3 deletions(-)

--statで変更ファイルの一覧と行数をまず眺めるだけで、依頼した範囲と一致しているかが数秒で分かる。中身を読む前に、まず範囲を確認するという順番が効く。

よくある誤解と罠

• diffのサイズだけで安心・危険を判断する。行数が少なくても、設定ファイル1行の変更が本番を止めることがある
• 差分は見るが、依頼した内容を見返さない。何を頼んだかを覚えていないと、スコープの逸脱にそもそも気づけない
• 複数エージェントの差分をまとめて一度に見る。第8回で担当ファイルを分けておけば、どの差分がどのエージェントの成果かが最初からはっきりする

3つ目の罠は、気の緩みだけの問題ではない。複数のエージェントの成果を一つにまとめる作業そのものが、技術的に重い。

だからこそ、第8回で担当ファイルを分けておくことが効いてくる。ファイルが最初から分かれていれば、マージという名の合流作業そのものが要らない。分けずに走らせてからまとめようとするほうが、あとで重い代償を払うことになる。

今日のまとめ

• レビューの対象は途中経過ではなく、最終的に残った差分
• 差分を開いたら「範囲・削除・副作用」の3つを順に確認する
• 書くコストが下がるほど、どこを重点的に読むかを判断する力の価値が上がる

次は、ここまでの一つひとつの依頼を、繰り返す仕組みに変える。第12回、仕事をループに分解する。ステップ2の卒業回になる。