Oct 7, 2026

不安解消

エンジニア1年目、コードレビューの指摘がつらい時の受け止め方

※本サイトの記事にはアフィリエイト広告（PR）を含む場合があります

※本記事にはアフィリエイト広告（PR）を含みます。

未経験でエンジニアとして入社し、初めて出したコードに20件近いコメントが付いた。直して出し直すと、また別の指摘が来る。「自分はエンジニアに向いていないのでは」と落ち込んでいる人に向けた記事です。

先に結論を書きます。1年目にレビューの指摘が多いのは普通で、指摘の多くはあなたではなくコードに向けた意見です。 指摘を「必ず直すもの」と「好みの範囲」に分け、同じ指摘を2回受けない仕組みを作ると、数か月で件数は減っていきます。ただし、人格を否定する言葉が続くなら、それはレビューではなく相談すべき問題です。

指摘が多いのは1年目では普通のこと

コードレビューは、バグを防ぐことと、チームの書き方をそろえることが主な目的です。新人の教育も目的に含める会社があります。入社したばかりの人は、そのチームの命名ルールや書き方の癖をまだ知りません。指摘が多くなるのは、能力より「チームのルールを知らない」ことが原因の場合がほとんどです。

Googleが公開しているコードレビューのガイドでは、レビューする側に向けて「コメントはコードについて書き、書いた人については書かない」ことを求めています。多くのチームでも、レビューの指摘は「このコードをこう直したい」という意見です。「あなたはダメだ」という評価ではありません。

経験者でも指摘はゼロにならない

レビューの指摘は、経験を積んでもなくなりません。設計の好みや読みやすさの判断は人によって違うため、ベテラン同士でもコメントのやり取りは起きます。件数をゼロにすることを目標にすると、ずっと苦しくなります。目標は「同じ指摘を繰り返さない」ことに置いてください。

指摘は3種類に分けて受け止める

指摘を全部同じ重さで受け取ると、量に押しつぶされます。届いたコメントは、まず次の3つに分けてください。

必ず直すもの：バグ、動かない処理、セキュリティの問題、チームのルール違反
直すと良くなるもの：読みやすさ、変数名、処理の分け方など
好みや参考情報：「自分ならこう書く」「こういう方法もある」という提案

Googleのガイドでは、細かい指摘に「Nit（細かい点）」、必須でない提案に「Optional」といった印を付けることを勧めています。あなたのチームのレビューに印が付いていないなら、「このコメントは必須ですか、参考ですか」と聞いて構いません。聞くこと自体は失礼ではなく、優先順位を決めるための確認です。

コードレビュー｜指摘の仕分け方

届いた指摘を3つに分ける

全部を同じ重さで受け止めなくてよい

	今回直すか	メモに残すか	質問してよいか
必ず直すものバグ・ルール違反など	○ 直す	○ 必ず残す	○ 理由を聞いてよい
直すと良くなるもの読みやすさ・名前	○ 基本は直す	○ 繰り返すなら残す	○ 聞いてよい
好み・参考情報「自分ならこう書く」	△ チームの方針次第	△ 気になれば残す	○ 必須か確認してよい

※どれに当たるか迷ったら、レビューした人に「必須か参考か」を確認してください

IT転職ナビ

同じ指摘を2回受けないメモの取り方

指摘の件数を減らす一番の近道は、受けた指摘を自分用のチェックリストにすることです。手順は次の3つです。

指摘を一行で書き写す：「関数名は動詞から始める」「マジックナンバーは定数にする」など、次にも使える形にまとめます。
なぜそう直すのかを書き添える：理由が分からない指摘は、その場で質問して理由ごと残します。理由が分かると、似た場面でも応用できます。
提出前にリストを見直す：コードを出す前に、リストの項目を上から確認します。

リストは2〜3か月で30項目ほどになるはずです。1項目ずつ身につくたびに、同じ指摘は来なくなります。リストが長くなること自体が、成長の記録になります。

指摘の理由を聞くときの聞き方

理由が分からないまま直すと、次も同じところでつまずきます。聞くときは「直し方」ではなく「理由」を聞いてください。

「〇〇に直しました。こう書く理由を知りたいので、参考になる資料があれば教えてください」
「今回の指摘は、チームのルールでしょうか。それとも一般的な書き方でしょうか」

チームのルールなら、コーディング規約などの文書があるか確認します。文書があれば、レビュー前に自分で読んでおけます。

提出前の工夫で指摘を減らす

レビューに出す前の準備でも、指摘の数は減らせます。新人のうちに効果が出やすいのは次の4つです。

変更を小さく分けて出す：Googleのガイドでは、変更は100行程度が目安で、1,000行は大きすぎることが多いとしています。小さい変更は早く丁寧に見てもらえます。
自分で差分を読み直す：消し忘れたデバッグ用の出力、タイポ、不要なコメントは、提出前に差分を読めば自分で気づけます。
何をなぜ変えたかを説明に書く：レビューする人が意図を読み違えると、不要な指摘が増えます。
自動チェックの道具を使う：チームで使っている書式チェックや静的解析の道具があれば、提出前に通します。

大きく作り込む前に方向を確認する

新人がつらくなりやすいのは、何日もかけて作ったコードの方向が根本から違うと言われたときです。作り始める前か、半分ほどできた段階で「この方針で進めていいか」を先輩に確認してください。早めに確認するほど、やり直しの量が減ります。

人格否定に近い指摘は相談してよい

レビューは指導の場ですが、何を言ってもよい場ではありません。厚生労働省のハラスメント対策サイトでは、業務上必要かつ相当な範囲の指導はパワハラに当たらないとしています。一方で、人格を否定する言葉やひどい暴言は「精神的な攻撃」の例として挙げられています。

次のような状態が続くなら、コードへの意見ではなく人への攻撃に近いと考えてください。

「こんなこともできないのか」「向いていない」など、コードではなく本人を責める言葉が続く
他のメンバーが見ている場で、繰り返し大声で責められる
質問すると「自分で考えろ」とだけ言われ、理由も資料も示されない状態が続く

こうした状態が続くときは、日付と内容をメモに残してください。レビューのコメントが文字で残っているなら、それ自体が記録になります。相談先は、直属の上司以外のリーダー、人事、社内の相談窓口です。社内で話しにくいなら、各都道府県の労働局などにある「総合労働相談コーナー」が無料で相談を受け付けています。

転職を考えるのはどんなときか

指摘が多くてつらいという理由だけで、すぐに辞める必要はありません。指摘を減らす工夫をして3か月ほど様子を見ると、件数の変化が分かります。

一方で、次のような状態なら、職場を変えることを考え始めてよい時期です。

人格を否定する言葉が続き、社内に相談しても変わらない
質問しても答えてもらえず、学ぶ手段がない状態が続いている
心や体の不調が出ている

なお、指摘の内容が理解できない状態が長く続き、プログラミングそのものがつらいと感じる場合は、職種の向き不向きを見直す時期です。コードを書く量が少ない職種もあります。どの方向が合うか迷ったら、IT/Web転職タイプ診断（無料）で整理してみてください。

第二新卒として次の会社を探したい人は、第二新卒向けの就職・転職エージェントに相談する方法があります。UZUZ第二新卒は、第二新卒向けの就職・転職支援サービスです。今の会社に残るか移るかを比べる材料として使えます。

よくある質問

1回のレビューで20件指摘されました。多すぎますか

件数だけでは判断できません。細かい書き方の指摘が並ぶと、20件はすぐに超えます。3つに仕分けると、「必ず直すもの」は数件だけということもよくあります。件数より、同じ指摘が次回も来ているかを見てください。

指摘に納得できないとき、反論してもいいですか

理由を添えて意見を返すのは問題ありません。「〇〇の理由でこう書きましたが、△△の方がよい理由を教えてください」と、相手の意図を聞く形にすると話が進みやすくなります。チームのルールで決まっている場合は、ルールに合わせます。

レビューが怖くて、コードを出すのが遅れてしまいます

完成してから出そうとすると、出すまでの時間も、直す量も増えます。途中の段階で「下書きとして見てほしい」と出せるチームなら、早めに見てもらってください。小さく出すほど、1回の指摘は少なくなります。

先輩によって言うことが違います

レビューする人によって好みが分かれることはあります。どちらに合わせるか迷ったら、チームのリーダーに「どちらの書き方に合わせればよいか」を確認し、答えをメモに残してください。

まとめ

1年目にレビューの指摘が多いのは普通で、多くはコードへの意見
指摘は「必ず直す」「直すと良くなる」「好み・参考」に分けて受け止める
指摘を理由つきでメモし、提出前のチェックリストにする
変更を小さく分け、作り込む前に方向を確認すると指摘が減る
人格を否定する言葉が続くなら、記録を残して社内外の窓口に相談する

参考情報

※本記事は一般的な情報提供を目的としたもので、転職・収入を保証するものではありません。個別の労働問題は、労働基準監督署や弁護士などの専門家にご相談ください。