ブルベースの堀内です。
エンジニアチームのマネージャーを担当しております。
ブルベース株式会社は2020年3月に人材事業、受託開発事業、自社サービスの新規開発・運用保守を担う会社として発足しました。発足に伴いエンジニアの評価制度を考える機会をいただいたものの、非常に頭を悩ませました。通常業務をこなしつつ、評価制度を検討したため、半年もの時間がかかりました。
皆様の参考になればと思い、どのような思いで検討したかを述べさせていただきます。
エンジニア評価制度の必要性と方向性
エンジニアの評価制度を策定するにあたり、なぜ必要なのかを改めて考えてみることにしました。評価制度に従って、役職や給与が決定することは当然のことです。ただ、それだけではありません。この評価制度は「会社がどのようなエンジニアになって欲しいか」というメッセージと考えるようにしました。
現在、所属するエンジニアのみで誰がどのランクに相当するかを議論していても、**世間に通用するエンジニアは育ちません。**新たに評価制度を作成するこのタイミングではあえて他社のエンジニア、有名なエンジニア、この人と働きたいと思ったエンジニアを頭に浮かべて、策定することにしました。
どのような観点でエンジニアを評価するか
私がエンジニアとして働くようになった頃は、プログラマからはじまり、徐々に仕様策定などの上流工程を扱うエンジニアとなり、その後、マネジメントを担うのが通例でした。しかし、マネジメントの適正がないにも関わらず、経年だけで昇進した結果、本人も周りも苦労している光景を見てきました。
職務のミスマッチは個人・チーム・会社へも悪影響を及ぼします。プログラミングが得意な人にはプログラミングを担当させた方がアウトプットの質も量も最大化されます。このように、個々のエンジニアが得意領域を担当し、最大限のValueを発揮していただくのがコストパフォーマンスが良いのは明らかです。よって、キャリアの多様性を与えることが組織の成長に繋がると考えました。
しかし、それをどのように評価制度に組み込むかにまた頭を悩ませる訳です。どのような議論がなされたか、その一部を紹介します。（なお、本記事ではマネージャーについては除外して説明します）
1.スキルの高さをどう組み込むか（スペシャリストの評価）
技術力の高いエンジニアと低いエンジニアでは、当然高い方が理想的です。ただし、プログラミング言語、担当する領域によって、希少性、求められるスキル、給与の相場が異なります。ここは市場に合わせ、担当するプログラミング言語によって、給与の最低額と最大額を設定すべきと考えました。
2.周囲への影響をどう組み込むか（関与と影響の輪）
スペシャリストはその分野ごとに評価することを決めましたが、単にスキルの高さのみで評価すると不都合が生じます。例えば、全く同じスキルならば、周囲とコミュニケーションを積極的に取り、メンバーのモチベーションアップや教育にも熱心なエンジニアの方が評価されるべきです。
このようにスキル以外の組織貢献度（=行動評価）も取り入れるべきだという声があって当然のことです。
3.スキルの幅をどう組み込むか（ゼネラリストの評価）
一方でそこまで特定分野で秀でたスキルがなくても、インフラの設定からサーバーサイドの実装、フロント側の実装（Webサイト、iOSやAndroidのアプリケーションなど）など、幅広く担当でき、1人でサービスを形にすることができるエンジニアが評価されないのは懸念が残ります。少ないリソースかつ、リーン的アプローチでサービスをローンチできるエンジニアはスタートアップのような段階では重宝するからです。
スキルの高さのみで評価しない要素も取り入れるべきで、ここがまさに多様性を評価することに繋がります。
4.事業評価を組み込むか
上述において、スキルの高さと幅、また関与と影響の輪を考慮して評価する方向性でまとまりつつも、**「売上が好調なサービスを牽引するエンジニア」と「スタートアップでまだ市場規模が小さいサービスを担当するエンジニア」**をどう評価するかという疑問も挙がります。
売上のみで言えば、売上が不調よりも好調の方が良いのは明らかです。ただ、これから市場が伸びるかもしれない、未知の領域にチャレンジするエンジニアが軽視されるのは残念なことです。
また、担当するサービスを本人が選べることは少なく、会社の指示でアサインされることの方が多いでしょう。売上をベースに評価を決定してしまうと、誰もが「売上が好調なサービスに異動したい」と願い出るのは容易に想像が付きます。
よって、売上は会社にとって非常に重要な要素ですが、エンジニアを評価する際に組み込むのは今回は控えることにしました。もちろん、エンジニアが重要な要素を担っているかもしれませんが、企画・営業が優秀であれば、エンジニアのスキル関係なく、売上が伸びる可能性は否定できません。
会社の決定に依存しない評価制度を目指して
上述の【4.事業評価を組み込むか】において、会社の指示で担当するサービスが決定し、そのサービスによって、使用するプログラミング言語、ミドルウェアが限定されるケースもあります。スキルの高さと幅で評価するとはいえ、特定のスキル、ミドルウェアなどに触れる機会を会社が十分に与えることができず、全てを「自己学習で補え」と言うには、若干厳しい部分があります。
そこで評価制度と共に教育制度についても検討することになりました。学習機会を与え、自立化を目指します。興味を持ったエンジニアが率先してプロトタイプを作成し、そこから得た知見を周囲に波及させ、組織全体のレベルを上げていく構図をイメージしています。
リンカーンの言葉を借りるのであれば、**【エンジニアによるエンジニアのための評価制度】**であるべきです。エンジニアのスキルを上げるために、必要な制度や環境を整備するには何が必要かを半年間検討し、交渉を続けてきました。
形骸化させず、状況を見ながら改善していく
半年間、検討を重ねた結果、【スペシャリスト】【ゼネラリスト】【マネジメント】など、合計3つのキャリアを準備し、それぞれで求められるスキルの高さ・幅、また行動評価によって加点要素のある評価制度を策定しました。キャリアごとにスキルマップを定義し、キャリアチェンジ可能な自由度をもたせております。
冒頭で評価制度は「会社がどのようなエンジニアになって欲しいか」というメッセージと述べました。評価制度を見れば、その企業がエンジニアに対してどのようなスタンスであるかが垣間見れます。面接時に「何か質問ありますか？」と聞かれた際、エンジニアの評価制度を伺ってみることで、入社後のミスマッチを防ぐ有効な手段となるのではないでしょうか。
今回策定したものは、どの会社に当てはまるものではなく、会社の状況、つまり、立ち上げ時・成長期・安定期などで異なると考えます。よって、今回の決定が恒久的なものではないことを前提として、まずは走り出し、不都合が生じたら改めて検討していくことで合意しました。
おわりに
エンジニアの評価制度を策定するという経験をしたことで、自分自身も今後、どのようなキャリアを描いていくか、5年後、10年後にどのようになっていたいか、改めて考える良い機会となりました。
この半年間の苦労を共有することで、誰か1人でも楽になる人がいたら幸せです。また、このような情報発信の機会をいただいたデータラーニングギルドの村上代表に感謝を申し上げます。
最後までお読みいただき、ありがとうございました。
最後に弊社の教育に対する考え方を象徴する記事として、下記リンクを紹介します。
https://www.wantedly.com/companies/bulletgroup/post_articles/293935