「これだけ動いたのに、結局なにが評価されたのか分からない」。優秀なエンジニアほど、この一言を残して静かにチームを去っていきます。

評価のたびに、チームの温度が下がる

半期に一度の評価面談。本来はメンバーの努力に報いる場のはずが、この時期を境に開発チームの空気が重くなる——そんな逆転現象を、私たちは何度も見てきました。あるエンジニアは、深夜にまたがる難しい障害を一人で収束させた数ヶ月後、それが評価にほとんど反映されていないと知り、翌四半期から「言われたことだけをやる人」に変わってしまいました。退職理由のアンケートでも、「評価や処遇への納得感のなさ」は上位3割を占める定番です。スキル不足で辞めるエンジニアより、納得できずに冷めていくエンジニアのほうが、実はずっと多いのです。

「成果」だけを見ると、エンジニアの仕事は半分しか見えない

なぜ評価がこじれるのか。背景には、エンジニアの貢献の多くが「目に見えるリリース」の外側にある、という構造があります。技術的負債を返して将来の事故を防ぐ。レビューで同僚の手戻りを未然に止める。落ちかけたシステムを、誰も気づかないうちに支える。これらは「何も問題が起きなかった」という形でしか表に出ません。成果物の数だけを並べる評価軸は、この「見えない貢献」を構造的に取りこぼします。結果として、派手な新機能を出した人だけが評価され、足元を支えた人が報われない——優秀な人から順に冷めていくのは、むしろ当然の帰結です。

納得感は「結果」ではなく「説明できること」から生まれる

評価への納得は、点数の高さではなく、過程を説明できるかどうかで決まります。私たちが意識しているのは次の4点です。

  • 評価基準を期の「前」に開示する。終わってから基準を後付けしない。
  • 見えない貢献を記録に残す。レビュー履歴、障害の予防対応、ドキュメント整備を、本人の言葉で棚卸しする。
  • 面談の前半を「評価を伝える場」ではなく「事実をすり合わせる場」にする。認識のズレは、ほとんどがここで解ける。
  • 上がらなかった理由を、次に上げるための具体的な行動に翻訳して渡す。

実際、面談を「事実のすり合わせ」中心に組み替えたチームでは、評価への納得度（5段階の自己申告）が平均で3.1から4.2へと上がりました。評価の中身そのものは大きく変えていません。変えたのは、過程の見せ方だけです。

さいごに

あなたのチームでは、メンバーが「何をすれば評価されるか」を、評価が始まる前に言葉で説明できるでしょうか。もし答えに詰まるなら、それは個人の頑張りの問題ではなく、設計の余地が残っているサインかもしれません。

評価や組織づくりに本気で向き合うチームで働いてみたいと感じた方は、エイトの採用ページから気軽に声をかけてください。