AI時代のコードレビューで鍛えるべきは、指摘力か問う力か

プルリクエストを開くと、人間より先にAIがコメントを付けている。命名が雑だ、インデントが揃っていない、この分岐はnullを見落としている。かつてレビュアーが一行一行追っていた指摘のうち、少なくない部分はもう機械の仕事になった。

これを「レビュアーの出番が減った」と読むと、話は半分しか見えていない。機械的な誤りの検出が自動化されたということは、人間に残るレビューの中身が入れ替わったということでもある。そしてその入れ替わりの先にあるのが、指摘力から問う力への重心の移動だ。

正しさを探す目は、もう主役ではない

これまで「良いレビュアー」とは、誤りを見抜く目が鋭い人のことだった。バグの匂いを察知し、命名の違和感に気づき、設計のほころびを一行の差分から読み取る。その能力は今も無価値にはならないが、差分の一次チェックという土俵では、機械的な網羅性を持つAIに分が悪い。人間が同じ土俵で「よりたくさん誤りを見つける」競争をしても、勝ち筋は細くなっていく。

問題は、AIが拾えるのは「コードに書かれたこと」に対する正しさであって、「なぜその書き方を選んだか」という意図には、今のところ多くのAIレビューツールが踏み込みきれていないという点だ。ここにこそ、まだ人間の役目が残っている。

指摘ゼロでも、良いレビューはありうる

ある設計が妥当かどうかは、コードだけを見て判定できないことが多い。将来どんな変更が来る想定か、チームの他のコードとの整合をどこまで取るか、パフォーマンスと可読性のどちらを優先したか。こうした前提は、書いた本人の頭の中にしかなく、差分からは見えない。

だからこれからのレビュアーに求められるのは、誤りを指摘する力よりも、相手にその前提を言語化させる問いを立てる力だ。「ここはなぜこの実装にしたのか」「他の方法は検討したか」という一言は、指摘ではなく問いである。コードを変えさせるのではなく、書いた人自身にもう一段深く考えさせる。

たとえばあるレビューで、承認されたコードは結局一行も変わらなかった。だが「この処理を共通化しなかったのはなぜか」という問いに答える中で、書いた人自身が「将来この二つは分岐が別れる可能性が高いから」という判断を初めて言葉にした。その一文はそのままチームの設計メモに残り、後になって似た実装をする別のメンバーが、コードを読むより先にそのメモを参照するようになった。コードを一文字も動かさなかったレビューが、結果として最も長く使われる基準を残したことになる。これは立派な成果であり、指摘ゼロのレビューが失敗ではない理由でもある。

機械的な指摘を外注できる時代になったからこそ、人間が担うレビューの価値は「正しさの検出」から「意図の言語化を促すこと」へ移っていく。良いレビュアーの条件も、誤りを見つける目から、的確な問いを立てる力へと静かに変わっていくはずだ。

この力は一夜で身につくものではなく、設計の判断軸そのものを学ぶところから始まる。土台として、定番の技術書を読み直すことが役に立つ。

https://s-tasklog.com/books/general

tasklogは、実際に読まれ・引用され続けている技術書や学習記事を集めている場所だ。