LegalOn Technologies のエンジニアグレード評価基準を公開します

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

もし私がどういう人なのか気になる方がいましたら、私のことは以下の弊社オープン社内報でも記載していますので、よかったらこちらの記事をご覧いただければと思います。

https://now.legalontech.jp/n/n36b23e19f7b0

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

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

この記事では、弊社で2022年10月に実施した評価基準刷新の取り組みとそこから得られた学び、今後の方針をご紹介します。そして、得られた学びの結果として、Job Expectation と呼ばれる、実際に弊社で使われているエンジニアのグレード評価基準を公開します。

評価って何？

評価基準の話をする前に、そもそも人事評価とはなんなのかを確認してみましょう。

とりあえずChatGPTに聞いてみます。

それらしい回答が返ってきました。

人事評価制度に対する説明部分を抜粋すると、以下の通りです。

人事評価制度とは、企業が従業員の業績や能力、態度などを評価し、給与調整や昇進、役職配分などを行うための制度のことを指します。この制度は、業績向上や人材育成のための重要なツールとなっており、公平な評価を通じて従業員のモチベーション向上や職場の生産性向上を目指します。

企業側の人的リソース管理や人事評価から派生した人事考課の観点の他、従業員側の観点として、モチベーション向上や人材育成・成長といった点も含まれるようです。

ChatGPTの言うことを盲信するのもあまり良くないので、できるだけ信頼できる一次情報を探してみると、人事院の人事評価制度に関するサイトが見つかりました。人事院とは、国家公務員法に基づき、人事行政に関する公正の確保及び国家公務員の利益の保護等に関する事務をつかさどる中立・第三者機関として設けられた行政機関のことです。

人事院の人事評価の説明には以下の記載があります。

人事評価は、「任用、給与、分限その他の人事管理の基礎とするために、職員がその職務を遂行するに当たり発揮した能力及び挙げた業績を把握した上で行われる勤務成績の評価」（国家公務員法第18条の２第１項）とされています。人事評価制度は、能力・実績に基づく人事管理を進めて行く上での基礎となる重要なツールであるとともに、人材育成の意義を有するものでもあります。

引用: 人事院, 人事評価制度より抜粋 https://www.jinji.go.jp/ichiran/ichiran_jinjihyouka.html

人事院は国家公務員の人事管理を担当する第三者・専門機関であるため、ややエンジニアの評価とは異なる点があるかもしれませんが、本質的には大きな相違はなさそうです。

ChatGPTの回答と同じように人事院でも、組織側と職員側の両方の観点で、人事評価制度の意義が語られています。

これらをまとめると、企業における人事評価制度とは、主に以下を目的としたものと考えることができそうです。

• 企業側は、従業員の業績・能力等を適切に評価し、報酬やポジションの決定、人材育成を通じて業績を向上する
• 従業員側は、評価結果やフィードバックを通じて、役職や報酬、スキルやモチベーションを向上する

また、ChatGPTの回答、人事院が従う国家公務員法（第72条の2）の双方において、「公正な評価」の実施について明記されており、公正性の確保が重要だと伺えます。

すなわち、会社と従業員の間の期待値をできる限り疑義がない状態ですり合わせられ、それが評価者によってブレないことが評価基準の設定において重要な点だと考えられます。

制度変更前の課題

ここまで一般の人事評価制度について、ChatGPTや人事院の事例と併せて確認、考察してきました。

ここからは、弊社がなぜ評価基準を変更したかについて説明します。

2022年9月までの弊社のエンジニア評価基準は「社内の中での相対的な能力基準」をベースに4つ程度の評価軸から作られていました。

例えば「専門性」という評価軸においては「特定領域において社内で第一人者と認めうる優れた専門性を有すること」のようなものです。これ自体はどちらかというとよくあるもので、決して悪いものではないと思います。ましてや、この評価基準が作られたのは創業して数年という頃で、プロダクトが売れないといつ会社が潰れるかわからないような状況下です。そんな状況下では、綺麗な評価制度を作る暇があったら1つでもプロダクトの機能を増やすことに情熱を注ぐべきで、むしろ創業してほどないタイミングで作られたにしては悪くなかったのではないかと思います。

しかしながら、開発組織の人数ももうすぐ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で期待される振る舞いが実際に入社して期待できそうか？という観点で、質問や判断を行うことが増えてきました。結果として、そもそもあってはいけないものなので実感値があるわけではありませんが、カルチャーギャップの抑制に一役買っているのではないでしょうか。

あとは、採用という文脈だと、「御社ではどういうエンジニアを求めていますか？」という質問は採用でよく聞かれる質問TOP5に入りますが、そのときにJob Expectationを見せて「こういうエンジニアを求めています！」と言えるのも、策定当初は予想していなかったありがたいユースケースです。

その他にも、フィードバックの際に、Job Expectation をもとにして期待値を発揮できているか、できていない場合はこの点をもっと発揮して欲しい、というコミュニケーションがしやすくようになったのも大きな利点と感じています。私自身はCTOという立場なのでミドルマネージャーと比べると人事において相当裁量を持っていますが、なんだかんだ個人の主観でフィードバックするのと、会社の期待値として定められている中でフィードバックするのとでは精神的な負荷が違います。

そういうわけで、概ね当初に期待した効果を発揮しているのではないかと考えています。

今後の方針

とはいえ、課題がないわけではありません。

理想としては、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

https://herp.careers/v1/legalforce/CotqlKMH7IHE

開発の求人一覧

https://herp.careers/v1/legalforce/requisition-groups/d2e157cc-120b-4ade-8879-0326c32127bd