【注意】本記事は「なんとなくレビューできるようになりたい」人向けではありません。
今やAIがコードを書き、一次レビューまでしてくれる時代です。
しかし、彼らの成果物はまだ100%の品質ではなく、かつ責任を取りません。
最後に本番環境へデプロイする判断を下し、その結果に責任を持つのは私たち「人間」です。
この記事は、AI時代において 「人間がやるべき高次元のレビュー」 にフォーカスし、徹底的にレビュー能力を鍛えたいエンジニアに向けて書いています。
楽にLGTMを出したい人は、ブラウザバックを推奨します。
第0章：鉄の掟
本題に入る前に絶対的なルールを設けます。
これから紹介するのはスパルタ式ですが、これは 「自分自身の眼力を鍛えるためのスパルタ」 であり、他者を攻撃するためのものではありません。
-
コードには厳しく、人には優しく
指摘の解像度は極限まで高めますが、伝え方には最大の配慮（敬意）を払います。 -
強要の禁止
この基準を、合意のないチームメンバーや初心者にいきなり押し付けてはいけません。あくまで「自分がバグを見逃さないための訓練」として実践してください。
1. レビューとは「承認」ではなく「責任の移譲」である
多くの人がコードレビューを「承認プロセス（スタンプラリー）」と勘違いしています。違います。
レビューとは 「責任の移譲」 です。
LGTMを押してマージした瞬間、そのコードの責任は実装者と同等、あるいはそれ以上にレビュアーであるあなたに移ります。
基準はたった一つ。
「このコードの実装内容を、自分は『自分の実装』として、上位の人間に完璧に説明できるか？」
もし実装者が不在の時にトラブルが起きても、「自分が書いたかのように」即座に対応・説明できる状態にする。
これができないなら、あなたはAIが書いたコードの責任を取ることはできません。
この「他人のコードを完璧に説明できるスキル」こそが、AI時代にエンジニアが生き残るための必須スキルです。
2. 【準備】人間が機械の仕事をするな
「人間の脳」という高コストなリソースを、機械ができることに使ってはいけません。
-
Human Linterになるな
タイポ、フォーマット、未使用変数はLinter/Formatter/静的解析で弾きます。「人間がタイポを指摘している」時点でそのチームのプロセスは敗北しています。 -
基本動作の担保
基本的なロジックエラーはUnit Test/Feature Testで担保します。 -
CIは門番
CI (GitHub Actions等) がGreenでないPRは、そもそもレビュー対象外とします。「後で直します」は甘えです。
レビュアーが担保すべきは、タイポでもエラーでもなく、 「可読性」「設計の妥当性」「プロジェクトの統一感」 です。
3. 【実践】コードを見る前の「0秒思考」
ここからが具体的なスパルタ・メソッドです。
多くのレビュアーはすぐにコードの差分を見に行きますが、それは間違いです。
Step 1: 意図の確認と俯瞰
まずPRのタイトルと概要を見ます。
- 「何をしたか」が不明瞭なら、この時点で即座に質問します（※「書いてください」という指示ではなく、「何をしたかの確認」として質問する）。
- タスク全体を俯瞰し、その変更が「今、そこで」やるべき適切な対応かを判断します。木を見て森を見ずになっていないかを確認します。
Step 2: 瞬時に「脳内実装」する（重要☝️）
仕様を把握したら、コードを見る前に10秒以内で「自分ならどう実装するか」を脳内で構築します。
- ディレクトリ構成はどうするか？
- クラスやメソッドの責務はどう切るか？
- エッジケースはどう処理するか？
これを習慣化するには、日頃から「自分ならどう書くか」を四六時中考える鍛錬が必要です。
この「自分の正解（仮説）」を持って初めて、レビューのスタートラインに立てます。
自分の「正解」がない状態でコードを見るのは、レビューではなくただの「読書」です。
比較対象があって初めて、それは「検証」になります。
4. 【検証】ブラックボックス・テストと構造解析
Step 3: まずは動かす
コードを読む前に、ローカルにPullして動作確認します。レビュアーは 「壊すつもり」 で触ってください。
実装者は「正常系」しか確認していないことが多々あります。
- エラーが起きそうな操作
- 境界値
- 意地悪な入力
これらを試します。驚くべきことに、この段階で期待通り動かない（バグがある）PRは多々あります。コードレビュー以前の問題で弾くことができます。
Step 4: 差分を「答え合わせ」として見る
ここで初めてコードを見ます。自身の脳内実装と、実際のコードの「差分」に着目します。
- 自分と同じ： OK。
-
自分と違う： ここがレビューの最重要ポイントです。「なぜ違うのか？」
- 相手の考慮漏れか？
- 自分の想定外の優れた実装か？
- 設計思想の違いか？
浮かび上がった差分から、実装者の「意図」や「思考パターン」を読み解きます。
もし自分の考えより相手の実装が優れていれば、腹落ちさせて自分の引き出しに取り入れます。
Step 5: 構造とパフォーマンス
-
命名と責務
- 関数名やクラス名は実装の「要約」になっているか？
- 名前と中身に乖離（嘘）はないか？ 抽象的すぎて役割が不明瞭ではないか？
-
統一感
- プロジェクトのアーキテクチャに沿っているか？
- 変に浮いた実装になっていないか？
-
パフォーマンス
- 「今」動くだけでなく、データが1万倍になった時でも耐えられるか？（N+1、不必要なループ、計算量）
-
拡張性
- 今後似た機能が作られる際、横展開しやすい抽象化ができているか？（逆に、過剰な共通化で可読性を落としていないか？）
5. 【対話】指摘は「Ask」で、敬意を持って
間違いを見つけても、マサカリを投げてはいけません。
目的は「相手を打ち負かすこと」ではなく「品質を高めること」です。
-
正解はないと心得る
自分の脳内実装が絶対ではありません。期待通り動くことが前提であれば、やり方に正解はありません。 -
Askベースで伝える
「ここはこうすべき」と断定するのではなく、「〜という意図ですか？」「〜の場合はどうなりますか？」と問いかけ、相手に思考させ、説明させます。 -
知識をひけらかさない
長文の説教コメントは不要です。エラー系は端的に指摘します。 -
好みは
[IMO]
明確なエラーでない「自分ならこうする（明確なメリットまではない）」という意見は、[IMO]（In My Opinion / 私の意見ですが）を付け、強制しません。 -
元気よく！
最後は「レビューしました！いくつかコメント書いたので確認お願いします！」と元気よく伝えます。
PRのリンクも必ず貼り、相手に探す手間を取らせないのもマナーです。「確認してください。」だけだと冷たいので、実装者への敬意を忘れないようにしましょう。
対面レビューの推奨
可能であれば、テキストだけでなく対面でのレビューを推奨します。
- 相手の理解度が測れる
- 相手の実装の癖（得意・苦手）が読み取れる
- ニュアンスのズレを防げる
これらを知ることは、マネジメントやタスク割り振りにおいても大きなメリットになります。
おわりに：AI時代の「最後の砦」として
AIはコードを書けますが、文脈を理解し、将来のリスクを背負うことはできません。
「他人のコードを、まるで自分が書いたかのように自信を持って説明し、マージする」
この「責任移譲」を完遂できるスキルこそが、AI全盛期においてエンジニアが生存するための最後の砦となります。
今日からただの承認者ではなく、真のレビュアーとしての鍛錬を始めましょう！