- 公開日
VOYAGE GROUPの『公開技術力評価会』に行ってエンジニア評価と給与設定について本気出して考えた
目次
先日VOYAGE GROUP エンジニアの公開ガチ評価会というイベントに行ってきた。イベントの細かな内容まとめは他の方のブログに譲るとして、エンジニアの評価についていろいろ考える良いきっかけとなったので書いてみる。
人の評価は難しい
（エンジニアに限らず）人の評価は難しい。自分も人を評価する立場になって改めて思う。
付与できる昇給額やインセンティブに対して使える原資は限られている。加えて、本人の高い自己評価に対して組織の求める期待値との乖離や、他のメンバーとの相対評価の間にミスマッチがあるケースだって少なくない。
良い評価を伝えられる人と残念な結果を伝えなければならない人のことを考え、与えられた予算の中で精一杯納得感のある評価を伝えたいと思い悩む日々。
マネージャーの視点から見える向こう側の景色｜Kazutaka Irie｜note
僕自身、評価では苦い思いをしてきた。所属するチームの上長・部の上長ともに高い評価を貰ったのに天の意思によりランク・お給料ともに無風だった経験。自らの技術力を総動員してプロジェクトのイニシャルリリースを成功に導いたが、その後プロジェクト自体が失敗したために社内的にその功績は全く評価されなかった経験。市場価値より低く買い叩かれているなという経験1。
そんな僕自身の苦い経験から「自分が評価するメンバーにはできる限り納得感のある評価をしたい」という強い思いがあり、今回のイベント参加に至った。
納得感のある評価
評価は納得感があればなんだっていい と個人的に思っている。
極論、そこに納得感があるのであればじゃんけんで評価を決めても良い。例えば組織の全員が自他ともに「みんながんばっているよ、優劣はとくにないよ」という認識で評価が画一化されているのであれば「じゃあ今期の評価はじゃんけんで」という提案はもしかしたら受け入れてもらえるかもしれない2。たとえじゃんけんだとしてもそれにメンバー全員が納得し不満が全く無いのであれば、それは立派な評価だ。
だが実際問題、全員が納得できるような評価を行うのは極めて難しい。全ての評価が良いものになるとは限らないし、自己評価と会社からの評価が必ずしも一致はしないからだ。その齟齬が生じていたときに評価者は被評価者にいかに納得できる理由を提示できるかが重要だ。
技術力評価会
そういう意味でVOYAGEさんのエンジニア技術評価会はエンジニアにとって納得感のある評価が可能な評価制度になっていると感じた。具体的には下記のポイントである。
- 定量化しない
- オープンな評価
- 揚げ足取りをしない
- 複数人の専門家による評価
- 社外評価者
- ビジネス指向
定量化しない
まず面白いなと思ったのは技術力評価会では 評価を定量化しない ということだ。多くの企業では評価は何かしらの形で定量化してアウトプットすると思う。例えばABCDEの五段階評価、100点満点中何点などだ。
定量的な評価アプローチはわかりやすい反面、評価者の評価の甘辛で評価が低くなったり高くなったりすることがあり難しい。また評価基準もまちまちになりがちで、全社的に公平な評価基準を作ることは個人的には無理だと思う（例えば100点満点だとしたら100点となる基準は何か？/その基準は明確かつ公平か？/120点の人の20点は評価されないのか？など）。
技術力評価会では定量化しない代わりにフィードバックとなる文章をしっかり書くという構造になっている。無理に定量化するよりもこのように文書を通じたフィードバックを行うほうが上述の定量化の問題も起きないし、被評価者の納得感も得られやすいと思う。
オープンな評価
各人のランク（グレード）および 評価結果をGitHubでオープンにしている ということも興味深い。
評価をオープンにすることは評価の透明性が担保される一方で、「なぜあの人が私/俺よりランクが高いのか？」という不満も呼び込みやすく諸刃の剣の施策だ。ただVOYAGEさんの場合、被評価者の声を拾いつつ評価制度を納得感のあるようにブラッシュアップしてきているようなのでオープンにすることで得られるメリットのほうが大きいと感じた。
オープンにすることでロールモデルのイメージが得られるのも良い。同じチームにおいてAさんよりランクが上のBさんがいたとする。この状況においてAさんは下記の様な具体的なアクションをとることができる。
- 「Bさん（ロールモデル）のように行動すればランクが上がる」
- オープンになっているBさんの評価をみにいく
- Bさんの評価されているところを確認する
- Bさんの評価されているところを真似る
このような組織全体がレベルアップしていく絵を描きやすい。
他に評価をオープンにしている会社の例としてはペパボさんがある。こちらも参照されたい。ペパボのエンジニア文化を醸成するエンジニア評価制度 - ペパボテックブログ
揚げ足取りをしない
基本的に評価会においては揚げ足取りをしない。揚げ足となる指摘としては例えば「ここtypoあるね？」「スタイルガイドに沿っていないコードじゃない？」などだ。誰だって小さなミスはある。本質的な部分のみで評価しようという姿勢がよかった。
揚げ足取りはやらないってのは地味にめちゃくちゃ重要な気がする。本質的な指摘で評価したいよね#vg_tech_assessment
— toshimaru (@toshimaru_e) January 30, 2019
複数人の専門家による評価
フロントエンジニアの技術力をバックエンドエンジニアは評価できない。逆もまた然りでバックエンドエンジニアの技術力をフロントエンジニアは評価できない。このように異なる職種の異なる技術スタックのエンジニア同士は基本的に評価はできない。
VOYAGEさんの場合、チーム関係なくチームを跨いで 二人以上の適切な評価者が設定されるような仕組みを取ることで評価者・被評価者のミスマッチを防ぐ。被評価者をきちんと評価できる技術者がきちんとアサインされるわけだ。
そして一人ではなく二人以上とすることもポイントだと思っていて、複数の評価観点・視座で評価を行うことで偏った評価を防ぐことができる（実際、評価会の中で評価者によって意見が分かれる場面があった）。
社外評価者
なまじ社内事情がわかっていると（チームのメンバー状況・プロダクトの歴史やバックグラウンドなど）、意図せずとも社内のコンテキストによるバイアスが入るかもしれない。また社内の評価基準が社外の評価―つまり業界的な評価基準と離れてしまうかもしれない。あるいは社内のリソースだけで十分な専門家の観点を用意できないかもしれない（例えば機械学習エンジニアの領域など）。
これらの問題を解消し評価をフェアに行うために 評価者を外部から招いて３人目の評価者として入れる のは良いアイディアだと思った。外部の”強い”エンジニアの評価となれば被評価者の納得感も増すはずだ。
ビジネス指向
評価会では技術選定について聞く場面もあった。「なぜその技術選定（今回でいうとReact.js）に至ったのか？」
「流行ってるからReact.js」「jQueryはイケてないのでReact.js」…こういった回答だと不十分でもう一歩本質的な理由に踏み込むように評価者が導くように質問を展開していたのが印象的だった。
本質的な理由としては「DOMにステートを持たせたくない」「フロントエンドをテスタブルにしたい 」「メンテナビリティを高めたい」のようなもので、それが最終的にプロダクトの品質向上に繋がりビジネス的にもインパクトがあるよね？というところまで一緒に落とし込んでいるのが流石だと感じた。
「技術的な投資判断はどのようにプロセスを経てなされたのか」良い観点の質問だなぁ#vg_tech_assessment
— toshimaru (@toshimaru_e) January 30, 2019
エンジニアはともすると技術選定や設計の場面でエゴに走りがちだ。そこで 評価者がきちんとビジネス的な視座を持たせてあげるように誘導 してあげることで、エンジニアだけではなくビジネス側に所属する人たちにも評価してもらえるような理由付けをしている点が素晴らしいと思った。
エンジニアの評価制度の設計と導入
さてここまで「エンジニア技術力評価会は良い制度だった」という話をしてきたわけだが、いざ自分の所属組織でも導入するか？と問われるとおそらくやらないし、やってみようぜ！という提案もしないと思う。
なぜか？ 理由はコストが高すぎるから。評価者一人に対して被評価者が10人アサインされるとしよう。評価時間90分×10人分で900分、評価会単体の時間だけで15時間。それに加えて一人ひとりの評価を記入する時間を30分上乗せするとして30分x10人分で300分でプラス5時間。つまりランクの高い評価者一人あたり最低でも20時間（営業日換算で2.5営業日）は奪われるわけだ。
納得感のある評価を徹底するのはコストがかかる。もちろんそれだけのコストをかけるだけのメリットは享受できると思う。しかし不満もそこまでなくそこそこ上手く回っている既存のエンジニアの技術力評価をひっくり返してまで導入するかというと答えはNOだとは思う。
もし既存の技術力評価に問題があったとしてもなかなか導入は難しいと感じる。なぜならそれだけのコストがかかる制度導入は関係各所のコンセンサスを得るのが難しいからだ。ボトムアップで突き上げて制度を導入するには相当なパワーと時間が必要だ。
ではどう導入するのが一番手っ取り早いかというと、CTOなどからトップダウンで制度を導入することだ。VOYAGEさんの場合もCTOの小賀さんの強い力と思いがあったからこそ実現した制度だと感じた。
ランクと給与をマッチさせるべきか？
全く別の論点として、ランクと給与をマッチさせるべきかどうかという話がある。VOYAGEさんの場合、技術力評価などによって決まるグレードと給与が緩やかに結びついているという話を懇親会で聞いた。
給与テーブル
多くの企業は下記のような給与テーブルが設定されていると思う。下記はSmartHRさんの例だ。
この給与テーブルの仕組みは厳密に運用できていれば納得感もあるだろうし問題ないと思う。しかし問題があるケースとしては例外を作ってしまうことだ。具体的には前職の給与のスライドによって給与テーブルから外れる人が出てしまうこと。これをやると 給与テーブルという仕組み自体が崩壊し評価制度が矛盾を引き起こしひいてはエンジニアの不満・軋轢へとつながっていく。
現年収を聞く理由は下記の2つくらいしか思い浮かびません。
- エンジニアを安く採用したい
- 自社で評価せず、他社の評価を使って楽したい
給与テーブルや評価基準を明確にしている企業様は現年収を聞かないようにして頂けると、「この企業は評価基準が明確なのか」と分かるので聞かないようにして頂ければ幸いです。
面接で現年収(前職の年収)を聞かれるのが嫌い - アジャイルSEの憂鬱
その点SmartHRさんは下記の記事の通り厳格な給与テーブルの運用を行っており素晴らしい姿勢だと思う。
現年収や希望年収を聞かずに、経験や能力、期待する役割、社内の水準と照らし合わせてオファー金額を決めています。
SmartHR社が面談で「現年収・希望年収」を聞かない理由 - 宮田昇始のブログ
市場価値で給与を決定
サイボウズさんの場合、社内評価だけで給与を決めるということはせず 市場価値で給料を決めている。市場価値という概念を取り入れて給与を決めるのはなかなか他に例を聞かず、非常に面白い取り組みだと思った。
サイボウズの給与は「その人の市場価値」で決定されます。市場価値とは「社外的価値」と「社内的価値」の2つで決まります。
サイボウズの給料は「あなたが転職したらいくら？」で決めています | サイボウズ式
エンジニアは給与によって転職してしまうことが多い。社内で高く評価しているのにもかかわらず、お金という理由だけで転職してしまうのだとしたらそれは不幸なことだ。そういった不幸な転職を防ぐために市場価値を給与の決定要因にするのは悪くない判断だと思う。
思い切った賃金テーブルの改定が行えない企業が世の中には多いようで、転職すると年収が上がるというバグが報告されている。
（中略）
社内で手放したくないエンジニアがいるという企業は、年収バグ起因で他の企業に転職されちゃう前にきちんと実力・成果に応じた報酬設定を行うべきた。
『その「エンジニア採用」が不幸を生む』を読んだ ~優秀エンジニアをどう採用するか~ - Hack Your Design!
人を正しく評価する社会であってほしい
エンジニアの転職市場は活況でまだしばらくその情報は続きそうだ。エンジニアを正しく評価し適切な給与設定をしなければ簡単に他社になびいてしまう。
本記事ではVOYAGEさんのエンジニア技術力評価会制度、SmartHRさんの厳格な給与テーブル運用、サイボウズさんの市場価格よる給与決定を紹介した。どれも素晴らしい取り組み・姿勢であり各社「正しい評価をしよう」という努力が見て取れる。
本記事ではエンジニア評価という切り口だったため、エンジニアに焦点をあてた内容になった。しかしエンジニアだけではない。優秀な人が優秀な人として正しく評価される―そんな社会であってほしいと切に願う。
能力の高い人は静かにうつむいて仕事に打ち込む傾向があるいうことです。仕事での業績が認められ、何も言わずに出世の道が開かれることを望み、自分から申し出なければならないと知ると、憤りを覚えて不満をこぼすようになり、最終的にもっと評価してもらえると感じられる場所へ飛び立っていきます。そして、そのパターンを繰り返します。
往々にして経営者は優秀な人材が辞めていくことに驚き、理由がわからないでいます。これは経営者が配慮していなかったことが原因ですが、社員が去るまでその人材の価値を理解していない経営者がいるのは残念なことです。