はじめまして。
株式会社PRUMでエンジニアをしている人見です。日々、プログラミング学習や実務の中で、つまずきやすいポイントを整理して発信しています。

PRUMについて気になった方は、コーポレートサイトもご覧ください。
▶ コーポレートサイト

9割の新人エンジニアがやっている「失礼しました」の落とし穴（後編）

はじめに

前回は、「失礼しました」とすぐに謝ってしまう背景や、
そこにある思考停止について整理しました。

指摘されるたびに謝ってしまう。
そして内心では「自分はダメだ」と感じてしまう。

でも実際のレビューって、
「ダメ出し」じゃなくて「良くするための提案」なんですよね。

ただ、それが分かる前に心が折れる。
では、どうすればいいのでしょうか。

「考えろ」は正しい。でも、それだけでは足りない

指摘を受けたとき、
「ちゃんと考えよう」と思っても、

何が問題なのか分からない
前提が見えない

という状態は普通に起きます。
これは能力の問題ではありません。

人って、わからないことが一気に来ると、
とりあえず楽な方に逃げるんですよね。

つまり「とりあえず謝る」は自然な反応です。

ただし問題は、
そこで思考が止まることです。

なぜ考えきれないのか

理由はシンプルです。
現場には暗黙知があるからです。

過去の経緯
チームのルール
言語化されていない前提

これらは仕様書には出てきません。

つまり、
個人の思考だけでは到達できない領域がある。

だから「聞く」は正しい。ただし差が出る

分からないときに聞くことは、逃げではありません。
むしろ最短で理解に辿り着く行動です。

ただし、ここで大きな差が出ます。

NGパターン（よくある）

どうしてこうなんですか？

👉 情報をもらうだけで終わる

OKパターン①（意図確認）

〇〇という意図で実装したのですが、
この部分の認識が違っていそうでしょうか？

👉 自分の考えを出している
👉 相手がズレを指摘しやすい

OKパターン②（理由を聞く）

この実装だと問題になるポイントを、
もう少し教えていただいてもいいですか？

👉 表面的な修正ではなく、理解にフォーカス

OKパターン③（仮説＋確認）

〇〇の観点で考えると、
こちらの方がよさそうだと思ったのですが、
この認識で合っていますか？

👉 判断力がある人の聞き方

この違いはとても大きいです。
自分の考えを出しているかどうか。
ここが、理解の深さを分けます。

仕事ができる人の正体

ここ、めちゃくちゃ誤解されがちなんですが、

仕事ができる人は、
正解を知っている人ではありません。

正解を作るために、
考え続けることをやめない人です。

言われた通りに直すだけなら作業で終わります。

でも、

仮説を出す
比較する
納得して修正する。

このプロセスは「判断」です。

そして、この積み重ねが
そのまま深い理解・実力につながります。

レビュワーも完璧ではない

レビュワーも人間です。

前提のズレ
情報不足
認知バイアス（思い込み）

普通に起きます。

だからこそ
「指摘＝正解」とは限りません。

重要なのは、
受け取ることではなく、すり合わせること。

まとめ

やることはシンプルです。

分からなければ聞く
仮説を持って伝える
認識をすり合わせる

「言われた通りに直す」で終わるか、
「自分の考えを持って判断する」までいくか。
この違いが、そのまま成長の差になります。

また、
レビューは、一緒により良いものを作る場です。
その中で、自分の考えを出せるかどうか
そこが、次のステージに進めるかの分かれ道になります。

PRUMのエンジニアの95%以上は未経験からの採用です。
よければコーポレートサイトにも遊びに来てください。
▶ コーポレートサイト

エンジニアの方に役立つ記事をまとめたサイトも運営しています。もしご興味あれば覗いてみてくださいね。
▶ エンジニアに役立つ記事サイト

9割の新人エンジニアがやっている 「失礼しました」の落とし穴（後編）