メインコンテンツへスキップ
キャリア船木 俊介約9分で読めます

エンジニアが評価されないのはなぜか|評価の基準と、次の面談までにできること

エンジニアが評価されないのはなぜか|評価の基準と、次の面談までにできること

エンジニアが評価されないと感じるのは、どんなときか

以前より難しい実装を任されるようになった。設計の相談を受けることも増えた。それなのに、評価面談では「今回も同じ評価です」と言われる。技術力がついてきた実感があるほど、納得しにくいものです。

採用面接でも、「前の職場で評価されなかった」という話を聞きます。詳しく尋ねると、評価基準が分からなかった、成果が給与に反映されなかった、評価は良くても上に先輩がいて新しい役割を担えなかった、と事情はさまざまです。

私自身、社内ではチームをまとめる役割の社員について、評価する側として判断に関わっています。そこで大切にしているのは、会社や上司がその人に期待している役割を、実際に果たせているかということです。本人が力を入れてきた仕事と、その期待が一致しているとは限りません。

エンジニアが評価されないと感じる理由は、「期待されている役割」「評価する人からの見え方」「評価の仕組み」の3つに分けて考えると整理できます。誰かの努力不足、あるいは会社の問題だと最初から決める必要はありません。まずは自分が何を期待されているのか、そこから確かめてみましょう。

担当工程が変わったのに評価や報酬が動かない場合の見方は、SESで上流工程に行けるかでも扱っています。

エンジニアの評価基準は、何を見て、どう決まるのか

評価基準を考えるとき、最初に押さえておきたいのは、同じ仕事ぶりでも、期待される役割によって評価の意味が変わることです。

実装を担う段階なら、求められた機能を品質と納期を意識して仕上げることが評価の中心になるでしょう。設計を任される段階では、仕様を整理し、後工程に問題を残さない判断が求められます。さらにチームをまとめる役割なら、自分の担当作業が終わったかだけでなく、メンバーの仕事が進み、チームとして成果が出ているかまで問われます。

技術力が伸びたという本人の実感と、評価する側の判断が食い違うのは、この役割の違いを共有できていないときです。評価者である上司や会社は、その人に何を担ってほしいと考えているのか。それが明確でなければ、本人も力の使いどころを判断しにくくなります。

当社の評価でも、技術の基礎や仕事の安定性に加え、AI・自動化による生産性の改善、レビューや知識の共有、周囲との連携と信頼を見ています。扱う領域によって重点も変わります。エンタープライズ領域では設計品質や合意形成、継続性、安心して任せられること。デジタル領域では実装力や新しい技術への適応、スピードと品質、改善を進める力です。

評価の仕組みを知るには、項目だけでなく、誰が、どのくらいの間隔で仕事ぶりを確認し、結果が何に反映されるのかも見ておきたいところです。役割が広がること、社内クラスが上がること、給与に反映されること。この3つは、必ずしも同じタイミングでは起こりません。

当社では上司との評価面談を3か月ごとに設け、社内クラスと役割、報酬のつながりを定めています。詳しい運用は後半で紹介します。

評価されない理由は、3つのずれに分けられる

1. 期待されている役割とのずれ

例えば、チームをまとめることを期待されているエンジニアが、難しい実装をほとんど自分で抱えていたとします。技術的な問題を解決し、誰よりも作業を進めている。現場では頼りにされる存在でしょう。

ただ、会社がその人に期待しているのが、メンバーに仕事を任せ、困っている人を支え、チーム全体の成果を引き上げることなら、評価は別の見方になります。難しい仕事を自分で片づけることにも価値はあります。それだけでは、チームを動かすという役割を果たしたことにはなりません。

このずれは、努力が足りないという話ではありません。何に力を注ぐべきかを本人と上司が共有できているかという問題です。会社が期待している役割を知らないまま、本人が得意な仕事に力を注ぎ続けていることもあります。

同じ技術力でも、改善提案によって仕事の進め方が変わるケースについては、エンジニアの提案力の記事で詳しく取り上げています。

2. 評価する人からの見え方とのずれ

設計レビューで後輩の疑問に答える。障害調査の経緯を記録し、次に同じことが起こったときに使えるようにする。作業手順を整理して、チーム内で共有する。どれも開発を支える仕事ですが、成果が一つの機能の形では見えにくい仕事です。

上司が日々の現場に同席していなければ、その貢献を把握しきれないこともあります。面談の間隔が長いと、どうしても最近の出来事が印象に残りやすい。社員インタビューでも、以前の会社では評価面談が年1回だったため、直近の業務の印象が強くなっていたという話が出ています。

ここで要るのは、周囲にどんな変化があったかを伝えることです。誰の判断を助けたか、何が進むようになったか。レビューや育成のような見えにくい仕事も、事実が伝われば評価の材料になります。

3. 評価の仕組みとのずれ

期待された役割を果たしていても、評価が給与に結びつかない。上に先輩がいて、評価が良くても次の仕事を担う機会がない。そうした場合は、個人の仕事ぶりとは切り分けて、制度のほうを確かめます。

役割と評価の関係はPLとPMの違いで、担当工程が変わったあとの評価や報酬の確かめ方はSESで上流工程に行けるかで解説しています。

評価を上げるために、エンジニアが次の面談までにできること

評価を上げたいと考えたとき、最初にするのは実績の書き方を工夫することではありません。自分のクラスや担当に対して、何を果たすことが求められているのかを上司と確認することです。

「もっと評価してほしい」だけでは、話が噛み合わないことがあります。代わりに「いまの役割で、できていることと足りないことは何ですか」「次の役割を担うには、どんな仕事を任せられる状態になる必要がありますか」と聞いてみる。

抽象的な「主体性」「リーダーシップ」という言葉が返ってきたら、現場での行動に落とし込んで確認します。例えば「リーダーシップが足りない」と言われた場合、進捗管理なのか、メンバーのフォローなのか、顧客との調整なのかによって、次に取る行動は変わります。

次に、期待との間にある差を一つ選びます。例えばチームをまとめることが課題なら、難しい作業を自分で片づけるだけでなく、メンバーが自分で進められるように作業を切り出す、相談の場を設ける、といった動きが考えられます。あれもこれも増やす必要はありません。いまの仕事の中で変えられることから着手します。

そして、変化を残しておきます。顧客や周囲から受けた具体的な言葉、判断したこと、改善の前後でどう仕事が進むようになったか。後から思い出せるよう、短いメモで十分です。面談ではその事実をもとに、会社の期待にどこまで応えられたかを上司と確認できます。

評価を変える行動は、面談当日より前に始まっています。次の面談までの仕事の進め方を、少し変えるところからです。

スーパーソフトウエアの評価の仕組み

スーパーソフトウエアでは、技術を基盤に、顧客とシステムを理解し、人とAIを組み合わせながら開発を前に進める「開発推進力」を評価しています。

見ているのは設計・実装の質に加えて、AIや自動化を活用して生産性を高めること、改善を提案すること、レビューやドキュメントを通じて知見を広げることです。当社が掲げる5つの能力のうち「共有する力」は、個人の経験をチームの力に変える取り組みを指しています。

評価面談は3か月に1回。顧客から本人に直接伝えられた声を共有することもあれば、営業担当が顧客にフィードバックを求めることもあります。現場での取り組みを、上司が定期的に把握する仕組みです。

社員インタビューでは、短いサイクルで評価を受け、顧客の反応を知ることが励みになっていると語られています。別の社員インタビューでは、担当外のフォローや障害調査にも取り組み、入社半年で小チームのリーダーを任された例を紹介しています。

現場で担える領域や解ける課題の難度が広がれば、評価基準に照らして役割と社内クラスを判断します。クラスには期待される役割と報酬が結びついており、これまでの経験や会社への貢献の積み重ねも考慮します。詳しくはキャリアページをご覧ください。


この記事のテーマについて、もっと話を聞いてみたい方へ: