はじめに
自分のチームでチーム内コードレビューが導入されたのは、1年ほど前のことでした。
当初は「レビューを受ける側」だった自分も、実務経験が2年目に入り、最近では「レビューする側」に回る機会も増えてきました。
コードレビューというと技術的な部分に目が向きがちですが、実際に経験してみて思ったのは、非技術的な部分こそレビューの質、ひいてはコードの品質を左右するということです。
例えば、伝え方ひとつで相手の受け取り方は大きく変わりますし、何を指摘すべき/しないべきかの判断にも「人と関わる力」が求められます。
今回は、自分自身がレビューを通じて感じた、 「技術以外の大切なこと」 について整理してみたいと思います。
1. 言葉遣いに配慮する
特に言葉遣いに気を付けたいのが、テキストベースのコードレビューの場合です。
テキストはローコンテクスト（情報が明示的に言語化される必要があるコミュニケーションスタイル）な媒体なので、言葉のニュアンスや意図が伝わりづらいです。
そのため、口頭なら問題ない言い回しでも、文字にすると攻撃的・冷淡に見えてしまうことがあります。
【攻撃的に見えてしまう例】
「〇〇という書き方にしない理由はなんでしょう。」
【言葉遣いに配慮した例】
「この部分は〇〇の理由で別の書き方も検討できそうです。どうでしょう？」
たとえ技術的に正しい指摘であっても、伝え方が原因で心理的安全性が損なわれれば、長期的には逆効果です。
レビュイーや他のレビュワーが意見を出しにくくなり、特定のメンバーの声ばかりが通る状態になると、本来指摘されるべき潜在的な問題が見過ごされるリスクも高まります。
また、エンジニア文化の一部として 「マサカリを投げる（＝鋭く厳しい指摘をする）」 というスタイルがありますが、これをそのままチームに持ち込むのは注意が必要です。
マサカリ文化は指摘事項を素早く端的に伝えることができるという点で有用ですが、これを前提にしたコミュニケーションを取る場合は、事前に「そういうスタイルでやっていいか」をチームで合意しておくことが大前提です。
合意なきマサカリは、ただのマナー違反として受け取られてしまいます。
2.指摘の際に理由・方針も示す
ただ漠然と「この部分はこの書き方のほうがよい」と伝えても、
レビュイーからすると「なぜここを変える必要があるのだろう？ 元のままでも十分見やすいのに...」と疑問が残ることがあります。
特に、ベテランのレビュワーが経験の浅いレビュイーにこのような指摘をすると、
指摘の意図が伝わらず、かといって質問しづらいという状況が起こりえます。
その結果、レビュイーは
「よく分からないけど、言われたとおりに直すか……」
と対応してしまい、学習や成長の機会を失ってしまう可能性があります。
【理由・方針を示していない例】
「なんでこんな書き方にしたんですか？この書き方のほうが良いです。」
【理由・方針を示している例】
「ここは〇〇というデザインパターンを使うとスッキリ書けるかと思います。」
すべての指摘に丁寧な説明を添える必要はありませんが、
パターン名や技法の名前を出すだけでも、レビュイーが自発的に学ぶきっかけになります。
レビューの目的は「正すこと」だけでなく、「育てること」でもあるという視点を持つと、伝え方にも変化が出てきます。
3. 細かすぎる指摘は避ける
チームで明確に決まっていないことまで細かく指摘すると、
レビュイーは「そこまで気にしないといけないのか…」と委縮してしまうことがあります。
もちろん、バグにつながるコードや明らかなアンチパターン、チーム内のコーディング規約に反しているものなどは、積極的に指摘すべきです。
ですが、コーディングスタイルや命名の些細な違いのように、
個人の好みが分かれるレベルの内容まで細かく指摘するのは、相手を一人の技術者として尊重する姿勢に欠けているとも言えます。
好みが分かれる程度の問題であれば"指摘"ではなく、"提案"として柔らかく伝えるのが良いと思います。
【細かすぎる指摘の例】
このメソッドはこう書いた方が個人的に好みです。
【配慮ある提案の例】
このメソッドですが、一案として、こう書いた方が個人的にはスッキリするかと思いました。お気に召したらご採用ください。
たとえ経験年数に差があったとしても、レビュイーも一人の技術者です。
「自分だったらこう書く」ではなく、「この実装でチームとして問題ないか」という視点を持つことが、健全なレビューにつながります。
最後に
レビュイーにも心構えは必要
ここまで、レビューする側が気をつけたい非技術的なポイントについて述べてきましたが、レビューされる側にも心構えは必要です。
レビューは一方通行ではなく、双方向のコミュニケーションです。
指摘はあくまで「コード」に対するものであり、人格や能力の否定ではありません。
「自分と自分のコードは別物」と考えることができれば、防御的にならず、建設的なやりとりがしやすくなります。
ソフトスキルの重要性
本記事で紹介したような配慮や姿勢は、いわゆるソフトスキルに属します。
このようなソフトスキルに対して、エンジニアの中には、
「いちいち言葉遣いにまで気を遣うなんてあほくさい、時間がもったいない。」
と思う方もおられるかもしれません。
しかし、これは単なる気遣いではなく、チームで成果を出すための再現可能な技術でもあります。
どれだけ技術力が高くても、チーム内の信頼が崩れればアウトプットは鈍ります。
一方で、ソフトスキルが整ったチームは、同じ技術レベルでも、より高い成果と良い雰囲気の両立が可能です。
レビューにおける言葉遣い、伝え方、姿勢...
それらを磨くことは、技術力を高めること同じくらい大切な投資です。
エンジニアとしての成長を考えるとき、コードだけでなく、伝え方も育てていくことを、これからも大切にしていきたいと思います。