はじめまして。株式会社PRUMでエンジニアをしている人見です。
日々、プログラミング学習や実務の中で、つまずきやすいポイントや考え方を整理して発信しています。
PRUMについて気になった方は、コーポレートサイトもぜひご覧ください。
▶ コーポレートサイト
【前編】9割の新人エンジニアがやっている 「承知しました」の落とし穴
はじめに
「承知しました」と返したあと、普通に間違えたことない？
指摘された内容を直した“つもり”なのに、「違う」と言われる。
同じレビューを何度も往復して、「さっき言ったよね？」になる。
でもその直前、ちゃんとこう言っている。
「承知しました」
この一言、実はかなり危ない。
なぜなら、
理解していない状態を、自分で“理解したこと”にしてしまうトリガーだから。
問題は「伝え方」ではない
よくある上司の悩みはこれ。
「説明が足りなかったのかな？」
もちろんそれもある。
でも、本質はそこじゃない。
本当の問題は、
“理解の完了判定をどこでしているか”
にある。
人は「承知しました」と言った瞬間、
“理解が完了した”と脳内で扱う。
ここでズレが固定される。
「理解したつもり」を分解する
ここで一度、「理解する」という行為そのものを分解してみる。
理解は、次の3段階に分けられる。
① 言葉を聞く（インプット）
② 内容をなんとなく把握する（表層理解）
③ 自分で再現できる（実践理解）
つまり、
“自分で再現できる状態”になって初めて理解したと言える。
でも、実際に起きているのは違う。
多くの場合、人は②の段階で止まる。
- 説明は分かった
- なんとなくイメージもできる
- だから「理解した」と感じる
ここで、
「理解した」というラベルを貼ってしまうのだ。
そしてこの瞬間、
まだ②なのに、③まで終わったことになる。
つまり、「できない状態のまま、できる前提で進んでしまう。」
なぜ起きるのか
これは能力ではなく構造の問題。
人は「理解する」のではなく、「理解したと感じる」生き物だからだ。
納得できた瞬間に、人はそれを「理解」と判断してしまう。
会話は“今すぐ返事”を求める。
でも理解は時間がかかる。
このギャップを埋めるために、「承知しました」が使われる。
この状態のまま進むと、
・認識ズレが発生する
・手戻りが増える
・同じ指摘を繰り返す
そして最終的に、「あれ？なんでできないの？」になる。
ここが一番痛いところ
問題の本質はここ。
「理解していないこと」ではなく、
「相手と同じゴールを見ていないこと」
リーダーはこう考えている。
・なぜそれをやるのか
・どの状態になればOKか
・どこまでの品質を求めているか
一方で、作業する側はこうなりがち。
・言われたことをそのままやる
・とりあえず動けばOKと考える
・自分の解釈で進める
つまり、
同じ指示を聞いているのに、見ているゴールが違う。
それなのに「承知しました」と言った瞬間、
ゴールが揃っている前提で作業が始まる。
ここでズレてしまうのだ。
次回予告
じゃあ「理解した」とは何か？
ここを曖昧にしたままだと、ずっとズレる。
後編では、本当の理解 まで落とし込む。
PRUMのエンジニアの95%以上は未経験からの採用です。
よければコーポレートサイトにも遊びに来てください。
▶ コーポレートサイト
エンジニアの方に役立つ記事をまとめたサイトも運営しています。もしご興味あれば覗いてみてくださいね。
▶ エンジニアに役立つ記事サイト