【CTO・エンジニアマネージャーに聞いた】エンジニア組織で大切なのは「その会社らしさ」と「納得感」。エンジニア評価制度運用まとめ

Findy Teamsの石川(@HRBizDev1)です。

前回、企業の成長フェーズにおける5段階別エンジニア組織の課題と取組事例を書き、様々な方からの反響をいただきました。

今回は上場企業から創業初期のスタートアップまで、様々なフェーズの企業数十社のCTOやVPoEへヒアリングを重ねる中で感じた「エンジニアの評価制度を運用する上で大切なポイント」について書いてみました。

評価制度の運用を考えるにあたって、今回の記事が少しでもエンジニア組織運営の参考になりますと幸いです。

ちなみに Findy Teams では、そんな評価に関する課題も解決できるように絶賛、β版開発中です!

事前登録いただいた企業様へは、順次、無料でβ版を提供させていただきますので、登録いただけると嬉しいです! 早くご登録いただけた方から機能を優先的に公開してまいります!

1分でできる事前登録はこちら

はじめに

そもそも、エンジニアという職に限らず、人が人を正しく評価するというのは困難であるにも関わらず、何故評価するのでしょうか。

それは、ひとえに「会社として事業を成長をさせる為」ということに尽きると考えます。

多かれ少なかれ、事業成長の為に人は不可欠です。自社にとって必要な人材には辞めてもらわず、事業成長に寄与してほしいと思うのは当然です。

その為、必要な人材に対して、会社の目指す方向を理解してもらう為に評価制度を導入している・・・

つまり、評価制度とは「会社として、こういう人と一緒に頑張りたいと考えている」というメッセージを伝える為のツールのようなものではないでしょうか。

エンジニアの評価制度運用で出てくる2つの意見

Findy TeamsでCTOやVPoEの方々にヒアリングをしていて、エンジニアの評価制度に対する現場の声として多いのは、次の2つでした。

  1. 何をやったら評価されるのかわからない
  2. なぜそのような評価になったのか分からない

予想では「技術力が評価されない」といったエンジニア特有の悩みが多いのかと考えていましたが、それよりも一般的な人事制度における悩みと共通したものが多かったのが印象的です。

では、エンジニア向けの評価制度運用において、上記の問題が発生する背景に何があるのか。それぞれの視点で整理してみましょう。

1.『何をやったら評価されるのかわからない』問題が発生する背景

この問題が発生する背景には、「自社で必要なエンジニアとは、どうあるべきか」を定義出来ていないということが挙げられます。

「自社で必要なエンジニアとは、どうあるべきか」、ここが曖昧な状態のまま、既存の全社的な評価制度の延長線上で「どんな人を評価したいか」の前に「何を評価するか」が先に設計された場合に、この問題が発生しやすいようです。

特にエンジニアの場合は、前回の記事の変革期における評価で触れたように、受注件数や売上などの指標で成果を計測することが難しいが故に、評価者間でも基準がブレがちです。

では、具体的に「自社で必要なエンジニアとは、どうあるべきか」をどのように決めれば良いのでしょうか。

リリースのスピードが早い人、バグの発生頻度が低い人、OSS活動に意欲的な人など、CTOの価値観によって評価ポイントの項目とウエイトは異なるので、絶対的な正解はありません。裏返せば、「評価ポイントは各社自由」ということでもあります。

「何だそれ。全然参考にならない。」と感じる方もいるかもしれませんね。

しかしながら、自社と全く同じ状況の会社は存在しません。故に他社で上手くいった制度を転用したからといって、自社での制度運用が上手くいくとは限りません。だからこそ、”他社が”ではなく、”自社が”という主語で、時間をかけてでも考えるべきです。

『何をやったら評価されるのかわからない』を解決するために

ここでいくつか事例をご紹介します。

まず、クックパッド様の事例は有名ではないでしょうか。

クックパッド様では、「エンジニアのあるべき姿」を作られています。エンジニアのあるべき姿を6つの指針として


①ユーザ視点
②技術の使い方
③誰にも負けない分野
④他のエンジニアに貢献
⑤嘘ごまかし・妥協はナシ
⑥議論のための議論はしない


と定義されています。どの方向を向いたら良いか、とても分かりやすい指針だと思います。

また、GMOペパボCTOの栗林健太郎さんもおっしゃっていますが、GMOペパボでは全社的に「わたしたちが大切にしている3つのこと」というバリューが明文化されています。それをエンジニア視点で考えると、どのような具体例になるのか、全エンジニアからのアンケート結果をベースにとりまとめ、新たな評価制度の指標としたとのことです。

参考:ペパボのエンジニア評価制度をパワーアップした

別の考え方としては、及川 卓也さんの著書「ソフトウェアファースト」で紹介されていたボトムアップ型*で人材像を定義する方法もあります。ビジョンやバリューという上位概念から落とし込んでいくのは難易度が高い(抽象度が高くなりやすい)ので、色々試してみて、しっくりくる手段を選んでいただくのがよいかと思います。

参考:ボトムアップ型の人材像定義方法(ざっくり。詳細は是非書籍で)

エンジニア組織のメンバーを優秀だと思う順に全員で並べ、順位付けの理由を整理する→順位の比較を行い、順位付けの調整を行う→特徴量を抽出する。順位が高いメンバーの評価理由からは、組織が大事にしたいと思っているもの、こういうエンジニアになってほしいと思っているものが浮かび上がる。反対に順位の低いメンバーの評価理由からは、組織でふさわしくない行動例などが見えてくる。これらを整理すると、その組織らしい基準が出来上がる。

加えて、エンジニア人数が50人を超えるような企業様の場合は、今を評価するだけではなく、併せてキャリアパスについて、マネジメント以外のスペシャリストコースも含めて可視化しておくことで、より組織としての機能を高めることができそうです。

ただ、前回の記事で書いたとおり、企業の成長フェーズによって理想形は変化します。その為、求める人材像も、一度決めて終わりではなく、「今の理想ってこれでいいんだっけ?」と定期的に見直すことが必要がある点には注意が必要ですね。

Findy Teamsでは、「その会社らしさ」を決めていく上で、エンジニア組織内に潜在化している情報を取り出し、意思決定をサポートするようにしていきたいと考えています。

事前登録はこちら

2. 『なぜそのような評価になったのか分からない』問題が発生する背景

これは、「評価をきちんと伝えていないこと」よりも、「評価を伝えてはいるが『納得感』を得られていない」ということが起こっていると考えます。

CTOやVPoEの方にインタビューする中でも「『納得感』が得られていない」原因として多いのは、『1on1などで直近の動きに対する振り返りの頻度が少ない』ことだったりします。

振り返りの頻度が少ないほど、評価に対する納得感は低下していきます。エンジニアの場合、他職種に比べてこれまでに書いてきたようにやるべき事が状況に応じて変化しやすい傾向にあるため、振り返りの頻度と納得感の相関がより顕著です。

「なぜそうなったか」は、納得感を醸成するコミュニケーションを取ることが重要

不満が少ない企業様ほど、高い頻度(多くの場合は1週間に1回程度)でエンジニアマネージャー(CTO)とエンジニアで振り返りを行い、会社が目指す方向と本人が目指す方向のズレを早期発見・解消する取り組みをしていることが分かっています。

しかし、全てのメンバーの状況を丁寧に見きれるかというと、限界もあります。エンジニアマネージャーが、工数の大半を1on1やマネジメントに使い、疲弊してしまうことも少なくありません。本当はもっと開発したいのに、なかなか時間が割けないという声もありました。(解決策としてチームを分割する・新たにマネージャーを採用するなど、打てる手はありますが、労働集約的になってしまうので、このあたりはFindy Teamsで解決していきたいところです!)

評価のあとのタイミングで離職してしまうことを防ぐためにも定期的な1on1には時間をかけつつも、日々分報などでアウトプットを気が向いたときに確認しておくとよいかもしれません。

参考: Findyでの分報の活用について

また、振り返りの頻度ほどではありませんが、報酬に関しても納得感という意味では不満が上がりやすいようです。

提示される側もそうですが、評価者側としても昇給予算の中で適正金額を払いたいという想いはあるものの、そもそもの市場感が分かりづらい為に、ポジションに適した給与設定となっていないケースがあるようです。

ゆめみ様のように自己申告制にする、ソニックガーデン様のように一律化、あるいは、サイボウズ様にならい市場価値ベースにするなど、方法は一つではありません(とはいえ、全ての企業様が他社に習って同じように給与設定を運用するには難しい部分があると思います)。

このあたりは職種・ポジションによっても変わりますが、Findy や Findy Teamsとしてこれまで培った知見が活かせる部分ですので、こちらから気軽に相談していただければと思っています。市場対比で適正かどうか・競合優位性のある金額になっているかは相談にのらせていただきます!過去には、このような記事を書いていたりします。

ITエンジニアの年収をGitHub解析から予測可能に。OSSが年収アップにつながる時代へ。

最後に

本記事では、『何をやったら評価されるのかわからない』『なぜそのような評価になったのか分からない』の2点についてどう解決するかのポイントをまとめさせていただきました。

また、宣伝みたいになってしまいますが(宣伝です)、Findy Teamsではエンジニアのパフォーマンス最大化を支援することを目的とし、プロダクト開発を進めています。エンジニア組織の適切な意思決定を支援し、マネジメントする側もされる側も気持ちよく働ける世界を作っていくつもりです。

是非、この世界観に少しでも共感いただける場合は、是非ご登録ください(そして、たくさんフィードバックください!)。

1分でできる事前登録はこちら

事前登録いただいた企業へは無料でβ版を春先あたりから順次提供していきます。早めにご登録いただけたら Findy Teams として優先的に機能を提供させていただきたいと考えています!

以上、最後までお読みいただき、ありがとうございました!

次回の記事も、ご覧いただけると幸いです。

引き続き、Findy Teamsをよろしくお願いします。