前回の記事
こちらの記事の続きの話です。
レビューは「コードを見る場」ではない
コードレビューというと、ロジックの正しさやバグの有無をチェックする場、というイメージを持つ人は多いと思います。もちろん、それは今でも重要な役割です。ただ、AIの活用が進んだ現在、レビューの重心は少しずつ変わってきていると感じています。
AIを使えば、構文ミスや典型的な改善点、パフォーマンス上の懸念は、実装段階でかなり拾えるようになりました。その結果、レビューの場で「正しいかどうか」だけを見る価値は、相対的に下がっています。
では、レビューで人が何を見るべきなのか。
過去3本の記事で紹介した内容が、そのまま答えになると考えています。
問いと前提が曖昧なコードはレビューで詰まる
初回の記事で書いたように、問いが整理されていない実装は、途中で判断が揺れます。
2本目の記事で書いたように、前提が共有されていない議論は噛み合いません。
これらは、レビューの場でもそのまま現れます。
- 何を解決したいコードなのかが分からない
- どこまでを想定しているのか読み取れない
- 「それは前提に含まれているのか」が判断できない
こうしたコードは、レビューコメントが増えがちです。そして多くの場合、レビューが重くなっている原因は、コードの複雑さそのものではありません。問いや前提がコードから読み取れないことが原因です。
レビューで最初に見るべきはロジックではない
レビューで、最初に見るべきはロジックの細部ではなくそれ以外の部分でしょう。
まず確認するのは、次の点です。
- この実装は、何を解こうとしているのか
- どんな前提のもとで書かれているのか
- どこまでを責務として持っているのか
これらがコードやコメント、設計の文脈から読み取れるかどうかを見ています。
ここが分かれば、ロジックの妥当性は比較的スムーズに判断できます。
逆に、ここが分からないと、どれだけコードを追っても判断に迷います。その結果、「この実装は良いのか悪いのか」という本質ではないところで時間を使うことになります。
判断が説明できる形で残っているかを確認する
3本目の記事で書いたように、設計判断が説明できる形で残っているかどうかは、非常に重要です。レビューでは、その「説明可能性」を確認しています。
- なぜこの構造を選んだのか
- 他の選択肢は検討されたのか
- 何を優先し、何を切り捨てたのか
これらが読み取れる実装は、レビューがしやすいです。
また、後から変更が入ったときにも、安心して手を入れられます。
判断がブラックボックス化しているコードは、その場では通せたとしても、後から必ず問題になります。レビューは、その兆候を早めに見つける場でもあります。
レビュー文化でありマネジメントの話でもある
レビューで何を見るかは、個人のスタイルの問題に見えるかもしれません。しかし実際には、チームの文化やマネジメントと強く結びついています。
レビューで「意図や前提を見る」ことが当たり前になると、実装者は自然とそこを意識して書くようになります。問いを整理し、前提を言語化し、判断を残す、という一連の流れがチームに浸透します。
結果として、レビューの重さが軽減されます。
むしろ、手戻りが減り、チーム全体のスループットが上がります。
レビューは、個々のコードを良くする場であると同時に、思考の仕方を共有する場でもあります。
AI時代のレビューは、最終チェックではなく接続点
AI時代において、レビューは「最後に正しさを確認する場」ではなくなりつつあります。
問い、前提、判断という流れを、チームとして接続するための場になっていきます。
- 問いは妥当か
- 前提は揃っているか
- 判断は説明できるか
これらをレビューで確認することで、技術とマネジメントが自然につながります。
この4本の記事で書いてきた内容は、特別な理論ではありません。
日々の実装とレビューの中で、少し意識を変えるだけで実践できます。
AI時代だからこそ、人が担うべき役割は曖昧になったのではなく、むしろはっきりしてきました。
レビューは、その役割が最も表に出る場所だと感じています。
Discussion