エンジニアの給与水準の上昇傾向が続く一方で、「エンジニアの評価は難しい」という声も多くの企業から聞こえてくる。

そもそも開発業務の成果を短期間で測ることは難しい上に、特にスタートアップ企業では事業環境の変化も激しいことから、エンジニアの評価制度の設計・運用は難易度が高いと言われている。

そこで、一例としてエンジニアの評価制度の具体を公開してくださったのが、株式会社ミラティブで取締役 CTOを担う横手 良太さんだ。

▼同社のエンジニア用給与テーブル（2022年時点）

同社では2022年に評価制度をアップデートし、現在は「General（エンジニア以外）」と「Engineer」の二つに運用を分けて、半期ごとの評価会議で給与を決定しているという。

横手さんが管掌する開発チーム（Engineer）においては「プロダクト開発や技術コミュニティへ全力を傾けられる」「エンジニアの成長を支援する」「社内と社外の両面に対してフェアである」ことを重視して、エンジニアの評価制度をアップデート。

その一番の特徴は「被評価者が今転職をするとしたら、いくらのオファーをもらえる人材か」という市場評価の観点から給与を決定し、等級は後から付いてくるという思考の順序にある。

今回は横手さんに、ミラティブ社の開発チームにおける評価制度の設計と運用についてお話を伺った。

エンジニアを除くGeneralの評価制度は、全職業で統一しシンプルに

弊社は2018年に創業し、スマホで誰でも簡単にゲーム配信ができるライブ配信プラットフォーム「Mirrativ（ミラティブ）」を提供しています。

私は2018年7月に1人目のUnityエンジニアとして入社して、2021年4月からCTOを担っています。現在、全体では111名の社員が在籍（2023年1月時点）していますが、私はそのうち30名弱が所属するエンジニア組織を管掌しています。

私のnote内にも記載していますが、今回は開発チームの評価制度についてより詳しくご紹介できればと思います。

まず、現在の評価制度に至るまでの大枠の流れをお伝えすると、私が入社した2018年はまだ全体で10名ほどの組織だったため、評価制度自体がありませんでした。

2019年に初めて等級を示した評価制度が設けられましたが、スタートアップは短いスパンで事業環境が変化していくことから、細かい内容は決めずに非常にミニマムな制度運用でした。その後、100名以上の規模になった2022年に制度内容をアップデートした形です。

現在の制度の全体像をお伝えすると、「General（エンジニア以外）」と「Engineer」の大きく二つに運用を分けて、半期ごとの評価会議で報酬を決定しています。

▼同社の給与制度の全体像（2022年時点）

それぞれ1〜6の等級が設けられていますが、Generalの評価制度においては、デザイナー、セールス、コーポレート…といった職種ごとに評価項目を設定するのではなく、全職種共通の内容になっています。

例えば「この等級のデザイナーなら○○を満たしているべきである」といった職種ごとの基準を細かく設けている企業も多いと思いますが、ひと言でデザイナーと言っても実際は複数の役割を幅広く担っている人もいて、相当に評価軸がぶれるんですよね。

なので、ミラティブのGeneralの評価制度は「とにかくシンプルにしている」というのが特徴です。これは職種ごとの差がないということではなく、大枠としてはシンプルにしておき、職種ごとに運用を柔軟にする意図があります。

▼Generalの給与テーブルは職種問わず統一

また、評価の中には、「わかりあおうとし続ける」という行動理念や4つの行動指針に沿った評価軸も設けられています。

エンジニアの評価は「転職活動した場合の想定オファー額」から決定

次に開発チームにフォーカスすると、「Mirrativ」の開発では高いスキルと共にユーザーやプロダクトに真摯に向き合うマインドが求められるので、その双方を備えていることがチームの特徴です。

元々は全社とエンジニアの評価制度は分かれていませんでしたが、私自身は「特にソフトウェアエンジニアは、短期目標を掲げてそれを達成したかで評価をするのは、必ずしも適切ではないだろう」と考えていました。

というのも、エンジニアの場合は半年などの短期スパンではなく、1年後や2年後の事業にどのような影響を及ぼしたかという長期視点での貢献度で評価されることが非常に大切なので、MBO的な評価制度では時間軸が全く合っていないんですよね。

さらに、ソフトウェアエンジニアの業界は平均勤続年数が3〜5年ほどで流動性が高く、年収相場の変動も激しいので、細かい評価基準を設けても状況に合わせて調整し続ける必要が出てきます。

そう考えると、単純に「今この人はどのぐらいの市場価値だろうか、世の中にどれぐらい評価されるだろうか」という社外に軸足を置いた評価制度にした方がフィットするだろうと判断しました。そういった背景から、Generalと分けてエンジニア用の評価制度を設けた形です。

そして、弊社のエンジニアの評価制度の特徴としては、「先に等級があって給与が決まるのではなく、給与があって等級が決まる」という思考の順序にあります。一般的にはこの逆の順序で運用するケースが多いのではないでしょうか。

具体的には、半期ごとの評価会議で「対象メンバーが転職活動をした場合に提示されるであろう想定オファー額」を話し合って、先に給与額を決めています。その際には複数のマネージャーからリファレンスを取りながら、給与額としての最尤値​​を導き出している形です。

仮に現状の給与額が600万円のメンバーがいるとして、その人のプロダクトや組織への貢献度とスキルの成長度を長期的な視点で加味した結果、その人が今転職活動を始めたら700万円のオファーを受けるだろうと判断したら、必然的に適切な給与と等級に引き上げるというイメージですね。

異なる専門領域の給与相場を把握し続けるための「二つの工夫」

この制度自体は非常にシンプルなのですが、評価者がエンジニアとしての実務や採用に携わっていて、業界の給与相場を常に把握できていることが運用における絶対条件です。

また、評価者自身の専門領域とは異なるメンバーの評価を担当することもあるので、他の専門領域の給与相場と求めるスキルレベルを適切に把握できるように二つの工夫をしています。

一つ目は、採用面接において、候補者の志望領域とは異なる専門性を持つエンジニアに面接官を担ってもらうということです。例えば、iOSエンジニア志望の候補者に対して、Unityエンジニアが面接官として出るようなイメージですね。

毎回ではありませんが、そうすることで自分とは異なる専門領域の給与相場を把握することができるので、自ずと認識がすり合ってきます。

二つ目は、半期評価のタイミングで「このメンバーについてどう評価しますか」と、専門領域の異なるマネージャーからもフィードバックをもらうことです。マネージャーは管掌しないグループの社員の給与額を知らないので、明確な数字を言い合うわけではなく表現は工夫していますが、こういったやり取りの中で評価の基準も合ってきています。

実際にこの運用をしてみて、エンジニア同士は基本的にお互いの実力を分かっているので、評価基準が大きくずれることはないと感じていますね。

そして、下図がエンジニア用の給与テーブルです。Generalと同様に1〜6の等級に分かれていますが、転職活動した場合の想定オファー額から半期の給与を決定するという思想から、それぞれの等級の中身は厳格には定義していません。

大雑把な目安としてお伝えすると、等級1は新卒、等級2は第2新卒、等級3はリーダーや一部マネージャー、等級4はトッププレイヤーが多く、マネージャーや部長を担う人たちもいます。等級5は経営に関わるメンバーかそれと同等のインフルエンスを出せるコントリビューター、等級6は経営の中枢を担うメンバーといったイメージです。

この目安があるだけで、今のフェーズの組織に対しては、これ以上に細かく内容を詰めても、あまり何も生み出さないかなと思っています。

近年、多くの企業ではキャリアの選択肢として、マネジメントとスペシャリストの二つの道を設ける形式が増えているように思いますが、弊社ではそういった分け方もしていません。

というのも、私の経験則で「イケてるエンジニアは両方ともやっている」ことが多いと感じているので、どちらかのキャリアを選択することにすごく違和感を持っていて。なので、そこはあえて分けずにミニマムな設計にしている形ですね。

そういった意味では、当社の場合、エンジニア評価における等級自体の意味が薄くなっている側面もあるにはありますが、他の職種の役員がエンジニアの評価内容を見ても基準が分からず議論しづらいので、一つの目安として等級も置いています、というくらいの温度感です。

目標設定は成長角度を上げるため。その達成度は評価に直結しない

昨今のエンジニア業界は給与水準の変動が激しいですが、このような制度運用をしていると、中途入社の社員と既存社員との年収に大きく差が出るということも起きにくくなります。

また、社会の給与水準にあわせるため、相対的に既存メンバーの年収も上がりやすい傾向が出ますが、エンジニアの人材不足による機会損失の方が影響度としては大きいので、多少水準が上がっても気にしていません。

そして、開発チームでの目標設定については、半期ごとにマネージャーとメンバーで「この半期でここまで目指そう」という項目を三つ、四つほど決めて、毎月1on1を実施しながら伴走しています。

例えば、あるiOSエンジニアの目標としては、「所属するフィーチャーチームのKPIを改善できる機能を作る」といったプロダクト開発への貢献観点と、「リファクタリングを進める」といったiOSエンジニアチームに対する貢献観点、そして社内外への技術発信や共有の貢献観点で設定するイメージです。

ただし、そもそも弊社のサービスは外部影響を受けやすく、短期スパンで実行すべき内容が変化しやすいので、半年前に決めた目標を達成したかどうかにこだわりすぎることには、あまり意味がないと考えています。

また、こういう理由もあって先ほどお伝えしたように「社外を軸にした評価制度」にしていて、この目標の達成度が評価に直結するわけでもありません。

あくまでも、本人が最もパフォーマンスを発揮して、最も成長するために最適な目標を置くということが重要になります。

例えば、「テックブログを書くこと」を目標に設定してそれを達成したとしても、明示的な評価に直結しませんが、そのアクションによってセルフブランディングできれば社外で評価されるので、結果的に社内でも評価される思想が制度の根底にあります。

開発メンバー全員がCTOを経験しているような組織を目指したい

現在のエンジニア組織の運営としては、エンジニアグループを4〜5名ずつの小グループに分けてコミュニケーションパスを制限することで、密に連携するような構造にしています。

また、ソフトウェアデリバリーのパフォーマンスを示すFour Keysに、デプロイ頻度の概念がありますが、組織もこれと同様と考えていて。1〜2ヶ月に1度くらいの高頻度でグループメンバーを組み替えることで柔軟な組織を作っています。

メンバーやグループを構成する際は、3〜5年後の成長観点でそれぞれのメンバーにどういう良い変化を与えられているかという点を特に意識しますね。

こういった工夫もあり、現在は一つのプロダクトに対してエンジニア組織全体が一枚岩のように動けていると感じています。しかし、今後事業が拡大して社員数が200名に増えたり新規事業を始めるような場合には、思い切った体制変更をしないといけないとは思っています。

その頃には、専門性の異なるエンジニア間のコミュニケーションが増えるケースが多くなり、今の評価制度のままでは継続できなくなるので、キャリブレーションの仕組みや360度フィードバックなどをどのように入れ込んでいくかという工夫が必要になってくると想定しています。

また、私個人の展望としては、CTOやVPoE、取締役といった役割をメンバー間で積極的に交代していきたいですね。というのも、おそらく今のエンジニア組織は、私の得意な面と苦手な面をそのまま反映していると感じているからです。

そのため、私はプレイヤーとして開発を担って、その後またCTOに戻ってくるような形で、組織全体でぐるぐると役割を回していくのが良いのではないかなと思っています。

もちろんメンバーには得意なところを伸ばしてほしいのですが、食わず嫌いはせずに様々なポジションに挑戦してもらって、社内にCTO経験者が増えていくと組織としては相当強くなるんじゃないかなと考えています。

私の理想は、社内のエンジニア全員が一度はCTOを経験できるようにすることです。別の会社へ転職したメンバーがCTOを担っているという状態に持っていけたら最高ですね！（了）