動いてはいる、テストも通っている。でも「これで承認していいんだっけ」と手が止まる瞬間、レビュー担当になったばかりの人ほど多いはずだ。そのモヤモヤを言語化できないまま経験則でOKを出し続けると、レビューの質はレビュアー個人のカンに依存したままになり、チーム全体のコード品質は誰かが不在になるたびにブレる。『コードレビューの教科書』は、その「何を見て、どう判断すればいいのか」を具体例つきで整理してくれる本だった。

レビューがうまくいかない理由を先に潰しておく

本書は最初に、コードレビューがうまくいかない10個の課題とレビュアー・レビュイーそれぞれの役割から入る。「厳しすぎて心が折れる」「逆に緩すぎて意味がない」といった、レビュー運用でありがちなつまずきの正体を先に言語化しているので、自分のチームのどこが崩れているかを当てはめながら読み進められる。

「7つの観点」で判断基準を持てるようになる

核になるのは、設計・理解容易性・命名・スタイル・機能や性能・テスト・ドキュメントという7つの観点だ。この観点ごとに「何を見るべきか」と「どう判断するか」が具体的なコード例とともに示されていて、感覚頼みだったチェック項目が一気に言葉にできるようになる。後半には10本のケーススタディがあり、実際のコードを前にしてどう考えるかを追体験できる構成になっている。

読んでよかったポイント

レビューコメントを書くときの言い回しに迷わなくなった。指摘の厳しさと伝わりやすさのバランスを、具体例から掴める
「設計」と「スタイル」を同じ熱量で指摘していた自分の癖に気づけた。観点ごとに重みが違うと分かると優先順位がつけやすい
レビューを技術力を伸ばす場として使う視点が持てた。指摘して終わりではなく、自分の実装にも跳ね返す読み方ができる
チーム開発のプロセス改善に話が広がる章があり、個人のレビュースキルだけでなくチームの回し方まで見直すきっかけになった
AIが生成したコードをどう評価するかという章があり、AIコーディングが当たり前になった今の現場感覚に合っている

さらに広げて読むなら

レビューで指摘する側の視点を固めたら、次はコードそのものを改善する側の視点も持っておきたい。実践で学ぶコード改善の極意 5行ルールで強く美しくリファクタリングするは、レビューで指摘されがちなコードを自分の手でどう直していくかに焦点を当てているので、あわせて読むと理解が立体的になる。

まとめ

コードレビューは経験を積めばいつか自然にうまくなる、というものでもない。観点を言葉にして持っているかどうかで、指摘の質もスピードも変わってくる。若手からレビューを任されるようになった人はもちろん、後輩指導に手応えを感じきれていない中堅エンジニアも、まず目次の7つの観点に自分のチームを当てはめてみるところから始めてみてほしい。

コードレビューの教科書――なんとなく承認から抜け出すための観点と判断基準