「伝わるコードレビュー」を読み進めてみた
本記事は『伝わるコードレビュー』を読んで得た学びをもとに構成しています
第1回：信頼関係とコードレビュー
はじめに（全11回シリーズの第1回）
この記事は、全11回にわたって『伝わるコードレビュー』の内容とそこから得た学びを紹介していくシリーズの第1回です
初回では、Part1を通じて明確になった「コードレビューの質は、信頼関係に支えられている」という本質的なテーマについて掘り下げていきます
自分の過去のレビュー経験と重ねながら、特に印象的だった点を取り上げてみます
コードレビューの本質は「信頼」と「コミュニケーション」
本書が最も強調しているのは、コードレビューとは「コミュニケーション」であるという点です
それも、ただのやり取りではなく、相手との信頼関係が前提にあるからこそ成立するコミュニケーション
例えば、何気ないレビューコメント ──「なぜこのメソッドを使ったの？」── ですら、関係性によっては「試されている」「責められている」と受け取られてしまう
実際に、相手の受け取り方次第で良かれと思ったコメントが逆効果になった経験もある
信頼があるチームでは「わからない」「説明してほしい」と素直に言える逆に信頼がないと、曖昧な表現でお茶を濁すようなやり取りに終始してしまう
レビューの内容以前に、この関係性がボトルネックになっていたケースは多いはず
PR型レビューと役割の明確化
現代の開発現場で主流となっているPR型コードレビュー
- 実装者がPRを作成
- レビューを依頼
- レビュアーが確認・コメント
- 修正後にApproveしてマージ
このプロセスの中で、レビュイーとレビュアーの役割が不明確なままだと、すれ違いが頻発する
レビュイーに求められること
- この変更の背景や目的の明示
- なぜこの実装なのかという設計意図
- 動作確認の方法と結果
- 特に見てほしい観点
レビュアーに求められること
- 実装の意図と仕様との整合性の確認
- 指摘内容に対する明確な根拠
- 質問の背景を説明する姿勢（なぜそれを聞くのか）
コメントが曖昧だったり数が多すぎると、レビュイーは「全否定された」と感じてしまう
実際に、過去に自分が受けたレビューでも「言いたいことはわかるけど、結局どうしたいの？」と戸惑った記憶がある
「怠惰の想定」が関係性を壊す
本書の中でもとても印象的だったのが、「怠惰の想定」という言葉
たとえば、「この人、どうせ動作確認してないんだろうな」という決めつけ
しかし実際は、確認はしたけどうっかり漏れていたり、そもそも検証観点が抜けていたのかもしれない
自分自身も何度か経験があるが、「ちゃんとやったつもり」でも漏れることはある
そういう時に「怠けた」と決めつけるのではなく、「何が足りなかったのか？」を一緒に考えるスタンスが必要
あるいは、CIでの自動チェックが漏れを防ぐ仕組みになるかもしれない
技術とプロセスの両面で支えることが、健全なレビュー文化を作る一歩になる
レビュー文化を支える前提：信頼と共通認識
本書の締めくくりに近いメッセージのひとつが、
「敵は相手ではなく、解決すべき問題である」
という考え方
レビューを通してチーム全体が良くなることを目的とするならば、立場の違いや上下関係、優劣といった「関係性への拘泥」は不要だと強く感じた
信頼関係のない状態では、レビュー前の一言一言に深読みが走ってしまう
逆に、関係性が構築されていれば、「これ何か理由があった？」といった軽いやりとりで、必要な背景情報が引き出せる
おわりに
コードレビューは技術的な儀式ではなく、共同作業であり、チーム文化そのもの
この本を読みながら、自分のレビューの仕方やコミュニケーションの姿勢を何度も振り返ることになった
全11回のシリーズとして、次回はPart1の後半に触れていく予定
コードレビューに違和感を感じたことがある人、あるいはこれから改善したいと考えている人には、必ず刺さる内容になるはず
次回もどうぞお楽しみに