Blog -

「アウトプット」「セルフコントロール」「スキル」の3軸で考える ギブリーのエンジニア評価制度


評価制度は大きな転換点を迎えている

1990年代から普及が進んできた評価制度は、半年間ないしは1年間の期間中の目標達成状況を観察・測定するMBO(management by objectives 目標管理)を土台とし、360度評価やコンピテンシー評価などの新しいスパイスを加えながらも四半世紀近くはその姿を大きく変えずに来ました。
しかし、2015年頃から米国企業を中心に評価制度の在り方を根本から見直す動きが顕著に現れています。
先行事例として挙げられ研究されている企業としてAdobe社、GE社の名前を様々なメディアで目にしますが、どちらにも共通することは「半年間・1年間といった長期スパンで評価サイクルを回すことを止め、短期間で評価とフィードバックをきめ細かく実施する」という点です。
評価フィードバックの頻度を短期間(リアルタイム)にすることは社員の行動変容の適時性を高めるため、評価制度の本来の目的(事業目標を達成するために社員のパフォーマンスを最大化する)に沿った望ましい変化と言えるでしょう。
このような評価制度を抜本的に見直す動きは今後日本でも大きな潮流となっていくはずです。
「給与額を決めるために後付でやっている」と揶揄されるような形式的な評価制度を捨て、企業の事業目標達成/社員のパフォーマンス向上/社員の意欲向上/社員の成長をドライブする本質的な制度を作り上げる好機が到来しているのです。

今こそがエンジニアの評価制度を抜本的に見直すチャンス

評価制度の中でも、特にエンジニアの評価の難しさに悩んでいる企業は多いのではないでしょうか。
エンジニアには、営業のように売上や利益といった客観的な指標があるわけではありません。受託開発のモデルであれば利益額を指標とすることも出来ますが、自社プロダクトの場合は売上・利益はビジネスサイドに左右される面が否めず、そもそも新規プロダクト開発の場合には売上・利益自体がまだ存在しません。プロジェクトが計画通りに進みコストが予算内に収まっているかだけで評価するのもまた妥当性に欠けます。
スキルを評価しようとしても、主観的な自己評価以上の客観性を持たせることは難しい。何らかの客観評価のしくみを作ったとしても、技術の陳腐化のサイクルが早い昨今では評価対象とするスキルを最新のものに更新するだけでも多大な手間がかかります。
ウォーターフォール型の長期間のプロジェクトに身を置いているのであれば半年間の目標も立てられるかもしれませんが、アジャイル等の短期サイクルでプロジェクトを回している組織では半年後の成果目標を立てること自体がナンセンスかもしれません。
Adobe社やGE社が先鞭をつけた評価制度の見直しの流れは、上記のような課題に陥りがちなエンジニア評価制度を抜本的に作り変える良い機会にもなるでしょう。
ここで、一つの事例として弊社ギブリーのエンジニア評価の考え方をご紹介したいと思います。

半年間の評価サイクルを廃止し、2週間ごとにアウトプットを評価していく

ギブリーは、「エンジニアが活躍できる世界をつくる」ことを事業として取り組んでいます。
エンジニアが適切な教育機会を得ること、適切に評価されること、キャリアアップにつながるチャンスが得られることを目指し、track、CODEPREPといったサービスを展開しています。
そういった事業を行っている企業だからこそ、ギブリーはギブリーで働くエンジニアにとって最高の職場でなければならない、という信念を持っています。
また、ギブリーのエンジニアメンバーの約半数は外国籍のため、価値観や文化的背景も多様です。チームがうまく機能するために、MTGからドキュメントまで全てを英語で行う、多様な価値観を受容し合う、リモートワークやフレックス制度を導入するなど様々な取り組みを行っていました。
このような前提があったため、ギブリーのエンジニアにとってベストな評価制度を模索する際は日本的な常識にとらわれない自由な発想で考えることを意識しました。
そして、評価制度検討タスクのメンバーの根底にあった想いは、『メンバーの実務を正しく評価したい』というシンプルなものでした。
『メンバーの実務を正しく評価する』ことを考えた時、ビジネス上の定量目標のないエンジニアチームからすると半年間や1年間の従来型の評価サイクルは実態に合わず、評価はおろか納得性の高い目標設定すらも困難です。
そこで、ギブリーが出した答えは、半年区切りの評価を止め、『2週間という短いサイクルでアウトプットを評価する』ことです。
元々ギブリーではスクラム開発を行っており、2週間のスプリント単位でプロジェクトを運営していました。
その2週間という単位で、細かなアウトプットの積み重ねを常に評価していくことにより、普段のアジャイルプロセスの繰り返しそのものを評価することができます(評価をするためのタスク等をつくらず、とにかく実務に集中してもらうことができる)。
また、細かなイテレーション・評価サイクルは自ずと個々人での定期的な振り返りとスピーディな改善を求めることになるため、個の成長の最大化にも寄与するだろうとも考えました。

アウトプット、セルフコントロール、スキルの3軸で考える

上記の2週間単位でのアウトプット評価がギブリーのエンジニア評価制度の根幹になりますが、これだけでは制度として完全ではありませんでした。
アウトプット評価でそのエンジニアの発揮能力を測ることはできますが、アウトプットに直接的に結びつかない保有能力を測ることが難しく、また何をアウトプットするかは担当プロダクトの開発状況にも大きく左右されます。
また、ギブリーでは企業としてのビジョンからブレークダウンされた5つの行動指針を定めており、その行動指針の実践度は、他の職種と同じように評価をしたいという想いがありました。
そこで、私達はギブリーエンジニアの評価軸を、「アウトプット」「マインド/セルフコントロール」「スキル」の3つとすることにしました。

【 ギブリーエンジニアの3つの評価軸 】

① アウトプット(あるいはアイディア) :2週間のスプリント単位での評価
② マインド/セルフコントロール    :半年毎の評価
③ スキル               :半年毎の評価

②マインド/セルフコントロールとは、言葉のとおり職務への意欲や自己管理の程度です。チーム内で共有されている行動指針・フィロソフィーを基準として評価します。

③スキルとは、個々の技術レベルと市場価値です。スキルレベル・保有スキルの市場性から評価を行います。
これらの3軸をそれぞれx軸、y軸、z軸に据え、各個人の評価をプロットして出来上がる直方体の「容積の大きさ」がそのエンジニアのギブリー内での価値を表すイメージです。

市場価値を加味したスキル評価

一般的にエンジニアのスキル評価を行う場合、自社で作ったスキルチェック指標を元に、テクニカルスキル・コンセプチュアルスキル・ヒューマンスキル・ビジネススキルなどを定量化する手法が一般的かと思います。
この手法はギブリーでも勿論行っています。
「スキルマップ」と社内では呼んでいますが、ギブリーで使用する技術要素を網羅した一覧を用いてスキル項目毎の習熟度チェックを行います。
ギブリーでは、このスキルレベルチェックに加えて「市場価値」の観点を取り入れています。
新しい技術が日夜生み出されるITの世界では、スキルレベルの高低だけではそのエンジニアの力量を判断することは難しく、そのスキルの持つ市場価値を加味しないことには納得感の高いスキル評価は難しいと考えたためです。
市場価値を見るための取り組みとして、エンジニアがもう一度ギブリーに転職活動をするかのように自身のスキルを評価者に対してアピールする場も設けるようにしており、この取組は本人が最新のスキルをキャッチアップする意欲向上にも繋がっています。

まとめ

弊社ギブリーのエンジニア評価の考え方をご紹介いたしましたが、いかがでしたでしょうか。
2週間のサイクルで細かくアウトプットを評価することで、エンジニアの実務成果を正しく評価することができ、さらに半年毎のマインド/セルフコントロール評価とスキル評価を客観的に実施することで、そのエンジニアの持つ市場価値や定性的な側面も加味することができるようになりました。
評価制度に正解はありません。自社の社員数やビジネスの特性によっても適した制度は変わってきます。
だからこそ、「他社の真似ではうまくいかない」とよく言われますが、弊社事例がご参考になれば幸いです。

Writer >

track 運営事務局
track 運営事務局
track(トラック)とは、エンジニアのスキル可視化を目的としたプログラミングスキルチェックツールです。プログラミングテストの作成から採点、評価までをワンストップで実施できます。年間数千人を選考する大規模企業の新卒採用から、ベンチャーの早期インターン採用、中途即戦力採用においてミスマッチのない人材採用と、人事やマネージャー、選考に携わる現場エンジニア/CTOの工数削減に寄与します。また、自社のエンジニアの社内評価まであらゆるスキルチェックニーズにお応えします。