評価面談で損するエンジニアの共通点|成果が伝わらない本当の理由


評価面談で「頑張りました」と伝えているのに、昇給や役割につながらない。

こう感じているエンジニアは少なくありません。実際、私は評価する側に回ってから、成果がないわけではないのに、面談でかなり損をしている人を何度も見てきました。

問題は、本人の努力不足ではありません。評価される材料の出し方が、会社側の評価フォーマットと噛み合っていないことが多いです。

この記事では、評価面談で損しやすいエンジニアの共通点と、採用側・評価側から見て伝わりやすい整理方法を話します。

この記事でわかること

  • 評価面談で成果が伝わらない理由
  • 「頑張った」だけでは評価されにくい構造
  • 採用側から見ても価値が伝わる実績の言い換え方
  • 次の面談までに準備しておきたい材料

評価面談で損する人は「作業量」を話しすぎる

評価面談でよくあるのが、作業量の説明に寄りすぎるパターンです。

  • チケットをたくさん消化しました
  • 障害対応を何件もやりました
  • リリース前に残業して間に合わせました
  • 他部署からの依頼にも対応しました

もちろん、これらは大事な仕事です。現場を回すうえで欠かせません。

ただ、評価する側から見ると、作業量だけでは判断しにくいことがあります。

なぜなら、作業量は「忙しかったこと」は伝わっても、会社にどんな変化を出したかまでは見えにくいからです。

たとえば同じ「障害対応をしました」でも、評価されやすい説明はかなり違います。

伝わりにくい説明伝わりやすい説明
障害対応を頑張りました障害発生から復旧までの平均時間を30分短縮しました
問い合わせ対応をしましたよくある問い合わせを整理し、一次対応件数を減らしました
実装をたくさんしました決済まわりの改修で離脱原因を1つ潰しました
レビューしましたレビュー観点を整理し、手戻りを減らしました

評価面談では、量よりも「何が変わったか」を言葉にする必要があります。

私はここで損している人を本当によく見ます。本人は地味に効く仕事をしているのに、「忙しかったです」で終わってしまう。これだと評価者は、上位者に説明する材料を持てません。

評価は、直属の上司だけで決まるとは限りません。評価会議や等級調整の場で、他のマネージャーに説明されることもあります。そのときに伝わる言葉へ変換しておくことが大事です。

評価されにくい人は「再現性」を説明していない

採用側から見ると、エンジニアの価値は単発の成果だけでは決まりません。

かなり見ているのは、再現性です。

再現性とは、簡単に言えば「別の環境でも同じように成果を出せそうか」です。

社内評価でも同じです。たまたま一度うまくいったのか、本人の考え方や行動パターンによって成果が出たのか。この違いはかなり大きいです。

評価面談で損する人は、結果だけを話して、そこに至る考え方を説明していないことがあります。

たとえば、

  • なぜその設計にしたのか
  • どの選択肢を捨てたのか
  • どんなリスクを先に潰したのか
  • 周囲をどう巻き込んだのか
  • 次に同じ問題が起きたらどう再利用できるのか

ここまで話せると、評価者は「この人は任せ方を広げられる」と判断しやすくなります。

逆に、結果だけだと「今回はたまたま周囲が支えたのかもしれない」と見られることがあります。これは本人にとってかなりもったいないです。

特に、設計・運用改善・調整・レビューのような仕事は、成果が数字で見えにくいです。だからこそ、判断過程を残しておく必要があります。

「自分の仕事は地味だから評価されない」と思う前に整理したいこと

地味な仕事は評価されない、と感じる人は多いです。

ただ、採用側から見ると、地味な仕事の中にも市場価値が高いものはあります。

  • 障害対応を属人化させない
  • 運用手順を整える
  • 問い合わせを減らす
  • レビュー品質を上げる
  • 新人が迷わない状態を作る
  • 他部署との認識違いを減らす

これらは派手ではありません。しかし、会社にとってはかなり価値があります。

問題は、地味な仕事そのものではなく、価値の単位に変換できていないことです。

たとえば「問い合わせ対応をしました」では弱いです。

でも、

  • 月30件あった問い合わせをFAQ化して月10件に減らした
  • 調査に毎回30分かかっていた内容をダッシュボードで見られるようにした
  • リリース前確認の観点を整理して、手戻りを減らした

こう書くと、地味な仕事でも会社への効果が見えます。

評価面談では、仕事を大きく見せる必要はありません。事実を、評価者が扱える形に直すだけです。

この整理は転職活動でもそのまま使えます。面接で「何を改善しましたか」と聞かれたとき、地味な改善を成果として話せる人は強いです。

評価面談の前に作るべき「実績メモ」

面談直前に半年分を思い出そうとしても、かなり抜けます。

だから私は、月1回でいいので実績メモを残すことをすすめます。形式は簡単で構いません。

1. やったこと

まずは事実を書きます。

  • どの機能を担当したか
  • どの障害に対応したか
  • どの改善を進めたか
  • どの調整をしたか

ここではきれいに書く必要はありません。後で整理できれば十分です。

2. 変わったこと

次に、仕事の前後で何が変わったかを書きます。

  • 処理時間が短くなった
  • 問い合わせが減った
  • 手戻りが減った
  • リリースが安定した
  • 属人化が少し解消した

数字があれば一番いいです。数字がなくても、「誰の何が楽になったか」を書くだけで見え方は変わります。

3. 自分の判断

最後に、自分が何を考えて動いたかを書きます。

  • なぜその優先順位にしたのか
  • どんなリスクを見たのか
  • 誰と合意したのか
  • 何をあえてやらなかったのか

この部分が、評価面談でかなり効きます。採用側から見ても、ここを話せる人は実務の解像度が高く見えます。

上司に評価されないときの見方

ここまで準備しても、会社によっては評価されにくいことがあります。

理由は単純で、会社の評価制度がその仕事を見ていない場合があるからです。

たとえば、売上に直結する新機能だけが評価され、運用改善や障害予防がほとんど見られない会社もあります。マネージャーが技術的な負債の重さを理解していない場合もあります。

この場合、あなたの仕事に価値がないわけではありません。今の会社の評価項目と、あなたの貢献が噛み合っていないだけかもしれません。

採用側から見ると、運用改善や品質改善をきちんと語れるエンジニアは評価されることがあります。特に、事業会社やSaaS企業では、安定運用や継続改善の経験はかなり見られます。

だから、現職の評価だけで自分の価値を決めないほうがいいです。

もちろん、すぐ転職する必要はありません。ただ、外の求人や面談でどんな経験が評価されるのかを見ると、現職での評価のズレがかなりわかります。

面談でそのまま使える言い換え例

評価面談では、話す順番も大事です。

私がすすめるのは、「事実」「変化」「自分の判断」「次に広げたい役割」の順に話すことです。

たとえば、ただ「レビューを頑張りました」と言うのではなく、次のように言い換えます。

今期はレビューの手戻りが多かったため、観点をテンプレート化しました。結果として、仕様確認の抜け漏れが減り、若手メンバーが自分で確認できる範囲も広がりました。次は、この観点をリリース前チェックにも広げたいです。

この言い方だと、評価者はあなたの仕事を説明しやすくなります。

もう一つ例を出します。

障害対応では、復旧だけでなく再発防止まで担当しました。ログの見方を整理し、一次切り分けの手順をドキュメント化したことで、同じ種類の問い合わせを自分以外でも対応できる状態にしました。

ここまで言えれば、単なる火消しではなく、運用改善として伝わります。

評価面談で損する人は、仕事の価値が低いのではありません。評価者が上に説明できる形まで、あと一歩言葉が足りていないだけです。

次の半年で評価材料を増やすなら

今から評価材料を増やすなら、派手な新機能だけを狙う必要はありません。

むしろ、次のような仕事を拾うと、評価面談で話しやすくなります。

  • 毎月発生している問い合わせを減らす
  • レビューで毎回指摘される観点を整理する
  • 障害時の初動手順を作る
  • 開発環境の詰まりを解消する
  • 仕様確認の認識違いを減らす

どれも地味ですが、前後の変化を説明しやすい仕事です。

大事なのは、半年後に「やりました」と言うのではなく、始める前から「何を減らすのか」「誰の負担を軽くするのか」を決めておくことです。そうすると、評価面談の材料は自然に残ります。

上司に渡すメモは短くていい

評価面談の前に、長い資料を作る必要はありません。

むしろ、上司が評価会議で使いやすいように、短いメモにしたほうが効果的です。

  • 今期の主な成果を3つ
  • それぞれの前後比較
  • 自分が判断したこと
  • 次に担いたい役割

この4点だけで十分です。

評価者も忙しいので、情報が多すぎると逆に使いにくくなります。「この人は何を変えたのか」が一目でわかる状態にしておくと、評価会議で説明されやすくなります。

現職で評価されたい場合も、転職市場で評価されたい場合も、基本は同じです。自分の仕事を、相手が判断しやすい形に変換する。その一手間で、同じ実績でも見え方はかなり変わります。

まとめ

評価面談で損するエンジニアは、成果がないのではなく、成果の出し方が評価者に伝わっていないことが多いです。

  • 作業量ではなく、変化を話す
  • 結果だけでなく、判断過程を話す
  • 地味な仕事を価値の単位に変換する
  • 月1回の実績メモを残す
  • 現職の評価と市場評価を分けて考える

この5つを意識するだけで、評価面談の伝わり方はかなり変わります。

それでも評価が変わらないなら、今の会社の評価制度があなたの役割を見ていない可能性があります。一度外の相場を見て、同じ経験がどう評価されるか確認してみる価値はあります。

関連記事