エンジニアの評価と給与とグレードと部屋とYシャツと私
こんにちは、HRBrain VPoE川田です。
部屋とYシャツと私の「飲みすぎて帰っても 3日酔いまでは許すけど」って良い歌詞ですよね。許して欲しいです。
もうこれ以上部屋とYシャツと私の話は出てきません、悪しからず。
さて、本日はEngineering Manager Advent Calendar 2020の記事です。
エンジニアの評価と給与とグレードの話をします。
想定読者は、もちろんエンジニアリングマネージャーの仲間たちです。
ちなみに今回の内容は「これが俺の考えた最強の制度だ！」と言うつもりは全くなく、みなさんと同じようにずっと悩み続けている中で今現時点での考え方をスナップショット的に記したものなので、数ある考え方のうちの1つと捉えていただけたら嬉しいです。
この記事から「こうした方がより良いのでは？」等、議論が生まれてくれればなお嬉しいです。
エンジニアの給与決めるの難しい問題
いきなりですが、給与決めるの難しくないですか？
めちゃくちゃ儲かる会社にいるとか、温泉のように地下から現金が湧き出したなんてことがあればそんなに苦労することはないかもしれません。
実際は様々な制約の中で、市場価値という幻想に振り回されながら、ある程度納得できる落とし所を見出してるのではないでしょうか。
また、エンジニアは新しく価値を生み出す部署にいる人もいれば、保守している人、研究している人、物事をうまく回す人、効率を上げる人、様々いるので更に難易度が高いです。
ではどうやってエンジニアの給与を考えれば良いのでしょうか。
エンジニアの給与の考え方
そもそも給与って何なんでしょうか。
生活するために必要なもの、頑張ったご褒美、天下の回り物、様々な考え方があると思いますが、私は当社内で事業価値を生み出す能力を1次元に投影した数値と定義することにしました。
成果ではなく能力を用いたのは、成果自体を直接比較することは不可能だと考えたからです。ある機能をリリースした成果と、研究で得られた成果を直接比較することはなかなか難しいです。お金で換算することができれば可能かもしれませんが、様々な仮定を必要とするため納得されづらい指標になってしまいます。
また、前提としてこの数値は絶対値ではなく、社内で相対的に扱われます。会社がめちゃくちゃ儲かっているのであれば相対の数値にしたがって全員の給与が底上げされますし、逆に厳しい事業ドメインで勝負している会社であれば全員の給与は他社に比べて低くなります。そういった点で、市場価値というのは幻想だと私は考えています。
どの役割であれ、事業価値につながる仕事をしているはずです。分かりやすさに差はありますが、保守も事業的に意味があるからやっているし、研究も長期的に事業価値を生むから早い段階で投資しています。こういった様々な事業価値を生み出す能力を、何かしらの方法で1次元に投影する必要があります。
ということで、給与は事業価値を生み出す能力を表現した1次元の数値であることから、給与を決めるためには事業価値を生み出す能力をどう表現するか？を考えれば良さそうです(本記事で固定給のみを扱い、賞与や株式報酬は今回のスコープ外とします)。
事業価値を生み出す能力とは
では、事業価値を生み出す能力はどう定義すれば良いのでしょうか。ここを考えるにあたり、エンジニアリング組織論への招待を参考にしました。
まず、そもそもエンジニアリングとは何か。それは「実現」していくことであると書かれていました。
そして、「実現」していくということは、ものごとがはじまったときの曖昧な状態から、終わりの明確な状態まで持っていくことであり、「曖昧さ」を減らし「具体性・明確さ」を増やす行為だと定義されていました。
実際のプロジェクトを考えると、はじめはモヤモヤとした構想があるだけで、プロジェクトメンバーも仕様もアーキテクチャもリリース時期も何も決まっていません。その後徐々に何かが決まっていき、最終的には全てが具体的になるので、納得感があります。
ということは、事業価値を生み出す能力は、「曖昧さ」を「具体性・明確さ」に変換する能力と言い換えることができそうです。
更に、本書では「曖昧さ」を分解して説明されていました。詳しくは本を読んでいただければと思うのですが、以下で簡単に説明します。
まず、曖昧さ=不確実性の全体像を示したのが上の図です。最終的に頭に入れるべき3つの不確実性に下線を引いています。以下でそれぞれ説明します。
不確実性は、大きく分けて他人のことは分からないという通信不確実性と、未来のことは分からない環境不確実性の2つに分類することができます。
プロジェクトの初期構想段階を考えると分かりやすいと思います。発案者のアイデアを最初に聞いたときは、なんとなく構想は理解できるけど発案者がどこまで考えているのかは相当深堀りして聞かないと理解することができません。思い込みでプロジェクトを進めることで、後半になって「そうじゃないんだけど」とどんでん返しが起こるかもしれません。これは他人のことが分からない通信不確実性に当たります。
また、やろうとしていることが実は顧客のニーズを満たしておらず、頑張って作りきったとしても全く流行らないかもしれません。これは未来のことは分からない環境不確実性に当たります。
またそれぞれは更に分解することができ、特に環境不確実性は、目的不確実性と方法不確実性に分類することができます。
これも先程の例を挙げると、作りきったとしても全く流行らないかもしれないというのは、何を作れば顧客に受け入れられるのかわからない、目的不確実性に当たります。また、どのようなアーキテクチャを採用すると開発スピードを落とさずにチームがスケールするかが分からないというのも目的不確実性に当たると私は考えています。
また、作っている途中でアーキテクチャの破綻が見つかるかもしれないとか、作りきって動かしてみるとあとからパフォーマンスの問題が発生するかもしれないという問題があります。これは、やってみないと、どのように作っていくかわからないといった方法不確実性に当たります。
ということで、事業価値を生み出すということは「実現」することであり、それは「曖昧さ」を減らし「具体性・明確さ」を増やすことであり、それは通信不確実性・目的不確実性・方法不確実性の3つの不確実性を削減することである、と言うことができます。つまり、
事業価値を生み出す能力 = 通信不確実性・目的不確実性・方法不確実性を削減できる能力
であると言えます。先程の給与の考え方のところで書いた「事業価値を生み出す能力を1次元に投影した数値」と照らし合わせると、
給与 = 通信不確実性・目的不確実性・方法不確実性を削減できる能力を1次元に投影した数値
ということになります。では、どのようにして通信不確実性・目的不確実性・方法不確実性を削減できる能力を1次元に投影したら良いのでしょうか？
グレードを利用する
不確実性を削減できる能力と給与を1:1に明確に定義できるようにすると、ある問題が発生します。それは、不確実性を削減できる能力が他者に知れることで、給与が容易に推定できるということです。
給与を公開している会社もありますが、弊社は現時点では公開する予定はありません。そのため、1つクッションを挟むことにしました。グレードを利用します。
- 不確実性を削減できる能力をグレードにマッピングする
- グレードに給与レンジを設定する
ことで、簡単に給与を推定はさせることなく、能力と給与をある程度連動させることができそうです。
ある時点での能力をグレードに変換し、それを元に給与を決めることができました。次は、各人の能力をどう上げていくかという点を考えなければいけません。
目標・評価について考える
ここまでの流れを考えると、目標と評価について見るべきポイントが絞られてきます。それは、
新しい能力と、その能力がどのグレードに当てはまるかだけを考える
ということです。「今期はこういう成果を出す(出しました)」という分かりやすくて目立つ事象を目標として設定したり評価するということが度々ありますが、成果そのものを評価の対象としてはいけません。あくまで本人の能力がどうなったかを評価すべきで、成果はその副産物でしかありません。
もし成果を評価の対象とすると、良くないことが発生します。それは、部署によっては成果が見えづらいため組織内に評価されやすい部署・評価されづらい部署が存在することになり、評価されやすい部署に人が流れることで組織が正しく成果を出し続けることが困難になるということです。
どんな組織であれ、基本的には必要だから存在しています。重要だけど成果が見えづらい部署が正常に稼働しなくなったら、組織は崩壊に近付きます。
どうしても成果を評価した場合は、固定給ではなく賞与で対応する方法はありかもしれません。
もう一つ大事なポイントがあります。それは、評価というのは被評価者は評価者に上から目線で「大変良くできました！」って言ってもらうことではないということです。
その人の能力を的確に言語化できれば良いので、極端に言えば被評価者同士で評価し合うことも可能です。実際は視座視野視点等の観点もあるので評価者の目は入れておいた方が良いとか思いますが。
ということで、目標設定では「半年後にこういう不確実性を削減する能力を身につける」というゴールとそれに伴う具体的なアクションを決めていくこと、評価は能力を見定めることが重要です。
補足
エンジニア外の職種についてです。実はこの不確実性の話はエンジニアリングに限らず当てはまると考えています。
ただ、職種によっては不確実性がほぼ存在しない領域があるため、全く違う見え方になります。
例えば、営業職であれば「事業目標を達成すること」が最大のゴールになるので、目的不確実性がほぼありません。とにかく方法不確実性を削減していくことが重要になるため、「○までに□円受注する(=という目的を達成するための方法不確実性を削減する能力を身につける)」という目標設定をすることが許容されます。
具体例
上記のポイントを押さえていれば、基本的にはどのようなやり方でも良いんじゃないかと考えています。とはいえ具体的なイメージが湧いていない方もいると思うので、弊社で行っている例を紹介します。
実際の運用の流れに沿って、グレード定義、目標設定、評価、グレード・給与決定の順に説明します。
グレード定義
上記のように、notionにそれぞれのグレードに対してどういう能力を持っているかを言語化しています。多様性に欠ける内容になっているので、まだまだ改善していく必要はあります。それぞれのグレードについては更に5段階設定しています。
目標設定
このように目標設定を記載しています。
1. ブロック目標: 3ヶ月~半年程度の期間で、大きくどのような不確実性の削減能力をどうしていきたいのかを言語化してもらいます。グレードを用いた表現でもOKとしています。
2. No目標: 機能開発や大きな課題など、ある時点でやることになったものを記載し、それに伴う不確実性のある問題を記載します。
3. 中目標: 機能開発や大きな課題を解決していくにあたり、目の前にあるやるべきタスクと、解決しようとしていることを記載します。期日を入れたり、実際のタスクを入れたり、極力具体にして表現します。
このような目標設定とやったことを振り返りつつ記載することで、しばらく後で振り返ると、シート上には自分自身が削減した不確実性のある問題が列挙されていることになります。
評価
評価時期になると、被評価者に期全体を通した振り返りコメントを記載してもらいます。この振り返りに対して、評価者がS~Dの評価を付けています。
ただ、評価結果のS~Dは被評価者がこの期にどれくらい成長したかの差分を表現しているだけで、被評価者の能力を絶対値で表現したものではありません。なので、S~Dは査定と直接関係しているわけではありません。
グレード・給与決定
ほとんど隠れてしまいましたが、上記の形でグレードに対して、氏名と理由を添えて新しいグレードを決めていってます。
ちなみに、ややこしいですが評価結果のS~DとグレードのレベルのS~Dは無関係です。
ここで決定したグレードと給与テーブルを元に、新しい給与を決定しています。
さいごに
長文読んでいただき、ありがとうございました。
弊社HRBrainでは目標評価管理のSaaSを提供していることもあり、この分野は常にしっかりやっておかないとというプレッシャーにいつも悩まされています。
ある程度基盤となるところはできたかなと思っているんですが、まだまだ改善の余地があるなとも感じています。
ぜひ他社のEMやVPoEの方など、一緒に議論できたら嬉しいです。
おしまい。
この記事が気に入ったらサポートをしてみませんか？