エンジニアの評価に関する一考察

タイトルは某ヤン提督のあれのパクリです。
卒論で一考察ってつけたら、1じゃなくてちゃんと考察しろって怒られた苦い思い出があります。
今回は、CTOになってからずっと悩んでいるエンジニアの評価について考えて見ます。というか2Qに向けて評価制度を変更したので、その時の頭の中の整理になります。

エンジニアの評価を考える

エンジニアの部下というものができて何年も経ちますが、どう評価するかが固まっていないままきています（経営陣に対して適切な提案ができない）ので、彼らに何をFBしたら正しいかも未だによくわからないですし、それがゆえにメンバーの成長は本人の努力次第という、組織的な何かがない状態なので早急に改善したい部分です。

弊社が取り入れているマネジメント手法に識学というものがありますが、そこでも、本人がどの立ち位置で物事を見て、フォーカスすべきことが何なのかをきっちり定義してあることが重要とあります。適切なFBのための適切な評価手法というものをいい加減考える必要があるなと思っています。

今までの問題点

MBOなどで評価はしてきましたが、セールス系の評価の仕方を参考にアウトプットのみを評価していくことへの不満は多いです。どうしても数値化することが必要なので、最新技術のキャッチアップ　みたいな尺度になると評価がぶれます。

他方、「会社の利益達成」みたいな目標は、数値化できていてo xつけやすく、バックヤードとして幅広く物事を見て会社全体をサポートしてほしいという意味合いで入れることが多いですが、それに対する責任がはまっていないことが多く（打ち手を思いついても権限が足らない、直接的な売上向上アクションができないことが多いなど）、会社の状況に対するアンテナを立てていこう、くらいの受け取られ方をしている気がします。（上司の伝え方の問題もあります）

評価軸を考える

• もちろん組織への貢献
  • 組織の貢献 == 「会社の競争力の源泉となる仕組み = プロダクト を通して組織に貢献する」と定義
    • 作ったプロダクトが創出する価値を最大化させる
• 新しいテクノロジーに対するアプローチは評価に必要か？
  • 新しい技術はある程度自分で勉強してもらわないといけない
  • でもそこにもエンジニアの価値があると思っているし評価の対象にするべき

弊社はテックファーストではなくプロダクトファーストということもあり、定量的にジャッジするのはプロダクトの良し悪しだけでいいのではないか。

他方、プロダクトのみ評価していると、新しいサービス作ろうという時に既存の知識で戦うしか無くなるため、やはり新しいテクノロジーに対するアプローチそのものを評価しないと、未来が見えない組織になる（機能Aがほしい時のその機能が作れるかどうかは、運（たまたまそれをかじっていてくれたとか）が絡んでしまう）。そういう意味で未来への投資も評価する必要があるのではないか。
こちらは定量的な評価は経験上難しいが、評価の際にはあらかじめきちんとexpectationsを作っておいて（期待値調整）、それで評価することで、ある程度カバーできないか？

どうしたいか

• 適切なFBを与えたい
  • 正しく評価することで、本人に適切なFBを行える
    • 良いFBがあると、成長が早い
    • 本人自身のメンタルにも影響（心理的安全性）
• 目標に対する本人の納得感
  • ある程度一緒に決める
• アウトプットだけでなくインプットも評価したい
  • 未来への投資も評価
• 組織の連続的な成長と非連続的な成長の両方に影響を与えたい
• 複雑なことはしたくない
• 胸を張って、エンジニアをマネジメント（評価とFB）ができていると言いたい
  • リクルーティングへの影響
    • いいマネジメントできていればうちのような小さい会社にも入ってくれる人がいるんじゃないか・・？
  • 離職率への影響
    • FBがないと成長が鈍化するという話もある

だいぶ都合のいいこといってますが、今クォーターで上記を元に作ったテンプレートはこんな感じです。
※重要なのは、この過程をある程度一緒に考えること（出来ればメンバーから案を出させるなど）
無論全部100%盛り込めたとは思っていません。

定量目標

プロダクト：回収的視点

• アウトプットの評価
• 組織の今の利益のために動く
• 数値で評価
• 連続的な成長に影響

こっちはある程度上司の側でほしいものを定義してそれをブレイクダウンしていきました。

コンピテンシー目標

テクノロジー：投資的視点

• インプットの評価
• 組織の将来のために動く
• 非連続的な成長に影響
• やったやってないで評価

叩きをメンバーに作ってもらい、それを練って、expectationsを作っていくというのが今クォーターで試した1つ流れになります。

実際に作ったMBOのイメージ

定量目標1

Aシステムに機能1と機能2と機能3の追加

• Expectations.
  • どれも実装できず：評価最低
  • 機能1のみ実装：評価C
  • 機能1と2を実装：評価B
  • 全部実装：評価A

定量目標2

課題Aへの回答のためのAIモデルの構築
モデルの精度はデータ集団Aからランダムにピックした100個のデータを使用する

• Expectations.
  • 回答精度50%以下：評価最低
  • 60%以下：評価C
  • 70%以下：評価B
  • 80%以下：評価A

コンピテンシー目標

言語N の習得

• Expectations.
  • FIZZBUZZ実装レベル
  • APIの実装レベル
  • 本番プロダクトでの実装
  • 本家にプルリク

こんな感じです。
一人一人作っていくのでめちゃくちゃ大変でしたが、とりあえず労力はすごかったので、やった感はすごいです・・。評価自体はシンプルなので、クォーターの最後の評価の際もめたりめんどくさいことは起こりにくいのではないかなと思っています。

まとめ

2018年の第2クォーターに弊社で作ったエンジニア評価の考え方をまとめてみました。

プロダクトに対する評価のみに絞ってしまうと、弊社のようにプロダクト単体で食べているわけじゃないエンジニアチームにはつらい（それこそクォーターの途中で既存プロダクトを捨てるようなジャッジもままありますので）ので、どうにか未来への投資も評価に入れたいというところから端を発しています。

無論改良の余地というか考え方をどんどん変えていく必要はあるとは思っています。チームの規模やその時々の会社の状況に合わせて柔軟に動ける評価作りは今後も続けていきたいと思います。