エンジニアの業績評価をやめるべき理由
身も蓋もない言い方をすれば、エンジニアの評価なんて必要ない。というか、できない。
できない理由は幾つかある。エンジニアに求められるスキルは広く深さがある。その人を形作る基礎スキルはもちろん、エンジニアが身につけている技術を適用してアウトプットする技術スキルの両方が評価対象となる。
評価対象は、所属する組織の事業により違いがある。事業領域が広ければ、事業として必要とする技術領域は広がる一方、そうした技術の幅は一人のエンジニアでは賄えないから複数のエンジニアでカバレッジをすることになる。結果、同じ事業を一翼を担うエンジニアの担当する技術は違うが、評価は同じ軸で行われる。
そこで持ち出すのが事業への貢献、役割になる。ビジネスでリーダーシップを発揮したか、などを問うようになる。
担当する業務もSI（新規開発）とSO（維持管理）で同等の評価をしない。SIでは新しいビジネス、サービス開発により事業貢献を評価されやすい。一方、SOでは安定させて当たり前、コスト削減して当たり前とエンジニアのビジネスに対する要求が違う。それを並べて評価しているのが現実だ。
ファーストライン、課長やエンジニアリングマネージャなど現場のマネージャならエンジニアの顔を見れるし、何をやっているかはレポート、ミーティングや1on1などでも知り得る。組織の上に行けば行くほど管理スパンが広がるのと同調してエンジニアの技術領域も広がる。上に行けば行くほどごった煮の鍋をかき混ぜながら評価しなければならなくなる。
評価して欲しい現場の長は評価に有利に働くように都合のよい数字を持ち出す。担当する事業領域が広く、嵩もあるなら売り上げや利益を持ち出し、配下に有利にしようとする。金融事業が評価されやすいのはそした背景があるからだ。新規事業、イノベーション事業はそうした旧態のビジネスが幅をきかせる中では多勢に無勢にしかならない。
では、ベンチャーやWeb系のエンジニアはどうかというと、本質は変わらない。適用技術が入れ替わるだけで、エンジニアの評価でやっていることは変わらない。年収を開示して、全員で評価するような形態をとっていても、それは評価者が負わなければならない評価の責任をメンバに付け回しているだけだ。
メンバで評価するのは、評価責任を押し付けているだけだというのも、メンバが評価軸や評価指標を持っているわけがなく、強く残った印象で評価しているからだ。日々のちょっとした気遣いによるリスク低減や段取りの手配などは気づけないメンバには評価しようがない。当たり前を当たり前にやることの評価はほぼゼロに近い。
評価が悪ければ居づらくなるため、自助による浄化作用を促しているだけに過ぎない。あいつはロクに働いていないのに文句ばかり言うと言うような輩を排除できるだけましなのかもしれない。ただ、それはエンジニアの評価というよりは、組織としてのパージ機能が働いているのだろう。
結局、エンジニアに限らず評価は様々なことに目を覆いながら評価せざるを得ない。
エンジニアの育成を目的とした目標設定とそれの実績の評価は切り離すのが良い。そして目標と実績からの次の目標設定はするとして、実績からのエンジニアの評価はやめるべきだ。
もう、年収に事業業績（プラスでもマイナスでも）一律に掛けて業績評価とした方が、業績評価という様々なことに目を覆っていることにコストを掛け続けるよりシンプルでいい。何より、全員で業績をダイレクトに享受することができる。
東京大学のデータサイエンティスト育成講座 ~Pythonで手を動かして学ぶデ―タ分析~
- 作者: 塚本邦尊,山田典一,大澤文孝,中山浩太郎,松尾豊[協力]
- 出版社/メーカー: マイナビ出版
- 発売日: 2019/03/14
- メディア: 単行本（ソフトカバー）
- この商品を含むブログを見る
