エンジニアリングマネージャーが等級制度を作るときの7つの注意点
heyの上杉です。
この記事は、Engineering Manager Advent Calendar 2021（その1） の20日目のものです。
等級制度は、一般にグレードなどと呼ばれていたりするものです。社内で制度を作っていこうという流れがあり、エンジニア職における等級の設計に携わらせて頂いたので、その知見を書いていこうと思います。
ついでにこれを見てねという記事です。
Engineering Ladders (日本語)
背景
社員数が増加の一途を辿り、2021年度の頭から制度を作り始めることとなりました。私はエンジニアの立場から、等級制度全体の設計に提言したり、エンジニアポジションにおける等級制度の設計と、開発担当部署との合意形成などを担当しました。
制度作りは一人で成し遂げられることではありません。様々な方々の知恵を借り、社内的なモメンタムを作り、合意を得ながらようやく完成したものです。そして完成一年を待たずして、これから改訂が始まります。
等級制度とは何か
「等級制度」とは、従業員が保有する能力や職務、役割に応じて区分し、序列化する制度を指します。
ビジネス職だと等級表はこんな感じになります。
なぜエンジニアリングマネージャーが等級制度作りに参加するのか
私は何故だか評価制度作る機会に恵まれています。今回で3回目です。なぜエンジニア(リングマネージャー)の私が等級制度作りに参加させてもらっているのか、これには3つの理由があると考えています。
1点目。個人の感覚ですが、エンジニアは職人なので、職人は職人に評価されたいというのがあります。事業に貢献することで評価されるのは重要な観点ですが、他方、技術力によって評価してほしいというのは、公平な評価を考える上で正当な要求だと思います。大工に例えるならば、カンナは一人前に使えた方がいいし、完成する建物をイメージして作ることができた方が良い。そういった能力がなければ、建物(事業)を正しく作り上げることはできないでしょう。そしてそれができたかどうかは、熟練の大工が、新人の大工を見てあげた方が良いことは説明の必要はないかと思います。
2点目。1点目の帰結として、実際に現場でエンジニアを評価や査定を行っていくのは私たちエンジニアリングマネージャーということになります。運用を行う私たちの声が等級制度に反映されていない制度では、運用は難しいと考えます。
3点目。日本の等級制度の歴史的経緯として、技術者の等級制度は高度専門職人材という名の下、そもそも一般職とは別に扱われ、賃金体系も別という設計が多かったようです。後述しますが、ジョブ型と呼ばれる等級制度だと各職種ごとに等級が作られています。
このような背景から、経験を積んだエンジニアリングマネージャーなどが等級制度作りやその改定に参加していくことは自然なことと感じます。
なぜ等級制度が必要なのか
等級制度は評価制度や賃金制度の中心になる制度です。また採用や育成観点でも利用されることになります。大きな企業に所属したことがあるエンジニアの方なら、等級制度は導入されているでしょうから想像はつきやすいのではないかと思います。
ビジネススクールの教科書的な話にはなりますが、一般に公平であることは社員の満足度を高める結果になります。
あらかじめ定められた基準を作り、所属する全員が公平に期待する役割や賃金が決定する。
文字だけで読むとすごく怖い感じがします。しかし対を考えると感覚を得やすいかと思います。「”偉い人たち”が、なんとなく役割や賃金を決める」よりマシなのは理解できます。
人間は基準があると(見える化されて理解ができると)安心感を得られる傾向があります。
一方で「人間は工業製品ではない」的なアートな意見もあるかもしれません。しかし数百人から数千人が同じ方向を向いて働いていくときに、査定など生活に関わる非常に重要なことが、”偉い人たち”の恣意性と、曖昧さに支配されている状況に、全員が耐えれるかと言ったら、そうでもないだろうなと思います。
また、今まで曖昧にされていたものが明瞭にされることに不安を感じる方もいるかと思います。いわゆる現状維持バイアスと言えるかもしれません。「今うまくいっているのだから良いのではないか？」
確かにそれは正しい部分もあるかと思います。人数規模が数十人の企業には等級制度は重い制度です。しかし視点を変えると、グローバルで成功している企業(Big Tech)や、日本のメガベンチャー、有名ベンチャーで等級制度が存在しない企業はありません。
所属企業が将来どうなりたいか、どうありたいかで導入は検討すべきです。
利用ケース
どう役に立つかは、どういう利用ケースがあるのかを想像すると考えやすいです。
以下の図は、等級制度が与える各制度や施策への影響になります。
採用
例えば面接で利用される場合、希望年収やポジションを鑑み、求める職務能力や役割の基準とします。
具体的には、面接の質問事項の観点としての利用や、回答などが期待する水準に到達しているかを確認し、採用や不採用の根拠とします。
加えて、採用エージェントの方に、どのような方を採用したいか説明する際にも非常に有効です。感覚値ですが、エージェントの方は募集要項だけでは情報量として実は少ないようです。明確な社内基準を知りたがる方が多いです。彼ら/彼女らとしても、ちゃんと採用率を高めたいでしょうし、明確な基準があることはお互いにとってwin-winなものです。
育成
社内でキャリアの段階が明確になるので、キャリアビジョンを描きやすくなります。どういった職種で、次の段階でどういった能力が必要になるのかが明確にできるので、方向性やステップが理解しやすく、能力開発の支援をしやすくなります。一般により高いグレードに求められるのは、より抽象度が高い問題を取り扱えるような能力や、組織的な行動を促す能力だったりします。
評価制度
等級制度によって、期待役割が明確になるので、個人目標の規模感を明確にしやすくなり、よりリーズナブルな目標を立てられるようになります。同一職種、同一等級内での目標の水準が明確にあるため、公平な目標を設定でき、よって公平に目標に対する評価を実施することが可能になります。個人目標設定の難易度が見える化されて、評価者、被評価者間でのコミュニケーションがしやすくなります。
賃金制度
上記の求められる能力発揮を見える化され、公開されている状態で、評価が行われるため、公平な評価に基づいて昇給などを判断することができます。各等級内での給与レンジを決めることができるため、発揮能力と給与の結びつきを明確にできます。
等級制度の種類
等級制度にはいくつか種類があります。トレンドもあります。私が知っている有名なところで言うと
職能資格制度(メンバーシップ型でよく用いられる制度)
職務等級制度(ジョブ型でよく用いられる制度)
役割等級制度(ミッショングレード型でよく用いられる制度)
なんていうのがあります。あと年功資格制度という年功序列を制度化したものもありますね。
上記リストのカッコ内の○○型は、言葉の定義が世の中的に解釈の幅があります。また、例えば「メンバーシップ型であっても職務等級制度を入れること」などがあるので、正確な記述にはなっていません。
ここでは説明は割愛しますが、どの制度も一長一短ありますし、完璧なものはありません。加えて、どの制度を全社で導入したとしても、エンジニアは先に説明した高度専門職人材として扱われることが多く、別ラインの等級制度が設定されることが多いです。
等級制度を作るときの7つの注意点
1.現状をよく知る
社内の誰がどういう理由で現在活躍されているかは大きなヒントになります。また、グレード制度が現状の運用と乖離がありすぎると、導入のための調整が大きくなりすぎて、導入自体が難しくなります。
2.将来どういう組織にしたいかを考える
現状だけを重視するのではなくて、将来を見据えた設計にしておく必要があります。どういう企業にしたいのか？その疑問の一つの答えが等級制度です。メンバーの社内でのキャリアパスのイメージになるので十分に考えていく必要があります。
3.様々な企業の事例を見る
門外不出のものであったりするので、他社の情報を得ること自体がなかなか難しいです。まずは書籍などで調査を進めることをお勧めします。
大枠としての制度の違いを理解した後に、個別の企業の事例を知るとわかりやすいです。googleなど海外の事例の方がインターネットで取得しやすいです。国内の企業の制度の方が日本の文化とのマッチングや、国内企業から入社されるマネージャーの方が多いことを考えると利用しやすいです。しかし前述したように、情報は手に入れにくいように感じます。
たまたま私は数社国内ベンチャーを経験していたため、制度を理解できていてラッキーでした。
4.シンプルにする
この手の制度は運用が肝です。というか運用がなければ制度は機能しません。凝った制度を作ったとしても、運用者が理解できなければ運用できません。故にできる限りシンプルな方がいいです。そもそも観点や水準を決めること自体が非常に複雑な行いです。アイディアが複雑なものはシンプルで覆い隠すことができたとしても、複雑になります。できる限り削ぎ落としてシンプルから始めましょう。
5.等級制度を運用したことある人に話を聞く
前述したように、運用は非常に重要です。過去に他の会社で、個人目標の設定や評価などを行なってきた方が社内にいるならお話を聞き、アドバイスをもらいましょう。すべてのアドバイスを聞き入れる必要はないですが、自分以外の観点で見てみることには大きな価値があります。アドバイスを聴きながら、運用イメージをしっかりと固めていきましょう。合理的な設計で、かつ運用者が利用しやすい状態を目指しましょう。
6.合意をとる
どんなに自分が最高だと思う等級制度でも、全員とは言わずとも、多数の方が合意できるものでなければ運用はできません。少なくとも会社のリーダー陣に納得してもらえるまで粘り強く合意形成を続ける必要があります。当然ですがディスカションが必要です。自分主体で作ったもののにはエゴが多分に含まれています。エゴが悪なのではなく、アイディアを曖昧なまま制度化すると運用者が企図を理解できず、大抵は良くないことが起こります。観点や基準を明確にし、意図を説明できるように、十分に準備しておきましょう。こういった他者とのやりとりの中で制度は洗練されていきます。曖昧だったものを明確に、複雑だったところをシンプルに。良い落とし所を見つけて一歩一歩進めましょう。
7.改善し続ける
最高の等級制度なんて存在しません。改善し続けましょう。
市況や業績やなど、外部要因や内部要因変化の影響もある中、みんなが気持ちよく働いていくための制度です。故に改善が必要ですし、時には0からの再定義も必要かもしれません。デグレーションすることもあるでしょう。一部の従業員は制度自体に不満を持つこともありますし、それによって退職ということもあるかもしれません。
それでも心を尽くし、思いを尽くし、知力を尽くして、一歩一歩前に進むしかありません。
等級制度を作るときに参考にした情報など
私が等級制度作りに参加するにあたって、主に参考にした書籍は以下です。
エンジニアやエンジニアリングマネージャーの能力の観点や水準以上に、等級制度とは何かということへの理解が重要と感じました。一般的にどういった種類があって、どの様なメリットデメリットがあるのか理解する必要があります。インターネット上にポロポロと落ちている散文的な情報も理解の助けにはなりますが、制度設計に関しては体系的な知識が必須です。ぜひ書籍の力を借りてみてください。
またここには記していませんが、他社の等級制度の資料は参考になりました。
エンジニア等級制度
よくできています。かなり参考にさせていただきました。
本サイトは英語でしたので、私が独自にforkして翻訳したものが以下になります。(本家にマージのリクエストを出しています)
まとめ
リサーチをしっかりしましょう。
できる限り広く深く知識を身につけて、大枠では既存の選択肢の中から選ぶような形が理想ではないでしょうか。巨人の肩を借りましょう。
自社の独自色は表現やディテールに宿らせましょう。
企業の将来、メンバーのキャリアに関わるものなので、非常に重要な仕事です。独自のアイディアで作った「僕の考えた最強の評価制度」は突飛で目立つかもしれませんがただそれだけです。エンジニアとして役に立つ制度を作れるように尽力することが大事です。
この記事が気に入ったらサポートをしてみませんか？