伝わるコードレビュー - 読書記録¶

📁 docs/reading-notes/20260408_025719_伝わるコードレビュー.md

読んだ目的¶

コードレビューで「意図が伝わらない」「説明ができない」「伝え方がまずくて誤解される」という課題を解決するため。以下を明確にしたい：

コードレビューは「チェック・○×付け」ではなく、二人三脚で良いソフトウェアを作るためのコミュニケーションである。心理的安全性を土台に、意図を正確に伝え合うことで品質とチームの成長を両立させる。

パターン	具体例	問題点
悪意の疑い	純粋な質問を「批判された」と受け止める	不必要な対立・誤解が生まれる
言いがかり	「ちゃんとチェックしないからだ」と責める	心理的安全性を壊す
過度な防衛	「大体大丈夫だと思います、でも自信はないです…」と曖昧なコメント	品質判断を放棄している
思考停止の修正	理由もわからず「反論が面倒だから言われた通りに直す」	理解なき修正で品質が下がる
虚勢	「自分のコードと大差ないので修正しない」と全拒否	改善機会を失う
優位性の誇示	「ちゃんと考えれば気付けたはず。なぜ気付けないのか」と責める	レビューイの委縮・成長阻害

悪い例:

このケースはどういう経路を想定していますか？

良い例:

この処理は〇〇のケースも通る可能性があると思ったのですが、
その場合の動作を確認したく質問しました。
想定ケースを教えていただけますか？

悪い例:

レビュアー: 「ここはなぜこういう処理にしたのですか？」
レビューイ: 「こういう書き方に直しました」（意図を答えていない）

良い例:

レビュアー: 「ここはなぜこういう処理にしたのですか？」
レビューイ: 「〇〇の理由からこの実装を選びました。
           ご指摘の点で懸念があれば教えてください」

#	アクション	具体的に
1	コメントに意図と期待回答を添える習慣化	レビューコメント投稿前にセルフチェックする
2	アイメッセージを使う	「私はこう思う」「〇〇のケースが気になりました」など
3	説明型フィードバックの実践	「こうした方がいい」ではなく「こうすればこうなる」の形で伝える
4	質問コメントへの誠実な回答	修正だけでなく、意図を言語化して返す
5	レビューコメントを理解してから進める	不明点は「なぜそうすべきか」を正直に聞く
6	チームのコードレビュー方針たたき台の共有	本書の内容を踏まえてガイドラインを整理・チームで議論する

この書籍の内容を人に伝える・アウトプットする際の改善ポイント：

チームで共有するスタンス・ルールの素案。別途議論・精査が必要。