エンジニア評価制度をゼロから作り直して運用した話

1. はじめに

過去に、上場を目指す過程にあった組織規模200名弱のスタートアップで、エンジニア組織の評価制度を0から作り直して運用した話を共有しようと思います。

どんな組織でもある程度の規模になると、エンジニアに限らず評価制度の見直しが必要になるのではないかと感じております。

実際にやってみて良かった点、うまくいかなかった点があるので参考になれば幸いです。

2. 改革のきっかけ

きっかけはいくつかあったのですが、私がCTOになった当時、明確な評価基準が存在しておらず、評価に透明性・正当性がない状態だったことが一番の動機でした。

個人の能力による評価ではなく、昔から在籍している（経営者が苦労した時代一緒にがんばってくれた）であったり、評価者に気に入られているメンバーの評価が高く、中途で入った優秀なメンバーの評価が正当にできていないという典型的な課題を抱えていました。

スタートアップとして上場を目指す中で、ある程度の規模になっても評価制度が整っていない場合、上記のような構造になりがちで、それにより組織体制・チーム編成時に歪み(優秀な人材を適切な評価で適切なポジションに配置できない問題)が生じ、結果として優秀な人材を失ってしまう危険性が高まります。
そのような組織では人数を増やし組織をグロースさせる事は非常に難しくなると思われます。

※評価制度に限った話ではありませんが、組織規模の拡大に耐えられる構造を整えられていない場合、人が入っては抜け…を繰り返す構造を保つのが精一杯になりがちです

その状況を打破し「優秀なエンジニアを正しく評価すべく」評価制度の改革を推進しました。その後、会社の上場に伴って人数が増えて行きましたが、その変化にも耐えられる仕組みを構築できたと思います。

3. 優秀なエンジニアとは？

先ほど『優秀なエンジニアを正当に評価したい』と書きましたが、『優秀』とは一体どんな状態を指すでしょうか？

「優秀」を定義をするためには、組織にとって重要なエンジニア像を明確にした上で、それを軸に「優秀さ」とは何かを考えていく必要があると考えました。
※この「優秀さ」は組織フェーズによって変化していくものですので、評価制度は定期的にメンテナンスしていく必要があると感じています

そこで、まずはじめに『うちの会社の優秀な人材』を定義をし、その内容を経営層とすり合わせ、現場のエンジニアメンバーにも共有しブラッシュアップを重ねるといった作業を行いました。
※組織のバリュー（価値観・行動指針）と絡めて方針を決めましょう

大前提、評価において大事なのは経営層も現場メンバーも納得感のある制度にする事だと私は思っています。

納得感を醸成するには、関係者に対する適切な説明の実施が不可欠で、会社としての方向性を定め、CTOとしてエンジニアメンバーに対してそれらの考えを打ち出すことで『うちの会社の優秀なエンジニア』の定義を浸透させていきました。

4. 評価制度策定のステップ

細かく書くと長文になってしまうので、おおまかに実施した事を記載します。

まずはじめに、会社内でのエンジニアのキャリアパスを定義しました。
新入社員も毎年採用していたので、新米エンジニアから始まり、エンジニア（一人前）、専門職(スペシャリスト・マネージャー)といったグレード分けを定義し、次にそれぞれのクラスで必要な能力を洗い出し評価項目の大枠を作りました。

当時はスペシャリストやマネージャーといった区分けもなかったことから、ハイレベルなエンジニアのキャリアパスを会社として明示することで、優秀なエンジニアが自分の特性に合ったゴールを描き、正当に評価される環境だと感じてもらえるよう意識しました。

キャリアパスを定義した後は、評価制度の骨組みとして、評価すべき大項目を以下の通り4つ定義しました。

• 当時定義した評価の大項目

  • 開発スキル

  • 業務遂行スキル

  • コミュニケーションスキル

  • マネジメントスキル

上記大項目の中に詳細な評価項目を複数設定しました。
例）大項目「業務遂行スキル」の中には、スケジュール管理や課題発見・問題解決能力に関係する詳細評価項目があり、「コミュニケーションスキル」の中には、協調性を測るための評価項目などがそれぞれ存在するような状態

各大項目内の詳細評価項目毎に5段階で求められる能力を具体的に定め、評価者と本人で認識ズレが起きない状態を目指しました（※主観で点数が変わるような表現は避けるように注意しました）

また、各グレードに等級をいくつか用意し、それぞれ何点〜何点ならどのグレードのどの等級かがわかる仕組みに最終的に落とし込みます。

これだけだと、ただの形式がしっかりした評価制度で終わってしまうので、会社として定義した優秀なエンジニア像に合致するスキルに重みをつけるという作業を実施していきます。

評価項目一つ一つは一般的な内容が多く、組織特有の内容は少ないのですが、それら評価項目に重み付けを行うことにより、「うちの会社の優秀な人材」の人物像と評価の実態が一致するように調整を行なっていきます。

また、重み付けをすることで、各グレード（新人エンジニア、エンジニア、専門職）毎で必要とされるスキルが異なる設計を実現しました。
専門職グレード（スペシャリスト・マネージャー）では、それぞれ必要とされる能力が違うので、それに合わせた評価が実現できるように調整するのも
非常に重要です。

この間、何度も質疑応答の場を設け、エンジニアメンバーから匿名での質問を受け付け、全ての質問に回答するような事をしながら推進したのを覚えています。

上記のような工程を経て、新たな評価制度を策定し運用まで漕ぎ着けるわけですが、納得感ある形で社内に浸透させ、きちんと運用していくには、それ相応のパワーと時間が必要となりますので、気合を入れて取り組んでいきましょう💪

5. 評価制度を運用して良かった点・うまくいかなかった点

それでは実際に上記制度を運用して良かった点、うまくいかなかった点をそれぞれ振り返ってみます。

• 良かった点

  • 各グレード毎に重要視される能力を明確化できた（評価の透明性・納得感向上）

  • 組織内でのキャリアパスを明確に定義でき、目標設定に役立てることができた（短期・長期での目標形成）

  • エンジニアの待遇を是正し、適切なポジションに優秀な人材を配置できた（評価されすぎていた人の待遇を下げ、評価されるべき人の待遇を上げることができた）

  • 各グレード・等級毎に具体的にどんなスキルを伸ばして欲しいか、各人の強み・課題が明確になり、1on1や評価面談時の納得感が増した

• うまくいかなかった点

  • 評価制度運用に非常に時間が掛かってしまう

  • 評価の透明性を上げたことにより、自身の評価を過度に気にした動きをする人が生まれた（等級・グレードを上げ給与をあげることだけを目的とするような動き）

  • チームリーダーのメンバー評価に対するマインドを統一するのが難しかった（評価のフィードバックの質を担保することが困難だった）

課題だった部分は解消されたので、評価制度改革を実施して良かったのですが、評価の透明性を上げ、正しく評価しようとすればするほど、運用コストが跳ね上がっていったので、その点は最初からもう少し考慮しておけば運用フローを改善できたかな・・・というのは大きな反省点でした（当時のエンジニアリーダーの人たちには苦労させてしまって申し訳なかったなと反省 & 感謝してます。。）

細かな問題は運用しながら改善していけば良いとは思いますので、自社の評価制度に課題を持っている方がいれば、課題を解消すべく第一歩を踏み出すことを強くお勧めします。

6. さいごに

組織規模やレベルに応じて、適切な落とし所を見つけ評価制度を策定しブラッシュアップしていくことが重要であると考えています。

エンジニアが数名しかいないような規模だったり、評価に相応のコストを払えないような組織状態である場合は、上記のような制度作りは不要だと感じています（費用対効果が薄い & 別の方法で納得感上げれるはず）

しかしながら、「うちの会社の優秀な人材」を定義しておくことはとても重要で、どんなフェーズの組織にもお勧めできるかなと思っています。
上記を定義することで、必要とする人材・評価すべき人材を明確化できる & 採用時にも役立つはずです。

数名しかいない規模であっても、資金調達を機に組織を拡大させる計画をしていたりする場合には、事前に評価制度の策定を検討をしておいた方が良い可能性はあります。前述の通り、優秀な人材の流出は組織にとってマイナスでしかありません。

色々と端折ってしまいましたが、もしエンジニア評価制度の策定に関してお困りの企業様がいましたら、お力になれるかもしれないのでご相談ください。

株式会社Shells
代表取締役 川上