はじめに：コードレビューは「人」を見るものではない

「コードレビューで指摘されるのが怖い…」 「先輩のコードにレビューコメント書いたら、空気が悪くなった…」

こういう経験、ありませんか？

僕は新人エンジニアの頃、先輩のプルリクに「ここ、バグってませんか？」とコメントしたら、翌日から口を利いてもらえなくなった経験があります（本当に）。

結論から言うと、コードレビューで人間関係が壊れるのは、「技術力の差」ではなく「伝え方」の問題です。

この記事では、僕がフリーランスエンジニアとして様々な現場で学んだ、炎上しないコードレビューの実践ルールを7つ、具体例付きで解説します。

---

コードレビューの目的を再確認する

まず大前提として、コードレビューの目的は以下の3つです:

1. バグの早期発見 テストでは拾えない論理エラー・エッジケースを見つける

2. コード品質の向上 可読性・保守性・パフォーマンスを改善する

3. 知識の共有 チーム全体の技術力を底上げする

「粗探し」「マウント取り」「減点方式の評価」ではないということを、まず理解しておいてください。

---

ルール1: 指摘は「コード」にして、「人」にしない

❌ ダメな例

「こんな書き方する人いるんですね。ありえないです。」

✅ 良い例

「このコードだと、ネストが深くなって可読性が下がるかもしれません。
早期リターンを使うと、こうなりますがいかがでしょうか？

// 修正案
if (!user) return null;

ポイント: 「あなた」ではなく「このコード」を主語にする。感情的な言葉（「ありえない」「ひどい」）は絶対に使わない。

---

ルール2: 「提案」であって「命令」ではない

❌ ダメな例

「ここ、useCallbackで囲んでください。」

✅ 良い例

「この関数が毎回再生成されて、子コンポーネントが不要に再レンダリングされてる可能性があります。
useCallbackで囲むと、パフォーマンスが改善するかもしれません。試してみてもらえますか？」

ポイント: 「〜してください」ではなく「〜してみてもらえますか？」。相手に選択肢があることを示す。

---

ルール3: 理由を必ず添える

❌ ダメな例

「constよりletの方がいいです。」

✅ 良い例

「この変数は後で再代入されているので、constだとエラーになります。
letに変更するか、再代入をなくすリファクタリングが必要です。」

ポイント: 「なぜそうすべきか」を書く。理由がない指摘は、単なる好みの押し付けになる。

---

ルール4: ポジティブなコメントも入れる

❌ ダメな例

（指摘だけして、承認ボタンを押す）

✅ 良い例

「エラーハンドリングがしっかりしていて、安心して読めました！
1点だけ、型定義の部分で気になる箇所があったのでコメントします。」

ポイント: 指摘だけだと「ダメ出しされた感」が強い。良い部分も必ず言語化する。

僕がレビューする時は、必ず1つは褒めポイントを探すようにしています。「この命名わかりやすいですね」「テストケースが網羅的で助かります」など、小さなことでOK。

---

ルール5: 優先度を明示する

❌ ダメな例

「このコメント、日本語になってないですね。」

✅ 良い例

【Nit（些細な指摘）】
「このコメント、typoがあります。次のコミットでついでに直してもらえると嬉しいです（マージブロックではないです）」

ポイント: 以下のようなラベルを使うと、受け手の負担が減る:

• [Critical]: これがないとマージできない
• [Suggestion]: 改善提案（任意）
• [Nit]: 些細な指摘（無視してもOK）

---

ルール6: レビューを受ける側も「感情」と「技術」を分離する

新人エンジニアが陥りがちなのが、「指摘された = 自分が否定された」と感じてしまうこと。

僕も最初の頃、レビューコメントが3件以上つくと、「自分はダメなエンジニアだ…」と落ち込んでいました。

でも、フリーランスになって複数の現場を経験してわかったのは、**「コードレビューが多い現場 = 成長できる現場」**ということ。

指摘ゼロのプルリクは、「完璧」ではなく「誰も真面目に見てない」可能性が高いです。

レビューを受ける時の心構え

• 指摘は「成長のチャンス」と捉える
• わからない指摘があったら、素直に質問する
• 「なるほど、勉強になりました！」と返信するだけで、空気が良くなる

---

ルール7: 「対面」でやるべきことと「テキスト」でやるべきことを分ける

テキストで伝えるべきこと

• 具体的なコード修正案
• ドキュメントへのリンク
• テストケースの指摘

対面（Slack通話・Zoom）でやるべきこと

• 設計レベルの大きな指摘
• 「このアプローチ自体どうか？」という議論
• 感情的になりそうな内容

僕の経験上、コメントが3往復以上続いたら、通話に切り替えるのがベストプラクティスです。

テキストだと5往復かかる議論が、通話なら5分で終わることが多いです。

---

【実例】炎上したレビューコメントと改善案

実例1: 炎上パターン

元のコメント（炎上）:

「この実装、何考えてるんですか？ググればすぐ出てくる基本ですよ。」

改善案:

「この実装だと、○○のケースでエラーになる可能性があります。
公式ドキュメントのこの部分（リンク）に推奨パターンが載ってるので、参考にしてみてください。

実例2: 曖昧すぎて伝わらないパターン

元のコメント（曖昧）:

「もうちょっと綺麗に書けそうです。」

改善案:

「この部分、早期リターンを使うとネストが1段減って読みやすくなりそうです。

// Before
if (user) {
  if (user.isActive) {
    // ...
  }
}

// After
if (!user || !user.isActive) return;
// ...

---

現場で使えるコードレビューチェックリスト

## コードレビューチェックリスト

### 機能面
- [ ] 要件を満たしているか
- [ ] エッジケースが考慮されているか
- [ ] エラーハンドリングが適切か

### コード品質
- [ ] 命名がわかりやすいか
- [ ] 関数が1つの責任に集中しているか
- [ ] 不要なコメント・console.logが残っていないか

### パフォーマンス
- [ ] 不要な再レンダリングが発生していないか
- [ ] N+1クエリが発生していないか

### テスト
- [ ] 必要なテストケースが書かれているか
- [ ] テストが通っているか

### セキュリティ
- [ ] 機密情報がハードコードされていないか
- [ ] XSS・SQLインジェクション対策がされているか

このチェックリストは、「GitHub Copilotの使い方」でも触れている内容と連動しています。

---

まとめ

【コードレビューで嫌われない7つのルール】

1. 指摘は「コード」にして、「人」にしない
2. 「提案」であって「命令」ではない
3. 理由を必ず添える
4. ポジティブなコメントも入れる
5. 優先度を明示する
6. レビューを受ける側も「感情」と「技術」を分離する
7. 対面とテキストを使い分ける

コードレビューは、チームの技術力を上げる最強のツールです。

でも、使い方を間違えると、チームを壊す凶器にもなります。

僕がフリーランスとして複数の現場を経験して気づいたのは、「技術力が高い現場」と「コードレビューの質が高い現場」はほぼ一致するということ。

逆に、炎上しまくってるプロジェクトは、大体コードレビューが機能していません。

この記事で紹介したルールを実践すれば、あなたのチームのコードレビュー文化は確実に改善します。

明日のプルリクから、ぜひ試してみてください。

関連記事:

• ポートフォリオ作成ガイド
• 独学での就活苦労話
• AIペアプログラミング入門