戦略人事的な人事制度の作り方①　～等級制度～

今の会社で、結構なパワーをかけて人事制度を作り直している。
ので、そのときに考えたことをここに整理しておこうと思う。

本来は、人材マネジメントポリシーの作り方から説明していくのが王道だが、うちの会社のカラーが出過ぎるので、そこはスキップ。
本題の人事制度設計の話からさせてください。
基本的な考える順番ごとにまとめていくので、初めて考える人などはこれに沿って考えてもらえれば、ある程度かたちになるのではないかと思っています。
わからないことがあればコメントください。

１．等級基軸

等級基軸は、人事制度設計でまず最初に検討する項目です。
これによって、どのような切り口で社員の序列を決めるか、評価するか、報酬を払うかが大きく左右します。
そのため、人事制度を策定するときは、まずこの項目を経営陣と合意することが大切になります。
現在では主に5つの等級基軸があると言われています。
長くなりそうなので、メリット・デメリットを一覧にしてみました。

で、結局何が一番よく採用されるの？
ということで、だいたいのシェア率をまとめてみました。
情報はいろんなところから集めたので、だいたいの参考程度で。

つまり日本では、「職能等級」が一番メジャーということになります。
当社でも検討するときに、職能等級にするか、役割等級にするか悩みました。
※職務等級は、やってほしい業務をすべて文章にするので、契約に重きを置くアメリカなどでは主流だが、日本では向かないなぁと思うことが多く、早めに候補から除外。

当社はエンジニア集団なので、どんな技術を持っていたら偉いのか、明確に定義したほうが頑張りやすいのではないか、ということが「職能等級」側の意見でした。
ただこの変化が激しい時代、その中でももっとも変化するIT業界において「職能」を定義してしまうリスクが勝りました。

例えば当社でメインで使っている言語はjavaなので、javaでの開発経験が何年以上で、どの程度複雑なシステムが作れるか、と定義した場合。
時代の流れでももうjavaは使われなくなり、やっぱりScalaだよね、となったらそれまでjavaの技術力のみで上位等級にいた人は、都落ちです。
これが起こり得るのがIT業界。

ということで、役割等級が当社の基軸になりました。
役割等級のデメリットは曖昧になりやすいことです。個人的にはこれは日本の良き文化でもあるが、悪しき文化でもあると思っていて、できる限りこの曖昧さをなくしたいという思いがありました。
そこで少しばかし、工夫を加えることにしました。
（検討の後半に出てくるので、ここでは触れませんが・・）

この基軸を決めることで、横にどう切っていくかが決まります。
次は縦にどのように切るか。

２．職掌・職種

等級定義をどのように書き分けるかを決めます。
同じようにまとめて、そのポジションの役割が書けるのであれば、それはまとめてしまうことをオススメします。
細かく分ければ分けるほど、違いが不明瞭になりやすくなったり、評価や報酬制度をそれごとに変えると、平仄が取りにくくなります。

例えばうちの会社で分けるか否かをもめたのは、現場で開発するエンジニアと、技術戦略室的な社内の案件を横断的にサポートするエンジニアの職種を分けるべきか、という議論です。
求められるミッションは明らかに違います。
現場のエンジニアは顧客の満足度やPJTの収益を要求されますが、技術戦略室はノウハウをどのように蓄積するか、そのPJTに最適な技術はなにかなどのアドバイスを要求されます。

だから、分けないと等級定義は書けない・・・と思われ、最初は分けて設計を進めていました。
ところが実際に等級定義を書いてみると、違うところもあるけど、似ている部分もあり、思ったより差が出ない。
そこで遡って、同じ職種にくくれないかという検討をやり直しました。

結果、役割のレベルは一緒だが、組織で求められるミッションが違うという表現にすることで落ち着きました。

どちらの役割も２等級は、定型業務を指示なしでできること。
現場エンジニアのミッションとこれをかけ合わせると、設計書に基づいて開発ができること等と読み替えられます。
また技術戦略室からすると、各PJTで使用した言語やフレームワークをインタビューして社内ポータルサイトに記事を書くとなります。
やってることは違えど、レベル感は同じくらい。
ということで、この２つの職種は統一することができました。

私はこのようにできる限りまとめて、しっかり説明ができるギリギリまでシンプルにするのが一番伝わりやすいと思っています。

長くなったので今日はここまでにしますが、こんなシンプルで伝わりやすい人事制度の作り方を引き続き綴っていきたいと思います。