はじめに
コードレビューはエンジニアにとって日常的な行為ですが、つい「なんとなく」で済ませてしまっていないでしょうか？
私自身、レビューを受けたり書いたりする中で、「もっと良いやり方があるのでは？」と感じることが増えてきました。
そんなとき、ネットで見かけたのが『伝わるコードレビュー』という一冊です。
実際に読んでみると、自分のレビューの質を見直すきっかけになり、「伝える力」を伸ばすためのヒントがたくさん詰まっていました。
今回はその学びと感想をまとめます。
なぜこの本を読んだか？
レビューの質に伸びしろがあると感じたから
最近はAIがコードを書く機会も増え、PRの数も自然と増加しています。
その結果、レビューが開発フローのボトルネックになりつつあるのを実感し、レビュー力を高めたいと思うようになりました。
同僚のPRがとても見やすく、自分もそうなりたいと思ったから
さまざまな企業出身のメンバーがPRを出す中で、ある同僚のPRが非常に丁寧で分かりやすく、レビューの負担を大きく下げてくれていました。
自分もそんなPRを書けるようになりたいと強く思ったのがきっかけの一つです。
今まで「なんとなくの雰囲気」でやっていたから
前職ではチーム開発やGitの文化があまり根付いておらず、レビューも雰囲気頼り。
今こそ体系的に学び直すタイミングだと感じました。
この本は誰におすすめか？
- チーム開発を始めたばかりの人
- 自己流でレビューしてきた中堅〜ベテランの人
本書では、ベテランとジュニアをモチーフにしたキャラクターのやりとりを通じて、現場でありがちなすれ違いや勘違いが丁寧に描かれています。
PRの「よくあるパターン」がケース別に扱われており、「これ、自分にもあったな……」と思わされる場面が多く、思い込みや思考のクセをリセットするのに役立ちます。
説明することの難しさを再認識
変数名や処理の流れに意図があっても、それが相手に伝わらなければ意味がありません。
レビューは「コードを書くこと」ではなく、「意図を共有すること」。
この視点を持つことの大切さを再認識しました。
特に印象に残ったポイント
伝わるコードレビューの5大ルール
-
決めつけない
- 想像や感情ではなく、事実に基づく。ハンロンの剃刀を意識する。
-
客観的な根拠に基づく
- 想像と事実を分け、エビデンス（ログや仕様）を添える。
-
お互いの前提知識を揃える
- 対話を重視し、前提を確認し合う。
-
チームで仕組みを作る
- テンプレートやLintなどで一貫性を保つ。
-
素直さを心がける
- 防衛的にならず、率直に意見を交わすことがチームの成長につながる。
前提知識を揃える重要性
- コードを見ても、背景や目的が分からなければレビューできない。
- PRには「背景」「目的」「試行錯誤したこと」「結果」を丁寧に記載する。
- スクリーンショットや動画などで視覚的に伝えるのも効果的。
説明不足がコストになる
-
「Issueを見れば分かるでしょ」は避ける。
情報を探しに行く時間はコストになるし、Issue自体が消えている可能性もある。 -
将来の自分もチームメンバーも、記憶しているとは限らない。
やって「できなかったこと」も記録する
- 試したけどうまくいかなかったアプローチも記録しておくことで、同じ議論の再発を防げる。
- プロセス自体がチームの資産になる。
期日の明示とレビュアーの指定
- 「いつまでにマージしたいか」をPRに明記する。
- 「誰かが見てくれるだろう」は思考停止。レビュアーは明確に指定する。
指摘に従うだけにならない
- 指摘を受け入れるだけでなく、「なぜそう感じたか？」の背景を共有することで、対等な対話が生まれる。
実践したいTipsまとめ
- 命令調ではなく、提案や共感をベースに伝える
- LintやPRテンプレートで仕組み化する
- はい/いいえで答えられる質問を使い、レビューの負荷を下げる
- 論破よりも納得を重視する
- before/afterの視覚的比較を使う
| 変更前 | 変更後 |
| ----- | ----- |
| <img alt="スクショ１"/> | <img alt="スクショ２"/> |
まとめ
改めて振り返ってみると、コードレビューは単なる技術行為ではなく、テキストベースのコミュニケーション能力が問われる場面だと強く感じました。
レビューは、チームでプロダクトを良くするための大切な「対話」です。
この本を通して、「どう伝えるか」の視点を持ちながら、より良いPR・レビューを実践していきたいと思います。
書籍リンク：伝わるコードレビュー