技術力評価会のこと

4 min readMay 27, 2019

VOYAGE GROUPでは技術力評価会という制度でエンジニアの技術力を評価している。そのやり方を紹介しつつ、よくあるトラブル、そしてそこに込められた想い…。我々はどこに行こうとしているのか。その全貌が明らかになる。

（この文書はエンジニアのマネージメントで悩んでいる人が集まる会 #3 での発表資料をもとに加筆・修正しています）

技術力評価会の実装

VOYAGE GROUPでのエンジニア職評価は4グレード制を採用しており、グレード1, 2の人が評価対象者、グレード2,3,4の人が評価者となる。つまり、グレード2の人は評価される方もやるし、評価する方もやることになる。

人事評価は「能力」「実績」「CCFB」で決定されるということになっている。ここでいう「能力」について評価しようっていうのが技術力評価会の領域というわけだ。つまり、人事評価制度のすべてではないし、ここだけで給料が決まるわけでもない。

人事評価タームにあわせて、半年に1回サイクルでやってる。

そんなことない。なんかネタはあるはず。小さいのでもいい、そこに込めた工夫を語ろう。

否定しない。最終的には説明力を含めて能力でいいのでは。評価者としても、簡単にハックされてはならない。評価者として、細かくつっこんでみよう。

データエンジニア、ネイティブアプリなど、技術領域的にハイコンテキストな場合にありがち。外部評価者に頼る。

よくある。「風呂に入る前は面倒だと思うが、入った後に後悔する人はいない」っていうのは、だいぶ前からつぶやかれていたようだ。

まあでも（というかだからこそ）、気をつけたいポイントはいくつかある。

その技術を採用した目的を忘れないように: なぜその機能を実装したか
なぜその手法を採用したのかを説明できるように: 複数プランを比較してるはず。よく思い出してみよう。
普通に議論しよう: 「なぜxxは採用しなかったのですか」みたいな流れで、考えていなかったアイデアについて質問されることはある。そのアイデアについての情報を引き出そう。森羅万象について思いつかなかったことは問題ではないし、やったこと以上によく見せる必要はない。いいアイデアならぜひ採用しよう。

ストーリーとして理解するように: 数ヶ月前の文脈として、技術的判断が妥当だったか想像しよう。当時はterraformもアップデートされず、AWSの発表もなく、競合のサービスはまだなかったし、ビットコインは高かった。
対案があればちゃんとぶつけて議論する: アイデアを提案するだけでは、ギャップは埋まらない
評価結果レポートは評価会の中で議論したことをまとめる: まとめるだけなのでレポートが早く書ける。とくにネガティブな評価を書こうとするとき、評価会ではない場で考えると、評価対象者から「言ってくれればいくらでも説明できたのに」っていう恨みを買うことになる。どうしても評価会後に気になったら、別途話をしよう。