こんにちは、採用担当の松本です！
今回は、CTOの深川が技術ブログで公開した記事を引用し、
弊社で2022年10月に実施した評価基準刷新の取り組みとそこから得られた学び、今後の方針をご紹介します。Job Expectation と呼ばれる、実際に弊社で使われているエンジニアのグレード評価基準も公開しておりますので、ぜひご覧ください！

【参考】
・技術ブログ掲載の全文はこちら
・深川のCTOインタビューはこちら

目次

- 制度変更前の課題

- 評価基準の変更

- 制度変更後の効果

- 今後の方針

- エンジニアグレード評価基準を公開した理由

- おわりに

こんにちは。LegalOn TechnologiesでCTOを務めている深川といいます。

エンジニア組織の運営は人数が増えていくにつれて加速度的に難易度があがります。その中でも、エンジニアリングマネージャーにとって常に頭を悩ませるものが人事評価制度です。特に、評価基準については、公正かつ納得感があり、それでいて属人化しない評価基準を作り上げるのは至難の業です。

弊社も例に漏れずエンジニアのグレード評価基準に課題を感じていたため、2022年10月にエンジニアグレード評価基準の刷新を行いました。そこから約10か月が経過し、徐々に刷新の効果や課題が見えてきました。

制度変更前の課題

2022年9月までの弊社のエンジニア評価基準は「社内の中での相対的な能力基準」をベースに4つ程度の評価軸から作られていました。
しかしながら、開発組織の人数ももうすぐ100名に届く、という規模感になり、徐々に以下のような課題を感じるようになりました。

■ 技術力は高いのだが、うまく成果に結びついていない人材と、一方でずば抜けた技術力があるわけではないが、高い成果を安定して出している人材がいる。会社としては後者の人材を評価したいと考えているが、現行の評価制度では前者の人材の方が評価が高くなってしまう。

■ 個人としては成果を残しているが、他部署/他職種とのコミュニケーション面やチームワークに課題がある人材がいたとして、そういう人材を厚遇すると、個人として成果を出していれば良いという人材を会社が求めているように映ってしまう。現行の評価制度ではそういった人材に対して適切な評価を下せない。

■ Individual Contributor と Engineering Manager では期待する能力・成果・行動は異なるが、現行の評価制度は創業初期に最も必要だったICとしての評価軸が中心になっている。そのため、Engineering Managerの評価が評価者によって大きく異なってしまう可能性がある。

■ 評価の際には、時にはネガティブフィードバックを伝える必要があるが、現行の評価軸には含まれないものも多く、フィードバックがマネージャーの主観によるものになってしまう。自身の主観でフィードバックすることはマネージャーにとっては精神的負荷になることもあり、また、よしんば評価はできても組織の改善はマネージャーの力量に大きく依存してしまうことになる。

当時マネージャーだった私は、こういった課題に対処していくうちに、自然と評価について考える機会が増えてきました。そして、これらの課題は評価基準をうまく設定することによって、解決することができるのではないか？評価基準は、会社から「こういう人材であって欲しい」という願いを従業員に伝えるツールとして活用できるのではないか？そして、従業員にとっても、より具体的に成長やキャリアアップを目指すための指針になるのではないか？と考えるようになりました。

評価基準の変更

ここまでに説明したような課題の他にも、「報酬レンジが相場と乖離しており、採用競合に負けるケースが多い」「ハイクラスの人材を評価できるテーブルが存在しない」といった課題もあったため、評価基準改定より半年ほど前の2022年の春に評価制度を一新するプロジェクトが立ち上がりました。
その中で評価基準についても、以下の方針で見直すことになりました。

上記の方針から実際に基準を作る際には、他社様のラダーを大いに参考にさせていただきました。特に参考にさせていただいたものを謝辞も兼ねて以下に挙げさせていただきます。

• メルカリ: Engineering Ladder
• CircleCI: CircleCI Engineering Competency Matrix
• Dropbox: Dropbox Engineering Career Framework

そうやって出来上がったエンジニアのグレード評価基準がこちらです。弊社では Job Expectation と呼ばれています。
https://docs.google.com/spreadsheets/d/1jad5ybRc5XqIPMRyz9eHAwCL6rUlFJ5NCakqoO_Uu08/edit?usp=sharing
2022年10月から利用開始されたものなので、まだ評価に使われたのは1回だけですが、実際にこのJob Expectationを利用して評価が行われています。

制度変更後の効果

Job Expectationを使って実際に私も評価を行ってみましたが、目に見える成果や振る舞いと比較しての評価であるため、以前の目に見えない能力ベースのものよりも評価はしやすくなったように感じています。
その他にも、以下などの点で当初期待していた効果を概ね発揮しているのではないかと考えています。

■ 評価観点が増え、より属人性の低い評価が可能になった

■ 採用面接の際の判断軸とすることで、カルチャーギャップの抑制に繋がる

■ 採用候補者に当社が求めているエンジニア像をより明確に伝える事ができる

■ マネージャーから被評価者にネガティブフィードバックを伝える際の精神的な負荷が軽減された

今後の方針

とはいえ、課題がないわけではありません。
理想としては、Job Expectationを評価のためだけでなく、日々の活動の中で理想のエンジニア像を示す指針として活用してほしい、という思いがありますが、現時点ではまだそこまで根付いているわけではありません。
また、能力ベースから成果・振る舞いベースに変えたことで、逆に採用や育成では使いにくくなった面も一部あります。
加えて、成果基準の記載が抽象的すぎるという課題もあります。何ができればどのグレード相当の成果なのか、という点は現状のJob Expectationではなかなかわかりづらく、属人化してしまっています。
これらの課題については以下のような対策を今後講じていく予定です。

その他にも、あった方が良いがまだ作成できていないグレード・ポジションに対するExpectationの定義や、運用を通じて観点や表現のアップデートは継続的に続けていく必要があります。

エンジニアグレード評価基準を公開した理由

最後に、Job Expectationをなぜ公開したかをお話しします。

まず、上述の「制度変更後の効果」でお伝えしたように、運用する中でこのグレード評価基準は社内だけでなく、社外の人にも公開することで弊社のことをもっと知ってもらえるのではないかと思うようになりました。採用候補者は、弊社のことをもっと知れることで安心してジョインできますし、弊社としても事業成果を出すための大きなネガティブ要因であるカルチャーギャップを払拭できることには大きなメリットがあります。
また、逆説的ですが、社外に公開することで間接的に社内のエンジニアもJob Expectationを目にする機会が増えるかもしれないと考えました。意外に思えますが、外に出ることで中の人間が意識するようになる、というのは往々にしてあることかなと思います。それを通じて、もっと社内に浸透できると良いなと考えました。
あとは、これはとても私の個人的な思いなのですが、メルカリさんのように自社カルチャーを公開し、自社だけでなく業界全体に貢献するような姿を見てすごくかっこいいなと思っています。弊社も Job Expectation を公開しておけば、今回、弊社がメルカリさんのEngineering Ladderを参考にさせていただいたように、もしかしたら他社さんが弊社のJob Expectationを参考にしていただけるかもしれません。そうやって、巡り巡って業界の発展に貢献できれば、それはすごくかっこいいなと思います。LegalOn Technologiesはそういう会社になりたいと私は願っています。

以上の理由から、今回 Job Expectation を公開する運びになりました。

おわりに

この記事では、弊社の開発組織で行なった評価基準の変更についてご紹介しました。
評価制度は正解も終わりもない難しいトピックですが、会社の願いと従業員の願いをすり合わせるための重要かつ実用的なツールでもあると私は考えています。
弊社自身もまだまだ試行錯誤を続けている最中ではありますが、もし評価基準の設計について迷われている方がいましたら、この記事が何かの参考になれば幸いです。

メンバー募集！

弊社では、この記事で取り上げたJob Expectationの改善をはじめとしたエンジニア組織の改善を推進するEngineering Coordinatorというポジションを募集しています。
- Engineering Coordinator
- 開発の求人一覧
その他にも、さまざまなポジションがオープンされていますのでご興味があれば是非ご応募ください！