はじめに

コードレビュー、やってますか？

どの現場でも日常的に行われている開発プロセスのひとつですが、
「レビューで何を見ればいいのか分からない」
「細かいことばかり指摘されてつらい」
「LGTMだけで終わらせてしまう」
──そんな悩み、あるあるですよね。

本記事では、エンジニアなら一度はやってしまう“NGレビュー”を13パターン紹介しながら、
それぞれにどう改善すればよいか、実際のPRを例にBefore / After形式で学べる構成にしています。

👥 対象読者
• コードレビューに慣れていない若手・中堅エンジニア
• 「レビューがつらい」「空気が悪くなるのが不安」という方
• チーム全体でレビュー品質を高めたいと思っている方

「コードを良くする」のはもちろん、チームの雰囲気も良くなるレビューを、一緒に考えていきましょう！

PRとレビューの前提

本記事では、「ありがちだけどちょっともったいないレビュー」をNGパターンとして紹介します。

そしてそれに対して、実際にありそうなPR（プルリクエスト）を題材に、コメントのBefore / Afterを並べて比較することで、
「なにが悪くて、どう改善できるか」を視覚的に理解できるように構成しています。

レビュー例には以下のような前提があります：
• フロントエンド or バックエンドのWeb系プロジェクト（特定技術に依存しない内容）
• 社内のチーム開発で、GitHubベースのレビュー文化
• 仕様や設計の方針はある程度共有されている状態

コメントでは「NG」と「OK」を明確に分けて表示しているので、
「良い例だけ拾いたい！」という方もサクッと読み進められるはずです。

次の章から、「つい、やりがち…」なNGレビューとその改善例をどんどん見ていきます！

1. 全体を見ずに「ここだけ」指摘してしまう

全体をざっと確認せず、変更箇所の一部だけに注目してしまうレビューはありがちです。その結果、背景や目的が見えず、修正が狭く浅くなってしまいがち。以下のようなNGコメントには要注意です。

// reviewer:
ここのメソッドだけ直して

このレビューパターンは、PRの本質—「この変更はどういう目的で、どこにどう効いているか」を見失いがちです。文脈を無視するとミスの見逃しにつながることも多くなってしまいます。

では、どうすれば良いのでしょうか？

// reviewer:
PR全体を読んだところ、主な変更は○○のためのロジック追加で、その前提に沿うとこのメソッドのこの部分が影響ありそうです。
この処理はこういう目的でしょうか？  
→ 目的に沿った改善を一緒に考えられるコメント例

✅ 章まとめ

• まずは全体を読むことがレビューの第一歩。変更の背景や目的を踏まえることで、指摘の質と意義が格段に向上します。
• 「ここだけ」指摘だと迷いやミスにつながるので、→「なぜ影響があるか」を一文で示すことを意識しましょう。

2. 背景が分からず「仕様を知らずに批判」

レビュー中に「このコード、なんか変じゃない？」と感じたこと、ありますよね。
でもその“違和感”、もしかしたら実は仕様通りだったり、他の制約のもとで妥当だったというケースも少なくありません。

つまり、背景や目的を知らずに突っ込むと、的外れなレビューになってしまうことがあるんです。

// reviewer:
なんでこんなロジックにしたんですか？

コードの背景には、プロダクト仕様、過去のバグ、外部サービスの制約、ユーザー要望など、さまざまな理由があるものです。
そのため、まずは「なぜこう書いたのか？」を確認する姿勢がとても大事です。

// reviewer:
これは○○の仕様に関連した処理でしょうか？目的が知りたいです。
過去PR（#123）にも似た処理があったので気になりました。

✅ 章まとめ

• コードの背後には、仕様や制約、意図が隠れていることを忘れずに。
• 「なんでこう書いたの？」ではなく、「こういう理由ですか？」と仮説ベースで聞くのがコツです。

3. エラーや境界値を無視して「見た目だけOK」

レビューをしていて、「まあ一通り動いてそうだし、OKでいいかな」と判断してしまうこと、ありませんか？
でもその“動いてそう”って、本当に全部のパターンで動く保証はあるんでしょうか？

// reviewer:
ざっと見た感じ問題なさそうですね！LGTMです！

特に、ユーザーの入力や外部APIレスポンスなど想定外の値や境界値（空文字、null、最大長など）に対するテストは見落とされがちです。

// reviewer:
全体的に良いと思いました！
ただ、X=0や空文字のケースは考慮されていますか？
意図的ならコメント補足があると助かります。必要ならテスト追加も検討お願いします。

✅ 章まとめ

• 動作が“なんとなく大丈夫そう”でも、境界値・異常系のチェックは必須。
• 「このパターン、試してみましたか？」という一言で、事故はグッと減ります。
• 特にnull・空文字・0・上限超え・例外パスあたりは常に目を光らせたいところです。

4. 速度や負荷を考えず「ただ速くレビュー」

忙しいときほど、ついレビューも「サッと見て終わらせたい」という気持ちになってしまいますよね。
でもその“サッと見”で、処理の重さやパフォーマンスの落とし穴を見逃してしまうと、あとで本番環境で大きな問題になりかねません。

// reviewer:
ぱっと見、大丈夫そうですね！このままで良さそうです。

実際、パフォーマンスの課題はコードが正しく動くことだけでは発見できない領域です。
たとえばループ内で毎回検索していたり、同じ計算を何度も繰り返していたり、何気ない処理が全体の処理時間に影響を及ぼすことも。

// reviewer:
ロジックは理解しました！
ただ、この部分はデータ量が多くなると O(n²) になりそうです。
Setを使うか、事前にキャッシュして処理できないか一度検討してみてください。

✅ 章まとめ

• “動けばOK”から“速くて安定して動く”へ意識を切り替えるのが重要。
• 少しの処理改善が、将来的なボトルネックの回避やユーザー体験の向上につながる。
• O(n²)、DBアクセスの回数、キャッシュの有無など、レビューでも最低限のパフォーマンス観点は押さえておこう！

5. 例外処理を後回しにして「エラー面をスルー」

「とりあえず動いてるし、エラーにはならなそう」
──そんな理由で例外処理を後回しにしたこと、ありませんか？

でも本番で落ちるのは、たいてい「ならなそうなエラー」なんです。

// reviewer:
まあこのケースで失敗はしなさそうですよね。とりあえずOKです。

特に、レビュー対象が外部APIの呼び出しやファイル処理、DBアクセスなどを含む場合は要注意。
「エラーが起きる前提で設計されているか？」をチェックする姿勢が大切です。

// reviewer:
このAPI呼び出しが失敗した場合のハンドリングはどうなっていますか？
try-catch で包んでログ出力 or フォールバック処理があると安心です！

✅ 章まとめ

• エラーは“起きるもの”として見るのがレビューの基本姿勢。
• 「try-catchされてる？」「失敗しても壊れない？」を最低限チェック。
• 特に外部通信・I/O・非同期処理はエラーハンドリングの抜けがちポイント！

6. 名前がわかりにくくて「これ名前変じゃない？」

コードレビュー中に「うーん、この名前ちょっと分かりにくいな…」と思った経験、ありますよね。
でもそこで終わってしまうと、レビュイーからすれば「何がダメなの？」と戸惑ってしまうだけ。

// reviewer:
これ名前変じゃない？

名前はコードの読みやすさに直結する重要な要素。だからこそ、「何が分かりにくいか」「どう変えると良くなるか」まで伝えることが効果的です。

// reviewer:
この `a` って変数、値としてはユーザーIDのリストみたいですね。
`userIdsList` のように役割が分かる名前だと読みやすくなりそうです！

✅ 章まとめ

• 命名は「なんとなく変」ではなく、“何がどう読みづらいか”を伝えるのが大事。
• ベターな案が浮かばなくても「○○っぽく見えました」と伝えるだけで十分。
• レビューは“あら探し”ではなく“言葉の選び直し”という視点が◎。

7. スタイルばかりに気を取られる「余計な揚げ足」

コードレビューでつい目についてしまう「スペース1個のズレ」や「全角スペースの混入」…
確かに気になりますが、そこばかりに集中してしまうと、本当に見るべき中身が見えなくなることも。

// reviewer:
インデントずれてます。  
ここ、全角スペース入ってますよ。
この空行いらないかも。

もちろん、読みやすいコードは大事です。でもそれなら、機械に任せられるところは任せて、もっと価値のあるレビューに時間を使うべきです。

// reviewer:
スタイルはESLintに任せて、CIで自動チェックできると良いですね。
その分レビューではロジックや設計に集中できるので、導入もおすすめです！

✅ 章まとめ

• スタイル指摘は悪ではないが、レビューの本筋ではない。
• 自動化ツール（ESLint, Prettier など）で人力の負担を減らす工夫をしよう。
• 「どこに集中すべきか」をチームで明確にすることがレビュー文化を整える第一歩。

8. 設計視点を忘れて「構造がおかしい」で終わり

レビュー中に「うーん、このコード、なんか読みにくいな…」「関数長すぎない？」と感じること、よくありますよね。
でも、その感覚を「なんか長いね」だけで終わらせてしまうと、レビューとしては非常に惜しいんです。

// reviewer:
この関数、なんか長くない？
構造ちょっとおかしい気がする。

設計や構造に関するレビューは、レビュアーの視座の高さが問われるポイントでもあります。
だからこそ、たとえ完璧でなくても「こうすれば良くなるのでは？」という仮説を添えることが大切です。

// reviewer:
この関数、3つの処理が1つにまとまっていて少し複雑ですね。
Strategyパターンで処理ごとに分けると、テストや保守がしやすくなるかもしれません。

✅ 章まとめ

• 「構造が微妙」と感じたら、“なぜそう感じたか”を言語化することが大事。
• 設計改善のアイデア（関数分割、責任の分離、デザインパターンなど）を提案ベースで伝えると、レビューが建設的になる。
• 完璧じゃなくても「仮説」として出すだけで、チームの設計力が底上げされるレビューになる！

9. 重複コードをスルーして「前も似たコードあった気が…」

「この処理、どこかで見たような…」
そう思っても、忙しかったり面倒だったりして、ついスルーしてしまうこと、ありませんか？

でもその“なんとなく放置”、あとで保守地獄の第一歩になることもあるんです。

// reviewer:
（あれ？この処理、前も見たような…まいっか）

コードの共通化は、可読性・テスト性・保守性すべてにおいてプラスです。
たとえ確信がなくても、「似た処理、他でも見た気がします」とふんわり投げかけるだけでも意味があります。

// reviewer:
このロジック、以前の `userService.ts` にも似たような処理があった気がします。
共通化すれば再利用しやすくなりそうです！

✅ 章まとめ

• 「前もあったような…」で終わらず、再利用のきっかけを作るのが良いレビュー。
• 共通化は後回しにされがちだからこそ、レビューのタイミングが一番言いやすい。
• 確信がなくても「似てる気がする」レベルでOK。ふんわり指摘でも価値あり！

10. テスト・ドキュメントを見落として「動いてる＝OK」

「コードもきれいだし、動いてるっぽいからマージで！」
──ちょっと待ってください、それ本当に安心して使える状態ですか？

// reviewer:
とくにエラーも出ないし、マージして良さそうです！

レビューは「動くかどうか」だけでなく、「他の人が安心して使えるかどうか」を見る場でもあります。
だからこそ、READMEやJSDoc、単体テストの有無はしっかり確認したいポイントです。

// reviewer:
処理内容は良さそうですね！
この関数を他のメンバーが使う可能性もあるので、READMEに使用例を追記してもらえると助かります。
合わせて、unitテストも追加できそうでしょうか？

✅ 章まとめ

• 「動いている」だけではレビュー完了ではない！
• 他の人が使えるように、使い方説明（READMEやJSDoc）とテストがあるかチェック。
• レビューはコードの“未来の利用者”への気配りでもある。

11. 修正提案だけで「なぜ直すの？」が抜けている

GitHubやGitLabのレビュー機能で便利な「suggested change」。
とても使いやすい反面、“意図を伝えないまま変更だけを投げる”というレビューになってしまいがちです。

return result.filter(x => x.active);
// reviewer:
（※コメントなし）

修正提案は、“コードを良くする手段”ですが、伝え方を間違えると単なる“押しつけ”に見えてしまいます。
そこで重要なのが、「なぜそう直すのか」という背景や目的の補足です。

return result.filter(x => x.active);
// reviewer:
※activeがfalseの要素は不要だと思うので、filterで除外する形にしてみました。
この方が条件が明確になり、読みやすいかと思います！

✅ 章まとめ

• 「前もあったような…」で終わらず、再利用のきっかけを作るのが良いレビュー。
• 共通化は後回しにされがちだからこそ、レビューのタイミングが一番言いやすい。
• 確信がなくても「似てる気がする」レベルでOK。ふんわり指摘でも価値あり！

12. レビューを先延ばしにして「放置レビュー」

「ちょっと今立て込んでるから、あとで見よう…」
──その“あとで”、本当に来てますか？

忙しいときほどレビュー対応が後回しになりがちですが、
レビューが止まると、開発の流れも止まってしまいます。

// reviewer:
（3日前にレビュー依頼されてたけど…まだ見てない…）

もちろん、人間だから忙しいときもあります。
でもそんなときは、“すぐ見れないことを伝える”だけでも全然違うんです。

// reviewer:
ごめんなさい、今詰まっていて今日中の確認になります🙏  
明日までにはコメント出します！

✅ 章まとめ

• 放置されたレビューは、技術的にも心理的にも負債になる。
• 忙しくて見れないときは、状況を一言共有するだけでもOK！
• 「期限感」と「ひとこと連絡」が、レビューの信頼感を支えるポイントです。

13. LGTMで終わらせて「コメントしない放置」

「特に問題なさそうだし…LGTM（Looks Good To Me）で！」

──その一言、便利だけど、もったいないかもしれません。

// reviewer:
LGTM 👍

一方で、「ここが良かったです」と一言添えるだけで、
レビュイーの安心感やスキルアップにつながる“前向きなフィードバック”に変わります。

// reviewer:
LGTMです！特にエラーハンドリングと命名が丁寧で読みやすかったです！

✅ 章まとめ

• LGTMだけでは“見たフリ”に見えてしまうことも。
• OKなら「どこが良かったのか」「どこを確認したか」をポジティブに伝えると◎。
• レビューはチェックだけでなく、“承認のコミュニケーション”でもある。

NGパターンまとめと対応策

ここまで紹介してきた「レビューでありがちなNG例」、
思い当たるものが1つや2つはあったのではないでしょうか？

ここでは、それぞれのNGパターンに対して、
どのような「声かけ」や「コメントの型」にすると建設的なレビューになるのかをテンプレ形式で整理します。

NG → OKテンプレート集

💡 ワンポイント

•	どんなNGも、「提案」と「共感」を添えることで“対話”に変わる
•	レビューは“文句を言う場”ではなく、“チームの知見を共有する場”
•	テンプレに頼るのは最初だけでOK。使ううちに自分のレビュー言語が育つ

良いレビューを書く心得13か条

ここまでNGパターンとその改善策を見てきましたが、実際の現場では「じゃあ結局どう意識すればいいの？」という声が聞こえてきそうです。

そこで、良いコードレビューのマインドセットを「心得13か条」としてまとめました。
NG例と対になる形で、レビューの本質を端的に押さえています。

✅ 良いレビューの心得
1. まず全体を見る。細部に行くのはそのあと。
2. コードの背景や文脈を確認してからコメントする。
3. テストの有無・観点を常に意識する。
4. パフォーマンスへの影響も視野に入れる。
5. 例外系やエラーハンドリングを後回しにしない。
6. 命名は“未来の自分”が見て分かるように。
7. スタイル指摘は自動化できる環境を整える。
8. 構造・設計についても踏み込む勇気を持つ。
9. 似たコードがないか、過去の実装を思い出す。
10. 使い方とテストの“伝わる状態”をゴールとする。
11. 提案には「なぜ」を添えて納得感を生む。
12. レビューを放置せず、ひとことリアクションを。
13. OKコメントにも「どこが良かったか」を伝える。

すべてを完璧にやる必要はありませんが、どれか1つを意識するだけでもレビューの印象はガラッと変わります。

「コードを良くする」ことはもちろん、人と人のコミュニケーションとしてのレビューを大切にしましょう。

仕組みでレビュー品質をアップ

良いレビューの意識があっても、チームやプロジェクト全体で習慣化するのは難しいものです。
だからこそ、「仕組み」でレビュー品質を底上げするのが効果的です。

ここでは、すぐ導入できる3つの工夫をご紹介します。

📝 1. PRテンプレートで「書くことを明確に」

PRに以下のようなテンプレートを用意しておくと、レビュアーが背景を把握しやすくなります。

• 変更内容の概要
  なにをどう変えたのかを簡潔に

• 背景・目的
  なぜこの変更が必要だったのか

• レビューポイント
  特に見てほしい部分（性能・設計・仕様など）

• 補足
  動作確認内容やテスト状況など

こうした情報が整理されているだけで、「見逃し」や「的外れな指摘」も減ります。

✅ 2. レビュー用チェックリストを用意する

レビュー時に確認すべきポイントを簡単なチェックリストにしておくと、誰でも一定品質のレビューができます。

例：

• ロジックの意図が分かるか？
• エラーハンドリングは十分か？
• 命名は適切か？
• テストケースは十分か？
• 処理の重複や再利用できそうな部分はないか？

これはレビュー初心者のフォローにもなるので、ナレッジ共有としても効果的です。

⚙️ 3. 自動化ツールで指摘コストを減らす

• スタイルチェック： ESLint, Prettier
• テスト自動実行： GitHub Actions, CircleCI
• suggested change： GitHubのインライン提案機能

これらをCIに組み込むことで、「人間が見なくてもいい部分」は機械に任せられます。

結果として、レビューの“本質”に集中できる時間が増え、議論の質が高まります。

レビューの品質は、個人のスキル×チームの文化×仕組みのサポートで決まります。

「仕組み」としてのPRテンプレやチェックリスト、自動化の導入を進めることで、
属人化せず、誰でも“良いレビューができる状態”を目指しましょう！

まとめ

ここまで、コードレビューでありがちなNGパターン13選とその改善方法、
さらに、良いレビューのためのマインドセットと仕組み作りのコツを紹介してきました。

レビューは「正しいかどうか」だけを判断するものではありません。
それ以上に、チームの認識をそろえたり、知識を共有したり、開発文化を育てたりするための大事なコミュニケーションの場です。

✅ 今すぐできるアクションリスト

• PRを出す前に、「背景・目的・レビューポイント」を明記しよう
• コメントするときは、「なぜ」を添えて伝えるクセをつけよう
• LGTMだけで済ませず、良かった点を1つでも挙げてみよう
• チームでレビューのチェックリストを作ってみよう
• ESLintやCIなど、自動化できることは機械に任せよう

📣 最後に

「コードレビューがつらい」「緊張する」「何を言えばいいか分からない」
そんな経験は誰にでもあります。でもそれは、ちゃんと向き合っている証拠です。

本記事が、レビューのモヤモヤやストレスを少しでも減らし、
「レビューって、ちょっと楽しいかも」と思えるきっかけになれば幸いです。

あなたのレビューが、チームの開発をもっと良くしていくことを願っています！