はじめに
この記事は『伝わるコードレビュー』の学びを整理しながら紹介するシリーズの第6回です
全11回のうち今回は、架空の開発現場で起きやすい具体的なコミュニケーションの問題と解決法を扱う19のケースの中から、ケース13〜16を紹介します
- ケース13 コメントへの訂正情報の不足
- ケース14 放置された議論
- ケース15 見過ごされた質問コメント
- ケース16 想像に基づく修正
いずれも「レビューコメントのやり取りにおけるコミュニケーションのすれ違い」が原因で発生する問題です
レビューの精度や効率を高めるためには、コードそのものだけでなく、やり取りの質に目を向ける必要があります
ケース13 コメントへの訂正情報の不足
問題点
レビューコメントで「ここは誤りです」と指摘されたが、実際は正しいコードだった
このとき「正しいです」や「問題ありません」とだけ返すと、レビュアーにはなぜ正しいのかが伝わらない
結果として、誤解の原因や背景が解消されず、同じ指摘が繰り返される可能性がある
解決策
間違った指摘は、実は改善のヒントでもある
なぜレビュアーが誤解したのかを一緒に探ることで、認識の齟齬やコードのわかりにくさを明らかにできる
- 間違いの理由を掘り下げる
- レビュアー: どのような思考で誤った結論に至ったか
- レビュイー: その指摘が誤りだと判断した根拠は何か
- 認識をすり合わせる
- なぜ誤解が生じたのか
- どうすれば誤解が生じにくいコードや設計にできるのか
このやり取りを通じて「理想的な状態」を議論することが、レビューの本質的な価値につながる
ケース14 放置された議論
問題点
PRの中で「外部仕様の確認が必要」といった議題が出たものの、誰も担当を引き受けないまま時間だけが過ぎ、最終的に放置されてしまうケースがある
議論の末にアクションプランが明確にされないことが原因
解決策
議論を終わらせるだけではなく「誰が・いつまでに・何をやるか」を決める必要がある
- アクションプランを具体化する
- e.g. 「Aさんが顧客に確認し、金曜までに回答する」
- フォローを忘れない
- 「確認進んでいますか？」と声をかける
- チケットや管理ツールに記録して進捗を可視化する
議論が動かなくなること自体は珍しくない
大事なのは、議論を前進させる仕組みを整えること
ケース15 見過ごされた質問コメント
問題点
PRコメントで「この仕様の場合どうなるのでしょう？」と質問があったのに、PRが承認されてしまい、回答が放置されることがある
質問コメントは軽く見られがちだが、バグの芽を事前に摘む重要な手がかりである
解決策
- レビュアーは質問の回答を促す責任がある
- 未回答なら「こちらの質問は確認いただけましたか？」と伝える
- チャットや口頭で補足してもよい
- 承認前に必ず質問に答えてもらう
- コメントの属性を明示する
- [must], [should], [fyi] などで意図をはっきりさせる
また、レビュイー側も「コメントが全て解決されているか」を確認する習慣を持つことが望ましい
質問が軽視されない環境を作ることが、チーム全体の品質を守る
ケース16 想像に基づく修正
問題点
「このメソッドはオーバーライドしているので修正してください」とコメントされたとき、レビュイーが「オーバーライド」という用語を理解していなかった
その結果、意味を想像して的外れな修正をしてしまい、再度指摘を受けることになった
解決策
レビューコメントは相手の理解度に合わせることが必要
- レビュアー
- 専門用語を使う場合、相手の知識を考慮する
- 意味が伝わらなければ補足説明を追加する
- レビュイー
- わからないことを想像で処理せず質問する
- 「このように理解しましたが、あっていますか？」と確認する
また、安心して質問できる関係性を普段から作っておくことも大切
誤解を恐れて曖昧に対応するよりも、率直に尋ねる方が結果的に効率が良い
おわりに
今回はケース13〜16を紹介しました
- コメントへの訂正情報の不足
- 放置された議論
- 見過ごされた質問コメント
- 想像に基づく修正
どのケースも「ちょっとしたすれ違い」が原因でありながら、放置すれば大きな問題に発展するものです
レビューの質は、コードそのものよりも「どう伝え合うか」に左右される部分が大きいと感じます
次回はPart2最後として、ケース17〜19を取り上げます