エンジニア組織の評価軸を調べてみた

エンジニア組織の評価制度についての調査のつづき。前回のエンジニアの評価制度について調べてみたでは方法面を中心に調べましたが、「ものさし」となる評価軸を少し調べてみました。

大切なこと

原則として、評価制度は企業や組織文化の影響を受けるため、ある程度の基礎部分を固めたあとは、自分たちなりのカスタマイズが必要になるはずです。

ただ、どこも似たようなことをやっている部分はあるので、そこは同じものを活用すればいいんじゃないかと思います。

役割：どういった振る舞いをするかをさすものとします。システムに置き換えると、メールサーバはメール配信を役割としてもっており、認証サーバはユーザ認証を担当するはずです。メールサーバと認証サーバのどちらがすごいか？が決められないのと同じで、役割には上下関係がないのが最近の流行りかなと思います。例：マネージャは役割でしか無いため上下関係ではない。ただし、マネージャとしての責任や求められる成果は大きくなりがちなので、給与面は優遇されているとか
責任：日本だと「責任」はひとつですが、海外の人と働いたときに、彼らにとって責任は、「Accountability」と「Responsibility」に分けられるようです。それぞれの違いは、「命令責任（Accountability）」と「実行責任（Responsibility）」と考えるとわかりやすいです。命令責任は命じたことへの責任なので、従来型マネージャの承認権限に近く、実行責任はそのままは最後までやり遂げる責任です（参考：アカウンタビリティとは「命令責任」である）。
グレード：階級制度です。大抵の場合、グレードが給与テーブルに紐づきます。
役職：職位がありがたがられる時代でもないので割愛。

評価における大きな軸となるのがスキルとパフォーマンスだと思います。

基本的に高いスキルの人は、高いパフォーマンスを出しやすいはずですが、パフォーマンスに直結しない仕事もあるので、そういったケースではうまくパフォーマンスにつなげるマネジメントが求められるように思います。

勉強会で発表した => 知り合いが増えて、自社に興味を持ってくれるようになり採用につながった（外での発表は基本的にブランディング、つまり採用になりがち）
開発に関わる総務の仕事 => 手続き系が多く一定以上のパフォーマンスが出にくいが、質問に対するリードタイムを計測するなど、定量化も可能なはず
会社全体での集まり運営 => 文化づくりのためには大切な作業だが、長期的な活動は短期的な評価がしにくく定性的になりがち。