コードレビューが最後に人間へ残る理由は、産物がコードではないことだ

AIが書いたコードのプルリクエストに、AIがレビューを返し、指摘への修正もAIが行い、テストは緑になった。あとは承認ボタンを押すだけ——という場面で、私は時々、手が止まる。止まる理由はコードの中身ではない。「これを入れていいと、誰が言えるのか」という問いに、自分以外の答えが思い浮かばないからだ。

この停滞はバグへの警戒ではない。指摘は正確で、修正も妥当だった。表の仕事は全部済んでいる。それでも手が止まるのは、レビューには表の仕事とは別の産物があるからだと私は考えている。この記事の主張はこれだ。コードレビューが人間の仕事として最後まで残るのは、レビューの本当の産物が「指摘されたコード」ではなく「その変更を説明できるもう一人の人間」だからである。

レビューの産物は、直ったコードではなくもう一人の人間だ

コードレビューは欠陥を見つける作業だと説明される。それは間違いではないが、半分しか説明していない。私が見た範囲で、レビューが実際に産んでいるものは、修正されたコードではなく「その変更について説明できる、書いた当人以外の人間」である。

具体的な場面をひとつ。差分そのものは正しい変更に、レビュアーが「このパラメータを変えると、別チームの夜間処理が止まる」とだけ書いたことがあった。その知識はチケットにもドキュメントにも書かれていなかった。コードを読んで分かる種類のものでもない。その人が過去にその系を触った記憶の中にだけあり、レビューという場がなければ、その変更と結びつくことはなかった。

もうひとつ。障害対応の最中に「なぜこの実装になっているか分かる人はいるか」と問われる場面がある。私が見た範囲では、そこで立てる人は例外なく、レビューを通してその系の差分を読み続けてきた人だった。仕様を書いた人は「こうあるべきだった」という意図を答えられる。だが系の現在形——実際にどうなったか——を答えられるのは、変更を追い続けた人だけだ。レビューは、その人を組織の中に継続的に作り直す装置として機能している。

「止められる人」と「説明できる人」は違う

ここまでの話は「AIを止められる人間を残せ」という主張と似ているが、私は別のことを言っている。停止権は拒否の話で、ここで言っているのは引き受けと説明の話だ。

止めるだけなら権限設定で足りる。マージ権を人間にだけ付与すれば、誰でも止められる人にはなれる。だが障害の夜に必要なのは、止めたあとに「ではどうするか」を説明できる人である。権限は設定で配れるが、説明能力は配れない。それは、変更を読み、文脈を聞き、時には反対して、というレビューの反復の中でしか育たない。

レビューで「このやり方は以前、別の箇所で失敗している」と、差分の外の記憶だけを根拠に止めた場面があった。あのとき止める力があったのは権限のおかげだが、止める判断ができたのは、過去の変更をレビューで読んできた記憶のおかげだ。前者はツールで代替できる。後者は、読み続けるという行為の蓄積でしか作れない。

「人間は上流に移ればよい」への反論

この主張への最も強い反対はこうだ。人間による差分レビューは、AIの生産量に対して周波数の合わないサンプリング機構であり、もう構造的に破綻している。品質はテスト、静的解析、AIレビューで機械的に担保し、人間は仕様と設計という上流に移るべきだ——と。

検出の問題としては、この反対は正しいと私は思う。AIが書くすべてのコードを人間が精読する運用は維持できないし、読み切れない差分を承認する人間は品質の担保になっていない。その部分には争わない。

ただしこの反対は「欠陥をどう見つけるか」への回答であって、「説明できる人間をどう作るか」への回答ではない。上流に移った人間が読むのは意図である。意図を知っている人と、出来上がった系の現在形を知っている人は別の人で、その非対称は上流への移動では解消されない。むしろ差分を読む場が消えれば、現在形を知る人の補給路が一本消える。

「説明ならAIが答えられる」という応答もあるだろう。コードベースと変更履歴を索引して「なぜ」に答えるAIは、確かに実現しつつある。だが私が遭遇してきた「なぜ」の多くは、コミットメッセージにも議事録にも残っていない種類のものだった。「あのとき隣の系が壊れていて、急いで暫定で回した」という経緯は、どこにも書かれない。書かれたものだけを索引する限り、書かれなかった「なぜ」を知っているのは、その場にいた人間か、レビューでそれを聞いた人間である。

この主張が外れる条件

この主張には適用範囲がある。まず、壊れても痛くないコードには当てはまらない。使い捨てのプロトタイプや実験コードに「説明できる人間」を維持する費用は割に合わず、レビューを省く判断は領域によっては正しい。

次に、書き手が唯一の利害関係者である場合だ。一人で書き一人で使うコードに「もう一人」を作る必要はなく、そこではレビューは始めから成立していない。

そして最も重い条件は、AIが「書かれなかったなぜ」にも答えられるようになることだ。変更履歴だけでなく、当時の会話や周辺の事情までを保持して応答できる段階に来たら、人間の頭に系の地図を維持する意義は薄れる。ただ私には、それはレビューが不要になるというより、レビューが担ってきた記憶の維持をAIが引き受ける、という形に見える。その引き受けが本物かどうかは、障害の夜にしか分からない。

承認ボタンの前の停滞に戻る。あれは無駄な逡巡ではなく、「この変更を、自分以外の誰かも引き受けたことにしていいか」を確認する作業だ。コードを書く行為もテストを回す行為もAIに譲ってよい。だがコードを読み続ける人間がいなくなれば、壊れたときに問い合わせる先が組織から消える。レビューが最後まで人間に残るのは、人間の検出能力が勝っているからではない。レビューが作っているのはコードではなく、次の障害の夜に立てる人間だからだ。