はじめに：レビューの「言い方」で、チームの寿命が決まる
コードレビューは技術的に正しい指摘をする場です。しかし、指摘の「内容」が正しくても、「言い方」が悪ければチームは壊れます。
「こんな書き方ありえない」──技術的には正しい指摘かもしれませんが、書いた本人は二度とPRを出したくなくなります。
逆に、同じ内容を「こういう書き方もありますが、こちらだとこんなメリットがありますね」と伝えれば、相手は「なるほど！」と前向きに修正できます。
この記事は、レビューでよく使われる「刺さりすぎる表現」を「建設的な表現」に変換する辞典です。チームに共有して、レビュー文化のベースラインにしてください。
変換辞典：30のビフォー・アフター
🔴 全般・コード品質
| # |
❌ 刺さりすぎる表現 |
✅ 建設的な表現 |
| 1 |
「このコード微妙です」 |
「ここ、こう書くとより意図が伝わりやすくなりそうです」 |
| 2 |
「なんでこう書いたんですか？」 |
「この実装にした背景を教えてもらえますか？」 |
| 3 |
「普通こう書かない」 |
「一般的にはこのパターンが多いですが、何か意図がありますか？」 |
| 4 |
「意味が分かりません」 |
「ここの処理の意図を理解したいので、コメントを追加できますか？」 |
| 5 |
「ここ全部書き直してください」 |
「このアプローチだと〇〇の懸念がありそうです。代案として△△はいかがですか？」 |
🟡 命名・可読性
| # |
❌ 刺さりすぎる表現 |
✅ 建設的な表現 |
| 6 |
「変数名がひどい」 |
「d だと何のデータか分かりにくいので、deliveryDate はどうですか？」 |
| 7 |
「読めません」 |
「ここ、処理を関数に切り出すと見通しがよくなりそうです」 |
| 8 |
「マジックナンバーやめて」 |
「86400 に名前をつけると、将来読む人に意図が伝わりやすくなります」 |
| 9 |
「コメントが足りない」 |
「WHY（なぜこうしたか）をコメントに残してもらえると、レビューしやすくなります」 |
| 10 |
「複雑すぎます」 |
「ここの認知負荷が高いので、3つの関数に分割するのはどうでしょう？」 |
🟢 設計・アーキテクチャ
| # |
❌ 刺さりすぎる表現 |
✅ 建設的な表現 |
| 11 |
「設計がおかしい」 |
「こちらの設計だと〇〇のケースで困りそうです。△△パターンを検討しませんか？」 |
| 12 |
「これは筋が悪い」 |
「長期的に見ると、この方向だとメンテコストが上がりそうです」 |
| 13 |
「やり方が違います」 |
「チームでは〇〇パターンを採用しているので、合わせてもらえると嬉しいです」 |
| 14 |
「この責務はここじゃない」 |
「この処理は〇〇層の責務に近いので、移動するとテストしやすくなりそうです」 |
| 15 |
「密結合すぎ」 |
「ここをインターフェースで切ると、将来の変更に強くなりますね」 |
🔵 テスト・エラー処理
| # |
❌ 刺さりすぎる表現 |
✅ 建設的な表現 |
| 16 |
「テスト書いてない」 |
「この変更にテストがあると安心してマージできます」 |
| 17 |
「このテスト意味ない」 |
「このテストが何を保証しているか、テスト名で表現できるともっと良くなりそうです」 |
| 18 |
「エラー処理がない」 |
「ここで例外が起きた場合、ユーザーにはどう見えるか考えてみましょう」 |
| 19 |
「エッジケース考えてない」 |
「null や空配列が来た場合もカバーできると堅牢になります」 |
| 20 |
「このcatch空っぽじゃん」 |
「エラーを握りつぶすと調査が大変になるので、最低限ログに出しませんか？」 |
🟣 パフォーマンス・セキュリティ
| # |
❌ 刺さりすぎる表現 |
✅ 建設的な表現 |
| 21 |
「遅い」 |
「データ量が増えた時にN+1問題になりそうです。事前にJOINするのはどうですか？」 |
| 22 |
「セキュリティ的にアウト」 |
「ここ、ユーザー入力がそのまま使われていて脆弱性になりそうです。一緒に確認しましょう」 |
| 23 |
「SQLインジェクションされるよ」 |
「プレースホルダーを使うと安全になります。〇〇のドキュメントに例がありますね」 |
| 24 |
「これ脆弱」 |
「セキュリティの懸念があるので、リリース前に一度一緒に確認させてください」 |
| 25 |
「本番で死ぬよ」 |
「本番のデータ量だとタイムアウトする可能性があります。インデックスを追加しませんか？」 |
⚪ ポジティブなフィードバック（最も重要）
| # |
場面 |
✅ 使うべき表現 |
| 26 |
良い命名を見つけた時 |
「この変数名、めちゃ分かりやすいです 👍」 |
| 27 |
きれいな設計の時 |
「この責務の切り方、すごく綺麗ですね。参考になります」 |
| 28 |
テストが丁寧な時 |
「エッジケースまでカバーされていて安心してLGTMできます」 |
| 29 |
前回の指摘が反映された時 |
「前回話した〇〇、ちゃんと反映されてますね。ありがとうございます！」 |
| 30 |
全体的に良いPRの時 |
「PR全体の構成が見やすくて、レビューしやすかったです。この調子！」 |
レビューする側の心構え
1. 「指摘」と「提案」と「質問」を使い分ける
多くのレビューツール（GitHub等）では、コメントに接頭辞をつけて意図を明確にできます。
[MUST] これは修正を必須とします。理由は…（指摘）
[WANT] こうするとさらに良くなりそうです（提案・任意）
[ASK] この実装にした理由を教えてください（質問）
[NITS] 本当に細かいことですが…（好み。スルーOK）
[GOOD] ここ良いですね！（称賛）
2. 良い点を最低1つ書く
全てのコメントが指摘だけだと、書いた人は「全否定された」と感じます。最低1つは良い点を見つけて言葉にすることで、指摘が受け入れられやすくなります。
3. 自分のコードだと思って読む
「他人のコード」だと思うと厳しくなりがちです。「1ヶ月後にこのコードの障害対応をするのは自分かもしれない」と思って読むと、建設的な視点になります。
この辞典をチームのレビューガイドラインのベースにしてください。言い方を変えるだけで、PRのコメント欄が「戦場」から「学びの場」に変わります。
