エンジニアの人事評価|成功している企業はおさえている3つのポイント

 2021.03.02  株式会社システムインテグレータ

転職エージェントとして延べ1,000名以上のエンジニアと面談してきた私が、エンジニアが納得できる評価制度を策定するためのアドバイスとして、実際にエンジニア評価に成功している企業様の実例を元にまとめました。

本記事では、エンジニアが納得できる評価制度を策定するために、まず初めに意識して頂きたい3つのポイントを解説します。

ポイント1:まず重要なのは定量評価

エンジニアの人事評価で多くの企業で課題になっていることは、営業職と違って客観的な数値で成果を判断することができず、定量評価ではなく定性評価が軸となっているということです。エンジニアに対して定性評価をしてしまうと、評価者の感覚によって左右されてしまい、エンジニアが納得いく評価をすることが困難になってしまいます。

そこで、まず初めに、エンジニアが納得できる評価制度を策定するために、定量評価を導入する方法について解説したいと思います。

1.1 評価項目の細分化

まず定量評価を導入する前に行うべきことは、評価項目の細分化です。評価項目細分化のポイントは、「できた」「できなかった」を明確にすることです。

1.2 「組織貢献度」を評価する例

例えば、「組織貢献度」という項目があった場合、何を持って組織貢献できたと判断するのかが曖昧です。

組織貢献度を評価項目としたいのであれば、まず自社における組織貢献とは何かを要件定義し、その要件が「できた」「できなかった」で明確に判断できるものかを確認してください。

例えば、「自分が持っているノウハウを他のメンバーにも共有し、エンジニア全体のスキルアップの底上げに貢献して欲しい」ということが組織貢献であるならば、評価項目を「自身がスピーカーとして主催した技術勉強会が1回以上ある」とすれば、「できた」「できなかった」が客観的を評価できます。

1.3 「技術スキル」を評価する例

技術スキルについても同様で、「Javaの開発スキルがある」という評価項目について、それがどういう状態なのかを明確に定義し、「基本的な構文を理解し、単体機能においては概ね自分だけの力で開発を進めることができる」などと設定することで、今の段階では何をできていれば良いのかが少し明確になります。

ただし、技術スキルにおいては、エンジニア本人が「自分の力で開発できている」と思っていても、上長の目からするとそうでもないと評価に乖離が発生する可能性もあります。

そこで、定性評価項目を策定した次に行うべきことは、エンジニア自身にも自己評価を付けてもらうことです。

ビッグデータ時代の必須科目 SQLの教科書
教養としてのプログラミング入門BOOK

ポイント2:自己評価と上長評価はどちらも必要

一方通行な評価をしてしまうと、エンジニアからは「自分は頑張っているのに、なぜこの評価をされるのか」と不満が出てしまいます。

また、評価面談は「できた」「できなかった」を判断する場ではありますが、より有益な場にするためには、今後評価を上げるためにどう行動すべきなのかのすり合わせまでする必要があります。

2.1 エンジニアに自己評価をつけてもらう

そこで、一方通行の評価にならないためにも、必ず評価面談前にエンジニアに自己評価をつけてもらうことをお勧めします。同時に上長も同じ項目に対してエンジニアの評価をつけ、評価面談の場においては、双方の評価を見比べながらなぜ乖離が生まれてしまっているのか、何が足りなくて上長評価のほうが低いのかなどを議論する場にできるとより効果的です。

そして、エンジニア自身に、なぜその自己評価にしたのかを説明させることで、考えのミスマッチが起きなくなります。

2.2 「できない」ばかりに目を向けるのは厳禁

ただし、できなかったことばかりを話すのは厳禁です。エンジニアのモチベーションが低下してしまうリスクが高いので、評価面談では余程のことがない限りは褒めることに重点を置くと良いと思います。評価面談においては、まずは褒めることから始め、その後に改善すべきポイントを伝えたほうがエンジニアも聞く耳を持ってくれるためにお勧めです。

「褒める」と「注意する」の割合は、7対3か8対2ぐらいで考えるとエンジニアのモチベーションを高く保つことができます。

ポイント3:客先常駐中のエンジニアの評価に要注意

ここまでエンジニアの評価に対するポイントについてお伝えしましたが、評価面談の日まで放置をしてしまってはいけません。特に、客先常駐中のエンジニアを評価する時には注意が必要となります。

3.1 久々に顔を合わせる上長からの評価は不満の原因

それまであまり声がけをしていなかったにも関わらず、久々に顔を合わせた上長に評価をつけられるというのはエンジニアも納得をしません。実際に、「何も見ていないのに評価をされる」ということを不満に感じて転職をしてしまうエンジニアも非常に多くいます。

そうなってしまわないためにも、自社にいないエンジニアに対しては特に意識してコミュニケーションを取る必要があります。

3.2 定期的に1on1ミーティングを実施する

本来であれば、毎週1on1ミーティングなどを設けて、目標に対する進捗度合いの確認や、思っていることの共有の場にできれば良いのですが、毎週時間を作るのは難しい場合もあるかもしれません。

その場合は、毎月か、せめて3ヶ月に一度は中間面談などを設けるなど、エンジニアとコンタクトを取る機会を設けることをお勧めします。顔を合わせて面談するのが難しい場合は、Webミーティングツールを活用して、エンジニアと会話してください。

まとめ

エンジニアを評価するポイントは、大きく次の3点です。

  • 定性評価ではなく、定量評価を導入する
  • エンジニア自身にも自己評価させる
  • 評価面談以外にもエンジニアとコンタクトを取る機会を設ける

これらはあくまでもエンジニアの評価方法の一例ではありますが、自社の特性に合わせたカスタマイズを行うことにより、是非エンジニアが納得する評価制度を策定していただければと思います。

教養としてのプログラミング入門BOOK

RELATED POST関連記事


RECENT POST「教育」の最新記事


教育

ITSS(ITスキル標準)とは?社内に必要なスキル、7段階のレベルと11の職種を紹介

教育

プログラマーに必須の研修とは?プログラミング未経験でも成長できる育成・教育のポイント

教育

プログラミング適性とは?向いている人の特徴や見極めの要素を解説

教育

コーチングとは?ティーチングとの違い、メリット、ビジネスでの活用について解説

エンジニアの人事評価|成功している企業はおさえている3つのポイント

TOPSIC TOPへ

新規CTA

TOPSIC-SQL4コマ漫画

RANKING人気資料ランキング

RANKING人気記事ランキング

RECENT POST 最新記事