Contents
結論
技術的に正しいことをしているのに評価されない原因は、
能力不足ではありませんでした。
相手が見ている論点と、自分が説明している論点がズレていただけでした。
まずこの順で話す：論点合わせテンプレ（コピペ可）
説明が通らないときは、技術の前に「相手の判断材料」を先に出します。
迷ったら、まずこの順で話してください。
- 何が変わるか（結論）
- 業務・運用への影響
- リスクと抑え方
- （最後に）実装の詳細
この順にするだけで、往復説明が減ります。
さらに「そもそも全部を抱え込みがちで消耗する」タイプの人は、次の記事が土台になります。
→ STEP3：考え直すきっかけになった1冊へ
よくある行き詰まり
エンジニアとして仕事をしていると、
こんな経験はないでしょうか。
- 実装としては正しいはず
- 動作確認もできている
- なのにレビューや説明で引っかかる
指摘されるたびに、こう感じます。
- 「なぜ伝わらないのか分からない」
- 「技術的に説明しているのに納得されない」
このとき、
「もっと説明がうまくならないといけない」と考えがちですが、
問題はそこではありませんでした。
自分がハマっていた説明の仕方
以前の私は、
説明の出発点が常に「技術」でした。
- なぜこの実装にしたのか
- どんな制約があったのか
- 技術的にどう正しいのか
しかし、相手の反応は曖昧です。
「それは分かったけど、なぜ今やるのか」
「本当に問題ないと言い切れるのか」
当時は、
技術の説明が足りないのだと思い込み、
さらに細かい話を重ねていました。
結果、
会話は噛み合わないまま終わります。
読書で気づいた視点
読書を通じて気づいたのは、
人は同じ話題でも、見るレイヤーが違うということでした。
- エンジニアは「実装の正しさ」を見る
- 上司や関係者は「影響・リスク・安心」を見る
この違いを無視して説明すると、
どれだけ正確でも伝わりません。
問題は技術力ではなく、
論点の階層を合わせていなかったことでした。
実務で変えたこと
1つだけ試す：次の会話で使う短文
次のレビュー／説明の場では、最初にこの1文だけ言ってください。
「最初に“影響とリスク”から共有します。実装の細部は最後に回します。」
これで、相手の不安（判断軸）に先に触れられます。
それ以降、説明の順番を変えました。
先に伝えるようにしたこと
- 今回の対応で何が変わるのか
- 業務や運用に影響はあるのか
- リスクはどこにあり、どう抑えるのか
あとで伝えること
- 実装の詳細
- 技術的な判断理由
この順にしただけで、
相手の反応は明らかに変わりました。
「なるほど、そこが分かれば大丈夫」
と言われる場面が増え、
不要な往復説明も減りました。
こうした考え方は、
技術書ではなく、仕事の向き合い方を整理する本から学びました。
その中でも、
自分の仕事の進め方を見直すきっかけになった1冊があります。
仕事と人間関係で消耗していた自分が「考え直す」きっかけになった1冊
まとめ
評価されない原因を、
自分の能力だけに求める必要はありません。
- 相手は何を判断しようとしているのか
- 自分はどの論点から話しているのか
このズレを意識するだけで、
説明の通りやすさは大きく変わります。
技術力は土台です。
評価されるかどうかは、
その上にどう翻訳するかで決まります。
関連記事
仕事がつらいエンジニアが最初にやるべきは転職でも努力でもなく「整理」だった話
努力に頼らず成果を出す：エッセンシャル思考は「仕組み化」と「バッファ」だった
評価が刺さって消耗するエンジニアへ 比較の呪いを外す本
