はじめに
コードレビューで、こんなコメントをもらったらどう思いますか？
このような書き方が推奨されていないことって知らないはずないですよね？
怖、、、
自分だったらまっさきにその言葉が思い浮かびます。笑
あるいは、自分がレビューする側で「伝えたいことがうまく伝わらない」と感じたことはないでしょうか。
コードレビューは、コードの品質を上げるための大事なプロセスです。
でもそれと同時に、コミュニケーション でもあります。
伝え方ひとつでチームの雰囲気が良くなることもあれば、逆にギスギスしてしまうこともあります。
最近 『伝わるコードレビュー』 という本を読んで、レビューのコミュニケーションについて改めて考える機会がありました。
この記事では、本書の内容をベースに、コードレビューで意識すべき 5つのルール を具体的な問題例・改善例とともにまとめていきます。
この記事で話すこと・話さないこと
話すこと
- コードレビューにおける コミュニケーション の5つのルール
- 具体的な問題例と改善例
話さないこと
- 技術的なレビュー観点（設計パターン、パフォーマンス改善など）
- レビューツールの使い方
ルール1: 決めつけない
まずはこちらの問題例を見てください。
このような書き方が推奨されていないことって知らないはずないですよね？
怖、、、 純粋に怖いですよね。
もうひとつ。
この書き方は〇〇の背景で書いたと思いますが、この書き方はよろしくないです。
受け取った側の気持ちはこうです。
「全然違う意図なんですが、、、」
どちらも、相手の知識や意図を 決めつけている ことが問題です。
改善例
この書き方は〇〇の理由で推奨されていません。△△のように書くとより良くなります！
この箇所に関してですが、〇〇という理由で記載されていますでしょうか？
もし上記理由であれば、以下のような記載方法もできますがいかがでしょうか？
改善例では、決めつけずに 理由を添えて提案 したり、 質問の形 で相手の意図を確認しています。
チームにはさまざまなバックグラウンドの人がいます。
若手エンジニア、その技術領域が初めての人、久しぶりにその言語を触る人。
「これくらい知っているだろう」という前提は、思っている以上に危険です。
ハンロンの剃刀
ここでひとつ、覚えておいてほしい考え方があります。
ハンロンの剃刀 という概念です。
「無能で説明できることに悪意を見出すな」
つまり、相手が間違えたコードを書いたとき、それは悪意や怠慢ではなく、単に知らなかった・忘れていた可能性が高い ということです。
人は無意識に自分を基準にして物事を考えがちです。
自分が知っていることは相手も知っているはず、と思い込んでしまう。
でも実際はそうとは限りません。
ハンロンの剃刀を初めて聞いた方は、以下の記事がわかりやすかったです。
推論ではなく確認を
相手が考えていることは、相手にしかわかりません。
コードの意図や背景を推測して決めつけるのではなく、わからないことは素直に質問しましょう。
PR のディスクリプションやコードだけでは判断できない場合、直接確認することで認識のズレを防げます。
下手に推測して話を進めると、かえって時間がかかることもあります。
迷ったら聞く。これが一番早いです。
ルール2: 客観的な根拠に基づく
次はこちらの問題例です。
多分このあたりが悪さをしていると思うんですよね。
レビューを受けた側はこう思います。
「情報が足りなくて、どこをどう直せばいいかわからない、、、」
「多分」「このあたり」「悪さをしている」——すべてが曖昧です。
これでは受け取った側が自分で原因を探し直す必要があり、時間のロスにつながります。
改善例
ここのメソッドで返り値が期待通りになっていないのを確認したため、このメソッド内の処理が原因の可能性が高いです。
具体的な 事実 に基づいているので、受け取り手の負担がぐっと減ります。
ポイントは、事実と想像を明確に分けて伝える ことです。
画面のスクリーンショットやエラーログを添付するのもとても効果的です。
「正解」が存在しないケース
プログラミングの世界には、絶対的な正解が存在しないことも多いです。
そんなときに「こうすべきだ」と断言してしまうと、それは客観的な根拠ではなく主観になってしまいます。
自分の意見を伝えるときは、以下のような工夫をすると良いです。
- 「自分はこの書き方のほうが好きです」のように 個人の意見であることを明示する
- imo（in my opinion）タグをつける
- 「根拠はないのですが、」と クッション言葉 をつける
こうすることで、相手も「あ、これは意見なんだな」と受け取れて、建設的な議論がしやすくなります。
ルール3: お互いの前提知識を揃える
こちらの問題例を見てみましょう。
この処理に関して、先方の指示通りに直しておいてください！
受け取った側の気持ちはこうです。
「『この処理』ってどの部分？ 『指示』ってどれ？」
レビューする側は文脈がわかっていても、受け取る側には伝わっていないことがよくあります。
改善例
〇〇メソッドの△△処理に関して、□□様からの1/20のSlackの指示通りに修正してください。
該当Slack：[リンク]
どの処理か、誰の・いつの指示か、参照先のリンクまで明確です。
ここまで書いてあれば、迷うことなく対応できますよね。
レビュワーだけじゃない、レビュイーにも言えること
前提知識を揃える責任は、レビュワーだけにあるわけではありません。
レビュイー側も、以下を意識するとレビューがスムーズになります。
- PR の説明に実装の背景を明確に書く
- コードだけでは実装背景がわかりづらい箇所は コメントで追記する
お互いが前提知識を揃えることで、同じゴールに向かって協力できる環境 が生まれます。
ルール4: チームで仕組みを作る
ルール1〜3は、個人の意識に関わるものでした。
でも正直なところ、「意識しましょう」だけでは限界があります。
大事なのは、意識しなくても自然に正しい行動が取れる仕組みを作る ことです。
たとえば、以下のようなものが効果的です。
- PR テンプレート: 背景・変更内容・テスト観点などを書く欄をあらかじめ用意する
- レビューガイドライン: チームとしてのレビューの方針やトーンを明文化する
- チェックシート: レビュー時に確認すべきポイントをリスト化する
ルールがあれば、誰がレビューしても 一定の水準を保ったクオリティ を出すことができます。
個人の心がけだけに頼るのではなく、チーム全体で仕組みとして整えていきましょう。
ルール5: 素直さを心がける
最後のルールは 素直さ です。
相手に対する敬意を忘れず、伝えるべきポイントを 的確に、簡潔に 伝える。
シンプルですが、これが意外と難しい。
過度な「柔らかさ」に要注意
「キツく聞こえないようにしよう」と意識しすぎた結果、内容がぼやけてしまうことがあります。
うーん、この書き方でもダメでもないんだけど、もう少しこう書いたほうが良いと思うんだ。
受け取った側はこう思います。
「ダメではないならいいんじゃないですか？（理由が知りたい）」
改善するとこうなります。
この書き方だと無駄なDBアクセスが発生するので、データ量が増えると処理が重くなり、実際に使うのが厳しくなると思います。だからこのように書いたほうが良いです。
理由が明確 だから、受け取る側も納得できます。
柔らかくすることが目的ではなく、伝わること が目的です。
素直さはお互いに求められる
素直さが求められるのは、レビューする側だけではありません。
レビューを受けた際、まずは 冷静にその指摘を受け止める こと。
その後、指摘の意図を理解し、必要であれば自分の考えを修正することが大切です。
間違っていることを認めることは、恥ずかしいことではありません。
むしろ、それが 個人の成長・チームの成長 につながります。
もし相手の指摘が間違っていると感じた場合でも、感情的にならず、事実ベースで会話する こと。
これがルール2の「客観的な根拠に基づく」にもつながってきます。
最後に
この記事では、書籍『伝わるコードレビュー』をベースに、コードレビューで守るべき5つのルールを紹介しました。
| # | ルール | ひとことまとめ |
|---|---|---|
| 1 | 決めつけない | 推論ではなく確認を。ハンロンの剃刀を思い出そう |
| 2 | 客観的な根拠に基づく | 事実と意見を分けて伝える |
| 3 | お互いの前提知識を揃える | レビュワーもレビュイーも情報を明確に |
| 4 | チームで仕組みを作る | 個人の意識に頼らず仕組み化する |
| 5 | 素直さを心がける | 率直に、でも感情的にならずに |
コードレビューは、ただコードの間違いを指摘する場ではありません。
チームで一緒に良いプロダクトを作るための対話の場 です。
明日のレビューから、ひとつでも意識してみてください。
きっとチームの雰囲気が少しずつ変わっていくはずです。
本書にはこの記事で紹介しきれなかった内容もたくさん載っていますので、気になった方はぜひ手に取ってみてください！
『伝わるコードレビュー 開発チームの生産性を高める「上手な伝え方」の教科書』
株式会社シンシア
株式会社シンシアでは、実務未経験のエンジニアの方や学生エンジニアインターンを採用し一緒に働いています。
※ シンシアにおける働き方の様子はこちら
弊社には年間100人以上の実務未経験の方に応募いただき、技術面接を実施しております。
この記事が少しでも学びになったという方は、ぜひ wantedly のストーリーもご覧いただけるととても嬉しいです！