技術力評価会のこと
VOYAGE GROUPでは技術力評価会という制度でエンジニアの技術力を評価している。そのやり方を紹介しつつ、よくあるトラブル、そしてそこに込められた想い…。我々はどこに行こうとしているのか。その全貌が明らかになる。
(この文書は エンジニアのマネージメントで悩んでいる人が集まる会 #3 での発表資料をもとに加筆・修正しています)
技術力評価会の実装
VOYAGE GROUPでのエンジニア職評価は4グレード制を採用しており、グレード1, 2の人が評価対象者、グレード2,3,4の人が評価者となる。つまり、グレード2の人は評価される方もやるし、評価する方もやることになる。
人事評価は「能力」「実績」「CCFB」で決定されるということになっている。ここでいう「能力」について評価しようっていうのが技術力評価会の領域というわけだ。つまり、人事評価制度のすべてではないし、ここだけで給料が決まるわけでもない。
タイムライン
人事評価タームにあわせて、半年に1回サイクルでやってる。
- 評価者割り当てる: 外部評価者もここで調整している
- 日程調整: 評価対象者が50人以上になるので、ある程度の期間内でそれぞれ調整することになる
- ネタ準備: 「半年なにやったっけ」を思い出しながら、どのトピックについて話をするか考えたり資料を作ったりしておく
- 90分セッション: 評価会本番は評価者含めた質疑をする
- 評価結果のすり合わせ: 評価者が評価レポートを持ち寄って、チームリーダーなどともに、内容を確認する。
- 評価結果を対象者に本人にフィードバック: レポートを見せつつ対面で感想戦
- ふりかえる: チームで評価結果を確認しあったり、社全体で評価会のやり方についてふりかえったりする
何が良いのか
- 評価の客観性が増す
- 評価慣れする: 評価対象者は説明力がつくし、評価者は質問力がつくし、…
- スケールする: 特定の評価者に負荷が集中しない
よくある状況とその対応
「半年間、俺、なんにもやってないわ」
そんなことない。なんかネタはあるはず。小さいのでもいい、そこに込めた工夫を語ろう。
「結局プレゼン上手い人が評価されるんじゃね?」
否定しない。最終的には説明力を含めて能力でいいのでは。評価者としても、簡単にハックされてはならない。評価者として、細かくつっこんでみよう。
評価者が毎回代わり映えしない
データエンジニア、ネイティブアプリなど、技術領域的にハイコンテキストな場合にありがち。外部評価者に頼る。
やる前はだるいけど終わったら楽しかった
よくある。「風呂に入る前は面倒だと思うが、入った後に後悔する人はいない」っていうのは、だいぶ前からつぶやかれていたようだ。
気をつけたいポイント
まあでも(というかだからこそ)、気をつけたいポイントはいくつかある。
評価対象者として
- その技術を採用した目的を忘れないように: なぜその機能を実装したか
- なぜその手法を採用したのかを説明できるように: 複数プランを比較してるはず。よく思い出してみよう。
- 普通に議論しよう: 「なぜxxは採用しなかったのですか」みたいな流れで、考えていなかったアイデアについて質問されることはある。そのアイデアについての情報を引き出そう。森羅万象について思いつかなかったことは問題ではないし、やったこと以上によく見せる必要はない。いいアイデアならぜひ採用しよう。
評価者として
- ストーリーとして理解するように: 数ヶ月前の文脈として、技術的判断が妥当だったか想像しよう。当時はterraformもアップデートされず、AWSの発表もなく、競合のサービスはまだなかったし、ビットコインは高かった。
- 対案があればちゃんとぶつけて議論する: アイデアを提案するだけでは、ギャップは埋まらない
- 評価結果レポートは評価会の中で議論したことをまとめる: まとめるだけなのでレポートが早く書ける。とくにネガティブな評価を書こうとするとき、評価会ではない場で考えると、評価対象者から「言ってくれればいくらでも説明できたのに」っていう恨みを買うことになる。どうしても評価会後に気になったら、別途話をしよう。
まとめと蛇足
- 自分がやったことについて客観的にふりかえることができる
- 次に何をしたら良いかの意見がもらえる
- 給与とは直接結びつかない: 技術力評価会が人事評価のすべてではないし、人事評価が給与決定のすべてでもない