コードレビューが怖くて質問できないとき｜エンジニアの心理的ハードル

レビューで指摘されるのが怖い、分からないことがあっても質問できない。その萎縮は、あなたの能力が足りないからではありません。レビューや質問が怖く感じる理由には、わりとはっきりした正体があります。そこを言葉にすると、聞き方の工夫で楽になる部分と、職場の環境のほうに問題がある部分とを切り分けられます。

プルリクを出すたびに胃が痛い。Slackで質問を打っては消し、結局何時間も一人で詰まる。経験の浅いうちは「指摘が怖い」「何が正解か分からない」とレビューをネガティブに感じる人が少なくない、という指摘もあります(参照)。珍しいことではありません。

なぜレビューや質問が怖いのか

怖さの大半は、「指摘＝自分への否定」と無意識に受け取ってしまうところから来ています。コードに赤が入っただけなのに、自分が責められた気持ちになる。この変換が、萎縮の出どころです。

理由をいくつか分けてみます。まず、正解が一つに見えてしまうこと。経験が浅いと、自分の書いたコードに自信が持てず、指摘されると「やっぱり間違っていた」と全否定されたように感じます。実際には設計の好みやチームの慣習の話も多く、白黒つく話ばかりではありません。

次に、指摘の言い方。同じ内容でも「なんでこう書いたの?」と詰問調で来ると、技術の話なのに人格を問われたように響きます。伝え方ひとつで毎回のプルリクが怖くなる、というのは多くの現場で起きていることです。

そして、質問することへの抵抗。「こんなことも知らないのか」と思われたくない、忙しそうな先輩の時間を奪いたくない。この遠慮が積もると、分からないまま抱え込み、かえって時間を溶かします。怖さは性格の弱さではなく、置かれた状況が生む反応です。

指摘は人格否定ではない、と捉え直す

レビューの指摘は、あなたではなくコードに向けられたものです。ここを分けて受け取れるようになると、同じ指摘でもダメージがまるで変わります。

良いチームでは、コードレビューを「間違い探し」や「テスト」ではなく、コードをより良くするための共同作業として扱います(参照)。指摘した側も、あなたを否定したいわけではなく、プロダクトを良くしたいだけ。そう考えると、指摘はむしろ無料で受けられる添削です。

実務でよく使われている工夫に、コメントへのラベル付けがあります。レビュアーが「[must]」「[imo]」「[nits]」「[質問]」のように、指摘の温度感を頭に付ける方法です。「must」は必ず直すべき点、「imo（in my opinion）」はあくまで意見、「nits」は些細な好み。これがあると、どれが本当に直すべきで、どれが流していい話なのかが一目で分かります。もしチームにこの習慣がなければ、自分が指摘を受け取るときに頭の中で仕分けるだけでも効果があります。

それでも刺さるときは、指摘の「内容」と「言い方」を切り離してみてください。技術的に正しい内容は取り入れ、きつい言い方のほうは「この人の癖」として横に置く。全部をまるごと受け止める必要はありません。

質問の仕方を変えると聞きやすくなる

質問が怖いなら、聞く中身を整えると一気に楽になります。「分かりません」とだけ投げるのが一番ハードルが高く、しかも相手も答えにくい。下調べ・具体化・仮説提示の三段で組み立てるのがおすすめです。

まず下調べ。公式ドキュメントや社内の過去のissue、エラーメッセージでの検索を一通りやってみる。これは「丸投げを避けるため」というより、自分の中で問いがはっきりするための作業です。調べる過程で半分解決することも珍しくありません。

次に具体化。「動きません」ではなく、「○○を呼ぶとここで500が返る。期待しているのは△△」と、現象と期待値をセットで書く。何を試したかも添えると、相手は同じ確認を省けます。

そして仮説提示。「××が原因だと思って□□を試したが変わらなかった。他に見るべき箇所はありますか」と、自分の見立てを一つ置く。これがあると、相手はゼロから調べずに済み、あなたの理解度も伝わります。質問が「教えてもらう」から「一緒に詰める」に変わると、聞くこと自体が怖くなくなっていきます。

PRの説明文でも同じ手が使えます。「この実装は自信がないので重点的に見てほしい」「別案も考えたが○○の理由でこちらにした」と先回りで書いておくと、レビュアーは詰問ではなく相談として受け取りやすくなります。

その職場、心理的安全性はあるか

ここまでの工夫を試しても萎縮が消えないなら、原因はあなたではなく職場の側かもしれません。質問や指摘が怖い空気が常態化しているなら、心理的安全性の問題を疑ってよいということです。

心理的安全性は、ハーバード大学のエイミー・エドモンドソン教授が1999年の論文で示した概念で、「対人関係のリスクをとっても安全だとメンバー間で共有された状態」と定義されます(参照)。質問しても、間違えても、馬鹿にされたり評価を下げられたりしない——そう信じられる状態のことです。これが欠けた職場では、誰もが無難に振る舞い、分からないことを隠すようになります。

見極めの材料はいくつかあります。

• 1on1や定期面談の仕組みがあり、形だけでなく運用されているか
• コードレビューのルールや指摘の仕方（ラベル付けなど）が共有されているか
• 質問用のチャンネルがあり、初歩的な質問にも普通に返ってくるか
• 「知らない」「分からない」を口にするメンバーが実際にいるか

面談で「心理的安全性を大事にしています」と掲げる会社は多いものの、言葉だけのこともあります。「具体的にどう運用していますか」と、仕組みやエピソードで聞くと、見せかけかどうかが透けて見えます。レビューやチームの人間関係に消耗している場合の切り分けは、エンジニアが職場の人間関係に疲れたときにもまとめてあります。

環境を変える選択肢

工夫の余地を使い切っても変わらないなら、転職で環境を変える判断は十分に妥当です。萎縮したまま成長機会を逃し続けるより、安心して質問できる場所に移るほうが、結果的に伸びることもあります。

ただし、求人票の「アットホーム」「風通しの良い社風」といった言葉は実態を保証しません。見るべきは、安心して聞ける仕組みが回っているかどうか。こうした内実は求人サイトを眺めるだけでは分からないので、現場の体制まで踏み込んで聞いてくれるエージェントを挟むと確かめやすくなります。エンジニア向けの選び方はITエンジニアの転職エージェント比較に整理しました。

転職しても新しい職場に同じ空気がないとは限りません。だからこそ、応募の前に「レビュー文化」「質問のしやすさ」を確認する習慣をつけておくと、移ったあとのミスマッチを減らせます。

次の一歩

今すぐ辞める必要はありません。まずは小さく一つ試してみてください。次の質問を「下調べ→具体化→仮説」の形に組み直してみる。あるいは、直近のレビュー指摘を「内容」と「言い方」に分けて読み返してみる。それで負担が減るなら、聞き方の問題だったということです。

工夫しても胃の痛さが変わらないなら、環境のほうを疑う段階です。在職中でも、エージェントとの面談でレビュー文化や質問のしやすさを軸に他社の話を聞いておけば、焦らずに比べられます。

レビューや質問が怖いのは、あなたが弱いからではありません。聞き方で楽になる部分と、環境を変えたほうがいい部分を分けて、できるところから一つずつ動けば十分です。