コードレビューで度々問題になるのが、コミュニケーションです。特に、レビュアーのコメントを起点として問題に発展することが多いです。たとえば、次のようなコメントを見たことはありませんか？
– 「このコード、なんでこんな書き方してるの？」
– 「ここ、もっと効率的に書けるよね」
– 「この変数名、意味不明じゃない？」
これらのコメントは、一見すると技術的な指摘に見えますが、実際には相手にとっては「攻撃的」や「否定的」と受け取られるでしょう。多くの場合、レビュアーは立場が上であり、こうしたトゲのあるコメントは、開発担当者を萎縮させてしまいます。こうした心理的安全性の低さは、チーム全体のパフォーマンスを低下させる要因となります。
では、どうすれば相手にとって建設的なフィードバックとなるのでしょうか？その答えは、レビューコメントの書き方にあります。
レビューコメントの基本原則
建設的なフィードバックを実現するために、レビューコメントとして心がけるべき基本原則をいくつか紹介します。
- 相手の立場に立つ
- 具体的な提案をする
- ポジティブな言い回しを心がける
- 命令ではなく質問形式を使う
- 学びの機会を提供する
- コメント + Why
- 直接話す
相手の立場に立つ
レビュアーは、相手のコードに対して批評を行う前に、そのコードを書いた人の立場や状況を理解することが重要です。相手がどのような背景でそのコードを書いたのか、どのような制約があったのかを少しでも念頭に置くと、より適切なフィードバックが行えるようになります。
具体的な提案をする
抽象的な指摘ではなく、具体的な指摘を心がけましょう。「ここを変えてください」ではなく、「この変数名はXの意味に読めるので、Yにするとより明確になります」といった具体的な提案をすることで、相手は何をどう改善すればよいのかが明確になります。
ポジティブな言い回しを心がける
テキストベースのコミュニケーションは、書いている本人が思っている以上に冷たい印象になります。問題がこじれてから「そんなつもりじゃなかった」と言っても、意味がありません。ポジティブな言い回しを心がけ、「ここは良いと思いますが、こうするとさらに良くなるかもしれません」といった形で提案することが大切です。
命令ではなく質問形式を使う
命令形での指摘は、相手に対して圧力をかけることになります。特に自分のほうが職位が上だったり、経験年数が多い場合にはそうです。代わりに質問形式を使い、相手が自分で考える余地を与えましょう。「このコードはこう書くべきでは？」ではなく、「この部分、こう書くとどう思いますか？」といった質問形でコメントすると、相手も受け入れやすくなり、成長機会にもつながります。
学びの機会を提供する
コードレビューは単なる指摘ではなく、学びの機会であると認識しましょう。レビュアーは、相手にとって有益な情報を提供する視点を忘れないようにしましょう「このコードはこう書くべきでは？」ではなく、「このような書き方をすると、パフォーマンスが向上しますよ」といった形で、学びの要素を含めると良いでしょう。
コメント + Why
コメントを書く際には、単に「こうしたほうが良い」と指摘するだけでなく、その理由も添えることが重要です。「なぜ〜したほうがいいかというと、〜だからです」という形で、なぜその変更が必要なのかを説明すると、相手は納得しやすくなります。
直接話す
説明が複雑になったり、相手が誤解しやすい内容の場合は、直接説明する方がいいです。特に、感情的な要素が絡む場合や、長文のコメントが必要な場合は、対面やビデオ通話でのコミュニケーションが効果的です。直接話すことで、相手の反応を見ながら説明できるため、誤解を避けやすくなります。
そのうえでコメントを残しておくと、相手の心象はまったく違うものになるでしょう。コードレビューのようにオンラインで行っていると、ついオンラインだけで完結したくなります。しかし大事なのは心理的安全性であり、円滑なコミュニケーションです。それがチームの開発生産性を高めることにつながります。
良いコメント・悪いコメントの例とその言い換え
ここでは、いくつかの例を挙げて、良いコメントと悪いコメントの違いを示します。
修正をうながす場合
- ✕「ここ変えて」
- ◯「この書き方だと〜の返り値としては不適切な可能性があります。〜のように書き換えるといいです」
悪い例の場合、なんの説明もなく変更を矯正されているように感じられます。指摘を受けた側は、なぜその変更が必要なのか理解できず、立場的にただ従うしかありません。これが続くと、心理的安全性が低下し、レビュー提出が億劫になったり、萎縮してしまいます。
いい例では、なぜその変更が必要なのかを説明しています。相手はなぜ変更すべきか、理由を理解しやすく、納得して変更に応じられます。また、次回同じようなケースが発生したときに、事前に学びに沿った書き方を選べるようになるでしょう。
バグの指摘をする場合
- ✕「バグってる」
- ◯「こういうケースで仕様と異なる挙動をしているようです。〜の部分の修正と、〜に合ったテストケースを追加してください」
悪い例では、単に「バグってる」と指摘するだけで、どの部分が問題なのか、どのように修正すればよいのかがわかりません。これでは、相手はただ不快感を感じるだけで、改善のための具体的なアクションを取れません。
良い例では、どのケースで問題が発生しているのかを具体的に示し、どのような修正が必要なのかを明確にしています。これにより、相手は自分で考え、改善策を実行しやすくなります。
不具合の修正においては、テストケースを追加して発見、回避できるケースが多いでしょう。そのため、単にロジックの修正だけでなく、テストケースの追加も提案することで、相手にとって学びの機会を提供できます。
レビューはバグ発見の麺もありますが、確実ではありません。テストケースを適切に用意し、テストによって品質を保証するのが大事です。
ケース別の例
- ✕「このコード、なんでこんな書き方してるの？」
- ◯「この部分は、こう書くとパフォーマンスが向上する可能性があります。例えば、〜のように書き換えると良さそうです」
質問系で書くのはいいですが、単に「なんで？」と聞くだけでは、相手は防御的になりがちです。良い例では、なぜその書き方が良いのかを説明し、具体的な改善案を提示しています。これにより、相手は自分で考える余地を持ちつつ、学びの機会を得ることができます。
ジュニアレベルのエンジニアの場合、自分のコードに対して自信がない人も多いでしょう。そうした人に対して、「なんで？」を強調するコメントは、相手を萎縮させるだけです。そうしたエンジニアの教育の場であると考えれば、学びにつながるコメントが大事になります。
具体的な命名の指摘
- ✕「この変数名、意味不明じゃない？」
- ◯「この変数名はXの意味に読めるので、Yにするとより明確になります」
悪い例では、単に変数名が不適切であると指摘するだけで、どのように改善すればよいのかがわかりません。これでは、相手はただ不快感を感じるだけで、改善のための具体的なアクションを取れません。
もしコーディング規約に沿っていないのであれば、その旨も指摘すると良いでしょう。たとえば「コーディング規約では、変数名はキャメルケースで書くことになっています。ここはスネークケースになっているので、キャメルケースに変更してください」といった具合です。
コメントの温度感を調整する表現集
レビューを担当する方にぜひ覚えておいてほしいのが、コメントの「温度感」です。温度感とは、コメントが持つ感情的なニュアンスやトーンのことです。以下に、温度感を調整するための表現集を紹介します。
ポジティブな温度感を出す表現
– 素晴らしいコードですね！
- ここは特に良いと思います
- こうするとさらに良くなると思います
- このアプローチはとても効果的ですね
日本人では「褒める」ことが苦手な人も多いですが、ポジティブなフィードバックは心理的安全性を高め、相手のモチベーションを向上させます。特にテキストだけでやり取りする場合には、多少オーバーな表現でも、相手にとっては嬉しいものです。
まず相手の実績に対して感謝の意を示し、ポジティブなフィードバックを与えることを心がけましょう。その上で、改善点を提案することで、相手は受け入れやすくなります。
ネガティブな温度感を和らげる表現
- ここは少し気になる点があります
- この部分、改善の余地があると思います
- ここはこうしたほうが良いかもしれません
- このコード、もう少し工夫できるかもしれません
ネガティブなフィードバックを与える際には、相手が防御的にならないように注意が必要です。「気になる点」や「改善の余地」といった表現を使うことで、相手に対して攻撃的な印象を与えず、建設的な対話を促すことができます。
また、ネガティブ表現をした際には、具体的な改善事項を提示しましょう。具体的な改善案を提示すれば、相手はストレスなく提案を取り入れられます。悩む時間はなるべく減らし、次のステップに進めるようにしましょう。
さらに、その提案について「なぜそのようにしたほうが良いのか」という理由を添えると、相手は納得しやすくなります。ネガティブなフィードバックを行う際には、相手の立場を考慮して、多方面でのフォローアップを心がけましょう。
過度な遠慮 vs 過剰な断定のバランス
コードレビューの目的はプロダクトに取り込むコード品質の向上にあります。そのため、遠慮して指摘せず、品質を下げるのは本末転倒です。適切な指摘ができるのは、普段のコミュニケーションや相手との信頼関係があってこそです。また、必要な指摘であるとお互い共通認識ができていれば、臆せず指摘できるでしょう。
ただし、過剰に断定的な表現を使うと、相手は防御的になりがちです。「このコードは絶対に間違っている」といった表現は避け、「この部分、こうしたほうが良いかもしれません」といった柔らかい表現を使うことで、相手も受け入れやすくなります。
開発者のコードには人格が反映されます。そのため、否定的なコメントは、受け取り側にとって自分の人格を否定されたような感覚になってしまうでしょう。そうした開発者の心理を理解し、適切な温度感でコメントを行うことが重要です。
まとめ
大事なのは、レビューの根幹はコミュニケーションであるという点です。正しければ何でも言って良いわけではありません。また、誰でも同じように指摘して良いわけでもありません。相互コミュニケーションである点を忘れず、かつ相手の立場に立ってコメントを行いましょう。また、必要に応じてテキスト以外のコミュニケーション手段も活用することで、より良いレビューが実現できます。
続きは良いコードレビューとは何か：その2「指摘か？提案か？」です。
おまけ：CodeRabbitの活用
CodeRabbitはAIコードレビューサービスで、GitHubやGitLabと連携してPRに対して自動的にレビューを実行します。開発者はCodeRabbitからの指摘を確認し、修正を行うことで、コードの品質を向上できます。最近リリースされたCodeRabbit for VSCodeを利用することで、ローカルでのレビューも「無料で」可能になりました。
ぜひ、CodeRabbitを活用して、コードレビューの効率化と品質向上を図ってください。
Discussion