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

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

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

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

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

この記事では、僕がフリーランスエンジニアとして様々な現場で学んだ、炎上しないコードレビューの実践ルールを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の使い方」でも触れている内容と連動しています。

チェックリストの「テスト」項目は特に見落とされがちです。フロントエンドテスト入門（Jest・Vitest）を参考に、テストの書き方を覚えておくと、レビュー時の指摘がずっと少なくなります。

また、TypeScriptの型エラーはコードレビューで指摘されやすい定番ネタです。TypeScript入門で型定義の基礎を固めておくと、「型がanyになってる」という指摘を受けることがなくなります。

---

まとめ

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

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

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

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

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

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

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

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

コードレビューの文化が整ったら、次はポートフォリオや転職活動の準備です。エンジニア転職の面接対策も合わせて読んでみてください。

関連記事:

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

---

よくある質問

Q: コードレビューをもらったときに、全部の指摘に対応しないといけないですか？

A: 全部に対応する必要はありません。[Suggestion]や[Nit]のラベルがついた指摘は任意です。ただ、理由を添えて「今回はこの指摘は見送ります」と返信するのがマナーです。無視するより誠実に対応する姿勢が、チームの信頼につながります。

Q: 先輩のコードに指摘するのが怖いです。どうすれば？

A: 「指摘」ではなく「確認」のスタンスで書くと心理的ハードルが下がります。「この実装だと○○のケースでエラーになる気がするんですが、何か意図があれば教えてください」という形にすると、先輩も防衛的にならずに答えやすくなります。

Q: レビューで指摘が多すぎて萎えます。どうすればいいですか？

A: 指摘が多い = 真剣に見てもらえている証拠です。ただ、量が多すぎる場合はプルリクのサイズを小さくすることを検討してください。一度に大量のコードを出すとレビュワーの負担も増え、指摘の質も落ちます。500行以内を目安にするのがおすすめです。

Q: リモートワークだとコードレビューの文化が作りにくいです

A: テキストコミュニケーションを丁寧にすること、定期的なコードレビュー会（週1回30分でも）を設けることが効果的です。また、ルール7で述べたように「3往復以上したら通話」のルールを明文化しておくだけで、リモートでの炎上は大幅に減ります。

---

【2026年4月追記】AIコーディングツールが普及してから、コードレビューの様相が少し変わってきました。「AIが書いたコード」のレビューには、また別のポイントがあります。近々まとめる予定です。

---

あわせて読みたい

• Git・GitHub入門：バージョン管理の基本をコードで理解する（2026年版）
• TypeScript入門：型定義の基礎からレビューで困らない書き方まで
• フロントエンドテスト入門｜Jest・Vitestの使い方（2026年版）