はじめまして。
株式会社PRUMでエンジニアをしている人見です。日々、プログラミング学習や実務の中で、つまずきやすいポイントを整理して発信しています。
PRUMについて気になった方は、コーポレートサイトもご覧ください。
▶ コーポレートサイト
9割の新人エンジニアがやっている 「失礼しました」の落とし穴（後編）
はじめに
前回は、「失礼しました」とすぐに謝ってしまう背景や、
そこにある思考停止について整理しました。
指摘されるたびに謝ってしまう。
そして内心では「自分はダメだ」と感じてしまう。
でも実際のレビューって、
「ダメ出し」じゃなくて「良くするための提案」なんですよね。
ただ、それが分かる前に心が折れる。
では、どうすればいいのでしょうか。
「考えろ」は正しい。でも、それだけでは足りない
指摘を受けたとき、
「ちゃんと考えよう」と思っても、
- 何が問題なのか分からない
- 前提が見えない
という状態は普通に起きます。
これは能力の問題ではありません。
人って、わからないことが一気に来ると、
とりあえず楽な方に逃げるんですよね。
つまり「とりあえず謝る」は自然な反応です。
ただし問題は、
そこで思考が止まることです。
なぜ考えきれないのか
理由はシンプルです。
現場には暗黙知があるからです。
- 過去の経緯
- チームのルール
- 言語化されていない前提
これらは仕様書には出てきません。
つまり、
個人の思考だけでは到達できない領域がある。
だから「聞く」は正しい。ただし差が出る
分からないときに聞くことは、逃げではありません。
むしろ最短で理解に辿り着く行動です。
ただし、ここで大きな差が出ます。
NGパターン（よくある）
どうしてこうなんですか？
👉 情報をもらうだけで終わる
OKパターン①（意図確認）
〇〇という意図で実装したのですが、
この部分の認識が違っていそうでしょうか？
👉 自分の考えを出している
👉 相手がズレを指摘しやすい
OKパターン②（理由を聞く）
この実装だと問題になるポイントを、
もう少し教えていただいてもいいですか？
👉 表面的な修正ではなく、理解にフォーカス
OKパターン③（仮説＋確認）
〇〇の観点で考えると、
こちらの方がよさそうだと思ったのですが、
この認識で合っていますか？
👉 判断力がある人の聞き方
この違いはとても大きいです。
自分の考えを出しているかどうか。
ここが、理解の深さを分けます。
仕事ができる人の正体
ここ、めちゃくちゃ誤解されがちなんですが、
仕事ができる人は、
正解を知っている人ではありません。
正解を作るために、
考え続けることをやめない人です。
言われた通りに直すだけなら作業で終わります。
でも、
- 仮説を出す
- 比較する
- 納得して修正する。
このプロセスは「判断」です。
そして、この積み重ねが
そのまま深い理解・実力につながります。
レビュワーも完璧ではない
レビュワーも人間です。
- 前提のズレ
- 情報不足
- 認知バイアス（思い込み）
普通に起きます。
だからこそ
「指摘＝正解」とは限りません。
重要なのは、
受け取ることではなく、すり合わせること。
まとめ
やることはシンプルです。
- 分からなければ聞く
- 仮説を持って伝える
- 認識をすり合わせる
「言われた通りに直す」で終わるか、
「自分の考えを持って判断する」までいくか。
この違いが、そのまま成長の差になります。
また、
レビューは、一緒により良いものを作る場です。
その中で、自分の考えを出せるかどうか
そこが、次のステージに進めるかの分かれ道になります。
PRUMのエンジニアの95%以上は未経験からの採用です。
よければコーポレートサイトにも遊びに来てください。
▶ コーポレートサイト
エンジニアの方に役立つ記事をまとめたサイトも運営しています。もしご興味あれば覗いてみてくださいね。
▶ エンジニアに役立つ記事サイト