エンジニアの評価はマネージャに見えていた残像でされている

エンジニアの業績評価は難しいのです。何せ、誰一人として同じ仕事をしていないところで、1年分の労働に対する貢献度を評価しなければならないのですから。

評価方法と言えるかどうかも怪しいですが、それぞれの組織においてエンジニアの業績方法は通常、人事担当が主務として構成し、それをマネージャに指示するのが一般的でしょう。

エンジニアの業績評価での問題点というか曖昧さが生じる事項は次のようなものが挙げられます。

同じ仕事でないエンジニアを1つの評価基準で評価しようとしていること
エンジニアの仕事をマネージャが全て知っているわけではないということ
エンジニア個人の絶対評価と組織の中での相対評価の2軸があること
評価結果は次年度予算に組み込まれるので評価の上限があること
マネージャは人の評価方法を知らないこと

同じ仕事でないエンジニアを1つの評価基準で評価しようとしていること

製造業で、同じラインで働いているなら、評価もしやすいでしょう。生産計画に従った生産量を確保でき、期待する品質を確保できるような監視と予防活動に取り組み、後進を指導し、勤怠も問題なければプラスの評価をされるでしょう。

ものを作ることには変わりはないですが、エンジニアは一人ひとりの作業が違います。まあ、大規模プロジェクトで同一サブシステムの機能を分担してプログラムを書くようなケースは割とニアリーイコールかもしれませんがやはり担当する機能の難易度が同じということはないです。何かしら違うので。

つまり、評価対象であるエンジニアの業務の成果は一品ものなのだ、という評価対象が違うというところの理解が必要です。

エンジニアの仕事をマネージャが全て知っているわけではないということ

標題のとおり、エンジニアの仕事をマネージャが全部知っているわけではないです。マネージャもプロジェクトにどっぷり入って、プロマネ＝マネージャのようなアサイメントなら割と知っているかもしれませんが、それでもやはり、エンジニアのひとつ一つの成果までは知りようがありません。断片的に、進捗や品質評価でしか知りようがないのです。

エンジニア個人の絶対評価と組織の中での相対評価の2軸があること

エンジニアの成果の評価は、個人の成果を評価する軸とそれを組織の中での貢献度合いを評価する2つの軸で評価するケースが多いです。なぜなら、前者だけで評価をしてしまうと、エンジニアの評価がインフレを起こしやすいからです。

どういうことかというと、評価項目に対して達成したかどうかになるのでやったと言いやすいし、エビデンスとしての成果が提示できれば評価せざるを得ないからです。

一方、組織としては有能なエンジニアは上に引っ張り挙げたいので序列をしたくなるのです。結果的に相対評価が必要になります。

評価結果は次年度予算に組み込まれるので評価の上限があること

エンジニアの対価は予算措置をされた上で支払われています。つまり、前年の評価を考慮し、昇給を反映した上で労務費を計上しているわけです。

逆に言えば、労務費の予算枠があるよ、それ以上は評価＝昇給はできないよということです。

いくらエンジニアが評価しろ、昇給させろと言っても枠でキャップがかかるのでその中で調整が組織全体で入るよということです。

マネージャは人の評価方法を知らないこと

これが一番の問題なのですけれど…マネージャが正しい業績評価の手法を学び、習得しているなんて思ってはいけません。

例えば、オリジナルだとしても評価方法を持って、その評価方法で評価しているマネージャなんて一握りくらいなものです。ちなみに、これまでそうした評価方法をしているマネージャは一人を除いて聞いたことはありません。

つまり、エンジニアの評価はマネージャの印象で評価されているのです。これは、エンジニア同士の評価であっても同じです。基本的には持っている情報若しくは提供される情報の範囲だけで主観により評価されているのです。

問題だと思うことは、印象で評価をすることになるのでマネージャに見えているエンジニアほど良くも悪くも評価を受けやすいということです。マネージャが評価方法を持っていて、評価項目からエンジニアを見る場合は全てのエンジニアを評価項目の視点で見ようとするので同じ評価軸で評価する方向に働きますが、エンジニアの見えている部分だけで評価するマネージャはマネージャに対する見え方でバイアスが強く掛かるので評価軸で評価するマネージャとは違う評価結果を出します。

マネージャの見え方で評価しているから労働時間が長いエンジニアや炎上させて周りを巻き込んで鎮火に到るまで残ったエンジニアが評価をされるのです。

違いますよね。本来であれば、