Goodpatch Advent Calendar 2016 25日目の記事です。
「エンジニア向け評価制度」とは、技術やスキルなどの側面を評価するための制度という意味合い。いまエンジニア向けの評価制度を作っていて、いろいろな会社のエンジニア向け評価制度について調べてみた。
大別すると、こんな感じ。
- そもそも評価制度がない
- エンジニア向け評価制度がない
- エンジニア向け評価制度がある
そもそも評価制度がない
時雨堂やソニックガーデンには評価制度がない。
こういった考え方は、たしかになーと思う。
良い悪いを短期的に見ないからです。短期的に評価すると、短期的な視線で仕事をしちゃうじゃないですか? 一番イヤなのは、チームで助け合って働くのが大事なのに、“自分の評価を考えると、この人を助けている場合じゃない”となってしまうこと。そうなるとチームワークが崩壊します。だから短期的な評価はやめました。
スペシャリストな人が多くて、社員を増やす予定がなければ、こういったやり方がよさそう。ある程度以上の規模になると、評価制度を導入するメリットもありそう。
エンジニア向け評価制度がない
エンジニア向け評価制度がない会社もたくさんあると思うけど、明示的に持たない会社ってけっこう珍しい気がする。
― そんな理想の像がある中で、エンジニアの評価軸はどのように定めてらっしゃるんですか。
特別、エンジニアだけの評価軸って明文化されてないんですよ。エンジニアも、デザイナーも、皆「いい人をつくる」という経営理念で評価されます。エンジニアである前に、スタートトゥデイのメンバーだから、いい人をつくれると判断された人がステップアップしていくんです。
エンジニア向け評価制度がある
いろんな会社で導入されていて、参考になる。特にVoyageとペパボはいろいろな情報が公開されている。
Voyage
VOYAGE GROUPのエンジニア評価あれこれ。
- 第6回 VOYAGE GROUP執行役員CTO小賀昌法氏に訊く(後編)―クリエイティブ職向けに考え抜かれた育成・評価の仕組み:Webクリエイティブ職の学び場研究|gihyo.jp … 技術評論社
- 株式会社VOYAGE GROUP - 技術者の能力は技術者が評価
- CTOに就任してからの5年間、VOYAGE GROUPで変わったこと・変わらなかったこと - VOYAGE GROUP techlog
- 初めての技術力評価会を終えたので感想を書いた - VOYAGE GROUP techlog
- エンジニアの評価観点について - @katzchang.gist
こういった軸の話しとか、とても参考になる。
- サービスや事業を理解しているか(そもそもサービスや事業への理解が浅いと見当違いのものを作ってしまう)
- プロジェクトの要件や制約条件を理解しているか(プロジェクトには要件や制約条件がつきもの。これを明確に定義して作ることも欠かせない)
- 可用性(24時間365日動くシステムを作るために単一障害点をなくしているか,障害が起こったときに復旧・検知しやすいようになっているか)
- 性能(きちんと性能が出る設計か,どこかで詰まるような設計になっていないか)
- セキュリティ(セキュリティは堅牢か,昨今サービス提供する上では欠かせない指標)
- 変更容易性(作ったものは1回出して終わりではない,フィードバックを受けてどんどん改善していけるよう変更容易な設計・実装になっているか)
- テスト容易性(プロジェクトの制約によっては品質に時間をかけるのが難しいことも。テストが簡単にでき,プロデューサー含め専門職以外も実施しやすいよう配慮されているか)
第6回 VOYAGE GROUP執行役員CTO小賀昌法氏に訊く(後編)―クリエイティブ職向けに考え抜かれた育成・評価の仕組み:Webクリエイティブ職の学び場研究|gihyo.jp … 技術評論社
ペパボ
ペパボのエンジニア評価あれこれ。評価者側、被評価者側のエントリがあって参考になる。
- エンジニア評価制度の話 - エンジニア評価制度とは | スタッフインタビュー | 採用情報 | GMOペパボ株式会社
- エンジニア評価制度の話 - エンジニア評価制度の運用について | スタッフインタビュー | 採用情報 | GMOペパボ株式会社
- エンジニアの働き方 | キャリア採用 | 採用情報 | GMOペパボ株式会社
- エンジニア専門職のグレードについて詳細な役割定義は必要か? - delirious thoughts
- ペパボのエンジニア評価制度をパワーアップした - delirious thoughts
- ペパボのエンジニア評価制度を、社内の一般エンジニアはどうみているのか? - 彼女からは、おいちゃんと呼ばれています
- Paperboy's engineer evaluation system - Gosuke Miyashita
- Paperboy's engineer evaluation system その後 - Gosuke Miyashita
- ペパボでの GitHub の使い方 - Gosuke Miyashita
こういう傾向もすごく参考になる
評価全体を見渡してみると、評価の高い人には、以下の傾向が見られます。(一人がすべてを満たしている、というわけではないです。)
- 開発手法、開発フローに対するきちんとした理解と実践
- 開発もインフラもできるオールラウンドな能力
- 常に新しい技術情報を追いかけ、それを仕事にも取り込み活かしている
- 現状これでやれてるから、とそこに留まらずに常に改善していこうとしている
- 一部の技術ではずば抜けていて、社内で他にできる人が少ない、あるいはいない
- いかに自動化して楽をするか、ということを常に考え実践している
- アウトプットがすごい
クックパッド
- クラウドワークス、Sansan、nanapi、クックパッド、スタートアップにおけるエンジニアの採用と評価とは - THE BRIDGE(ザ・ブリッジ)
- エンジニアを成長させる、たった6つの指針。|クックパッド CTO 橋本健太に訊く![前編] | CAREER HACK
- エンジニアの評価基準、そして危機感を簡単に得る方法。|クックパッド CTO 橋本健太に訊く![後編] | CAREER HACK
その他
- エンジニアの評価基準とキャリアパスのお話 | 外道父の匠
- CTOの役割と組織における技術的ポートフォリオの組み方 - Hatena Developer Blog
- 楽天株式会社: 人事制度 | 採用情報
- 超優秀人材でも、雇わない選択ができるワケ|ユーザベースに学ぶプロフェッショナルの採用・評価指標[1] | CAREER HACK
いまやっていること
いろいろ調べたことをまとめて評価制度の叩き台を作って、社内の全エンジニアと評価制度について1 on 1形式でヒアリングをさせてもらっている。実際にヒアリングしてみると、本当にいろいろな考え方の人がいて興味深い。多様性はあると感じた。制度設計は難しいけど。
まとめてみると、細かいところは違えど以下の観点で仕組みを作っている気がした。
- 自社のエンジニアとして意識してほしいこと
- 事業的な視点
- 技術的な視点
事業的な視点と技術的な視点という分け方をしている企業が多いような印象だった。これと自社の企業理念や行動規範とのバランスが、企業ごとにちょっとずつ違う。このバランスの取り方が、大事なんだろうなと、感じている。
流行りにのるわけではないけど、評価の軸をSystem of RecordとSystem of Engagementの視点で分けつつ、バイモーダルを意識した形で選択できるように分類したらどうかな、と思っている。キーワードをそのまま使うわけではないけど、分類するための視点としてはよいと感じた。これは自分で思いついたわけではなく、ヒアリングの過程でアイディアをもらった。
- System of Record と System of Engagement // Speaker Deck
- System of Record と System of Engagement、そしてバイモーダルITについての考察 - 生産性向上ブログ@miyajan
WEB+DB Pressにもnaoyaさんが記事を書いていた。
評価制度の内容以外で共通しているのは、そのプロセスにしっかりと時間を掛けていることだった。評価面談の前、評価面談、その後のフィードバック面談が、しっかりと設計されていた。評価制度の内容ではなく、大切なのはどうやって相互に納得感を醸成するのかだと思う。
そこを前提として、どんなバランスがよいのか考えている。ヒアリングをしていくことで、評価制度について興味を持ってくれる人が増えたし、よい意見ももらえた。
CTOになって、ちょうど1年になる。ピーターの法則をかなり意識する。エンジニアが気持ちよく働けるような制度をしっかりと考えて、よいものを作りたい。頑張らなくては。