console.blog(self);

技術、読んだ本、いろいろ。

エンジニアの評価制度について

memo

Goodpatch Advent Calendar 2016 25日目の記事です。

「エンジニア向け評価制度」とは、技術やスキルなどの側面を評価するための制度という意味合い。いまエンジニア向けの評価制度を作っていて、いろいろな会社のエンジニア向け評価制度について調べてみた。

大別すると、こんな感じ。

  • そもそも評価制度がない
  • エンジニア向け評価制度がない
  • エンジニア向け評価制度がある

そもそも評価制度がない

時雨堂やソニックガーデンには評価制度がない。

こういった考え方は、たしかになーと思う。

良い悪いを短期的に見ないからです。短期的に評価すると、短期的な視線で仕事をしちゃうじゃないですか？　一番イヤなのは、チームで助け合って働くのが大事なのに、“自分の評価を考えると、この人を助けている場合じゃない”となってしまうこと。そうなるとチームワークが崩壊します。だから短期的な評価はやめました。

スペシャリストな人が多くて、社員を増やす予定がなければ、こういったやり方がよさそう。ある程度以上の規模になると、評価制度を導入するメリットもありそう。

エンジニア向け評価制度がない

エンジニア向け評価制度がない会社もたくさんあると思うけど、明示的に持たない会社ってけっこう珍しい気がする。

― そんな理想の像がある中で、エンジニアの評価軸はどのように定めてらっしゃるんですか。

特別、エンジニアだけの評価軸って明文化されてないんですよ。エンジニアも、デザイナーも、皆「いい人をつくる」という経営理念で評価されます。エンジニアである前に、スタートトゥデイのメンバーだから、いい人をつくれると判断された人がステップアップしていくんです。

エンジニア向け評価制度がある

いろんな会社で導入されていて、参考になる。特にVoyageとペパボはいろいろな情報が公開されている。

Voyage

VOYAGE GROUPのエンジニア評価あれこれ。

こういった軸の話しとか、とても参考になる。

  1. サービスや事業を理解しているか（そもそもサービスや事業への理解が浅いと見当違いのものを作ってしまう）
  2. プロジェクトの要件や制約条件を理解しているか（プロジェクトには要件や制約条件がつきもの。これを明確に定義して作ることも欠かせない）
  3. 可用性（24時間365日動くシステムを作るために単一障害点をなくしているか，障害が起こったときに復旧・検知しやすいようになっているか）
  4. 性能（きちんと性能が出る設計か，どこかで詰まるような設計になっていないか）
  5. セキュリティ（セキュリティは堅牢か，昨今サービス提供する上では欠かせない指標）
  6. 変更容易性（作ったものは1回出して終わりではない，フィードバックを受けてどんどん改善していけるよう変更容易な設計・実装になっているか）
  7. テスト容易性（プロジェクトの制約によっては品質に時間をかけるのが難しいことも。テストが簡単にでき，プロデューサー含め専門職以外も実施しやすいよう配慮されているか）

第6回　VOYAGE GROUP執行役員CTO小賀昌法氏に訊く（後編）―クリエイティブ職向けに考え抜かれた育成・評価の仕組み：Webクリエイティブ職の学び場研究｜gihyo.jp … 技術評論社

ペパボ

ペパボのエンジニア評価あれこれ。評価者側、被評価者側のエントリがあって参考になる。

こういう傾向もすごく参考になる

評価全体を見渡してみると、評価の高い人には、以下の傾向が見られます。（一人がすべてを満たしている、というわけではないです。）

  • 開発手法、開発フローに対するきちんとした理解と実践
  • 開発もインフラもできるオールラウンドな能力
  • 常に新しい技術情報を追いかけ、それを仕事にも取り込み活かしている
  • 現状これでやれてるから、とそこに留まらずに常に改善していこうとしている
  • 一部の技術ではずば抜けていて、社内で他にできる人が少ない、あるいはいない
  • いかに自動化して楽をするか、ということを常に考え実践している
  • アウトプットがすごい

Paperboy's engineer evaluation system - Gosuke Miyashita

クックパッド

その他

いまやっていること

いろいろ調べたことをまとめて評価制度の叩き台を作って、社内の全エンジニアと評価制度について1 on 1形式でヒアリングをさせてもらっている。実際にヒアリングしてみると、本当にいろいろな考え方の人がいて興味深い。多様性はあると感じた。制度設計は難しいけど。

まとめてみると、細かいところは違えど以下の観点で仕組みを作っている気がした。

  • 自社のエンジニアとして意識してほしいこと
  • 事業的な視点
  • 技術的な視点

事業的な視点と技術的な視点という分け方をしている企業が多いような印象だった。これと自社の企業理念や行動規範とのバランスが、企業ごとにちょっとずつ違う。このバランスの取り方が、大事なんだろうなと、感じている。

流行りにのるわけではないけど、評価の軸をSystem of RecordとSystem of Engagementの視点で分けつつ、バイモーダルを意識した形で選択できるように分類したらどうかな、と思っている。キーワードをそのまま使うわけではないけど、分類するための視点としてはよいと感じた。これは自分で思いついたわけではなく、ヒアリングの過程でアイディアをもらった。

WEB+DB Pressにもnaoyaさんが記事を書いていた。

WEB+DB PRESS Vol.96

評価制度の内容以外で共通しているのは、そのプロセスにしっかりと時間を掛けていることだった。評価面談の前、評価面談、その後のフィードバック面談が、しっかりと設計されていた。評価制度の内容ではなく、大切なのはどうやって相互に納得感を醸成するのかだと思う。

そこを前提として、どんなバランスがよいのか考えている。ヒアリングをしていくことで、評価制度について興味を持ってくれる人が増えたし、よい意見ももらえた。

CTOになって、ちょうど1年になる。ピーターの法則をかなり意識する。エンジニアが気持ちよく働けるような制度をしっかりと考えて、よいものを作りたい。頑張らなくては。