スポンサーリンク

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

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

スポンサーリンク

大切なこと

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

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

用語集

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

スキルとパフォーマンス

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

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

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

スキル(能力)

スキルはドラクエでいうならばレベルでしょうか。レベル20にならないと遊び人から賢者に転職できなかったり、特定のレベルにならないと協力な呪文を覚えられないように、レベル(度合い)を満たしているかどうかで確認できます。

スキルに対して様々な視点を加えたのが、コアコンピテンシーでしょうか(参考:コンピテンシー評価とは? 必要性、メリット・デメリット、基準、項目、コンピテンシーモデルのつくり方、具体例について)。

スキルに関しては、異なる役割のスキルを比較できない点に注意が必要だと思います

たとえば、フロントエンドですばらしいUI/UXのアプリを組めるスキルと、サーバサイドですばらしい応答速度の処理を組めるスキルは比較できません。どちらもすごいんだけどね。同じく、営業とエンジニアを区別するのも不可能だと思います。

ただ、評価という軸に合わせるためには、これらを同じマトリクス状に表さざるを得ず、多少の矛盾はあれど、その役割の範囲でレベル感を作っていくことになるはずです。

基本的にスキルが身につけば身につくほど、高まれば高まるほど、評価は上がります。ただ、スペインの企業とやり取りするのに、ベンガル語学習を目標に入れられては困ります。よって、ある程度、パフォーマンスに連動するスキルマップを作るべきでしょう。

開発組織においては、技術スキルと、マネジメントスキルなど、多面的なスキルが求められるはずなのでそれぞれにレベルが必要になると思います。

たとえば、Scalaのスキルレベルが高いのと、他部署との調整力がありリリース日を厳守するスキルが高い場合、どちらもパフォーマンスへの材料として大切ですよね。

最後に、スキルは再現性が求められます。たまたまスキルが身についたようにみえたのでは再現性がありません。持続的にそのスキルを発揮できるかも確認しなければなりません。

パフォーマンス(成果)

パフォーマンスは成果です。成果はスキルとは違い、一時的なもの、季節的なもの、偶然なもの・・・がありえます。スキルが基本給であれば、パフォーマンスはボーナスでしょうか。

パフォーマンスの注意点は、その過程(プロセス)も重視したほうがいい点でしょう。

たとえば、すごい悪い社員がいて、同僚の成果をうばって勝ち得たパフォーマンスを、そのまま評価するのは不平等でしょう。協調型の組織で成果主義が嫌われる点も個々にあるように思います。

そういった点では、スキルもパフォーマンスも、権威的にならず、周囲からの賛同が得られるのが理想な評価なのでしょうね。

パフォーマンスは結果とも読み取れます。みんな大好きOKRの「KR(Key Result)」も主張な結果と訳せますし、ストレッチゴールという到底たどりつけない高い目標設定をみても、パフォーマンス集中型の手段だとおもいます。

グレード(階級制度)

どういった階段を作るかがポイントだと思います。

従来型の人材育成は、入社数年で基本を学び、ある程度の年数で仕事を任せ、働き盛りをすぎて定年・・・という流れだと思いますが、グレードもこれに合わせて作られている感じがします。たとえば、スキルの度合いをグレードに置き換えるとこうなります。

  • 新入社員:スキル面を中心に仕事の基本を学ぶレベル。
  • 若手: 指示をこなせるレベル。
  • 中堅: 助けは多少必要だが、ひとりでなんとかやりきれるレベル。
  • リーダー:複数人で効率よく仕事を動かしてパフォーマンスを高められるレベル。
  • マネージャ: 人を育成し、成果を出すチームや組織を作れるレベル

影響範囲で置き換えることもできます。

  • 個人レベルの影響範囲
  • チームレベルの影響範囲
  • 組織レベルの影響範囲(部とか課とか)
  • 会社を超えた影響範囲
  • 社会レベルの影響範囲

まとめ

こういったものさしを整理すれば、それなりの評価制度ができるように思います。

ただ、なんでもマトリクスに当てはまるわけではないので、どこまで柔軟性をもたせるか? どうやって本人や周囲の納得感を持つか? が結局大切になる気がします。

タイトルとURLをコピーしました