エアークローゼットのエンジニア評価方法

こんにちは。

株式会社エアークローゼットの藤川です。

よくカジュアル面談で「御社の評価制度について教えて下さい！」とご質問を頂きます。

弊社プロダクトグループ長の市塚がエアークローゼットにおけるエンジニアの評価方法をまとめているので、ご興味ある方はぜひご覧ください！

＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿

Profile

市塚 諒 ICHIZUKA RYO　1990年生まれ

ニックネーム：Icchi(イッチー)

慶應義塾大学在学中に公認会計士試験合格。卒業後、新卒でコンサルティングファームに就職し、事業戦略策定から業務改善(BPR)、経営管理、基幹システム導入まで幅広いプロジェクトに従事。2017年10月に株式会社エアークローゼットに入社。執行役員でありながらサプライチェーンマネジメントグループとプロダクトグループのグループ長に統括。

自己紹介

はじめまして。株式会社エアークローゼットの市塚です。

2012年に新卒でコンサルティングファームに入って、5年ほど事業戦略策定から基幹システム刷新に至るまで様々なクライアントワークに従事したのち、自分で事業をつくる経験を得たいと思い2017年からエアークローゼットにジョインしました。エアークローゼットにはエンジニアやデザイナーが在籍しているプロダクトグループがあり、CTOもこのグループに在籍しています。現在はサプライチェーン改革とプロダクトグループのマネジメントを統括させてもらっています。

新しいライフスタイルを生み出すための事業企画、そしてその実現のためのオペレーション構築、チーム作りをしていきたい。自分の力で困っている人/企業を助けてその人/企業が大きく成長する手伝いをしていきたいと思っています。

今回は様々な企業が悩んでいるであろうエンジニアの評価方法について、僕らがどう考えてどんなやり方をしているのか公開しちゃいます。

目次

1. エンジニアの評価って難しい。。。
2. 大切にしている考え方
3. エンジニア個人としての成長
4. 会社と個人の成長の紐付き
5. エンジニア評価基準
6. ストーリーポイントによる成果の評価
7. スキルマップに基づく行動の評価
8. チーム課題解決の成果の評価
9. まとめ

エンジニアの評価って難しい。。。

営業組織だったら、「売上いくら上げたか」「契約の成約が何件あったか」みたいな分かりやすい成果指標がありますが、エンジニア組織の場合、その分かりやすい成果指標がないことがほとんど。

自分が関わったプロジェクトの成果で評価って考え方もあると思いますが、ある機能開発のプロジェクトでCVRが劇的に改善したときの各エンジニア個人の貢献度を図るっていうのもハードルが高い。
そのプロジェクト仮説自体の筋が良くてたまたま成功することもあるし、逆にエンジニア的にはめちゃくちゃ良い設計・実装しているけど仮説が外れてて全然成果に繋がらなかったってこともよくある。。。

良いエンジニアを真っ当に評価する方法をいろんな企業がいろんなやり方を試しているところなのかなと。

なので、我々エアークローゼットではどんな考え方を元にどんな評価をしているのかを知ってもらって、どんな組織なのかを改めて知ってもらいたいなと思ってます。

大切にしている考え方

エンジニア個人としての成長

エンジニアの成長は会社の成長と直結していると考えています。エンジニアに限らずではありますが、一人ひとりの能力、適正を把握して能力と実績に応じた適切な目標設定／評価をしたいと思っています。

そのため、MBOによる目標設定を実施して、評価基準や目標設定はエンジニア自身と協力して設定します。エンジニアが自らの目標に納得し、それに向かって努力することが、評価の健全な基盤となると思っています。

目標管理制度（MBO）とは、従業員に個人目標を決めてもらい、その進捗や達成度合いによって人事評価を決めるマネジメント方法を言います。もともと現代経営学の祖であるドラッカー氏が、著書『現代の経営』内で発表した概念で、MBOは「Management By Objectives」の略です。

会社と個人の成長の紐付き

会社が登りたい山と個人が登りたい山の擦り合わせをするのが評価の目的の1つだと思ってます。

同じ「山を登る」という目標だとしても、エベレストを登るのか、富士山を登るのか、高尾山を登るのかで全然やることが変わってきます。
個人が高尾山に登ったから評価してほしいと思っても、会社としてはエベレストを登ることを求めているのであればそれは評価できません。

そのため、僕らの目標設定はSMARTの法則に則って、誰が見ても明確な目標になることを心がけています。

SMARTの法則とは具体的な目標設定において役立つフレームワークのことです。
Specific（具体的な）：目標が具体的か
Measurable（測定可能な）：達成度を測れる目標か
Achievable（実現可能な）：達成可能な目標か
Relevant（関連した）：目標の達成が自分の利益、会社の利益につながるか
Time-bound（期限を定めた）：期限が設定されている目標か

エンジニア評価基準

上記の考え方を踏襲して、僕らが現時点で実際に行なっているエンジニア評価基準は大きく3つあります。

ストーリーポイントによる成果の評価

アジャイル開発の見積もりでよく使われる手法であるストーリーポイントを僕らの開発現場でも導入しています。

（ストーリーポイントを詳しく知りたい方は書籍『アジャイルな見積りと計画づくり ー価値あるソフトウェアを育てる概念と技法』を読んでみてください。）

要はある機能を開発するにあたって、「〇〇日かかります」っていう見積もりの代わりに「〇〇ptかかります」っていうポイントでその開発の規模や難易度を表現しています。
実際にはざっくりしたポイント見積もり段階と、詳細なポイント見積もり段階の２段階に分けているのですが、評価として使っているのは詳細な見積もりの方になります。

ptの大きさはいうなれば「お客様にどれほどの価値提供をできているか」という相対的な成果基準になるので、そのptを短い期間でより多くアウトプットできたかどうか（いわゆるベロシティ＝速度）を成果の1つとしてみています。

ここでストーリーポイントを知ってる方なら「ストーリーポイントって評価に使っちゃいけないんじゃないのか」という疑問にぶつかると思います。まさにその通りで、そこは議論を色々重ねたところでした。

ストーリーポイントを評価に用いる問題点

1. 開発者がptを過剰に見積もることでptがインフレする
   ベロシティを上げる簡単な方法は、開発者が結託してptをちょっと多めに見積もることです。そうすると、実態は変わってないのにptだけが膨れて、もはやストーリーポイントの信憑性が崩れて意味が無くなっていきます。
2. チーム内の相互の助け合いが無くなる
   自分の速度が評価に直結している場合、究極チームの生産性が下がっても自分の生産性が良ければ評価されることになります。そうすると、入ってきたばかりのメンバーやジュニアなメンバーの育成に時間を使うより、自分のアウトプットに時間を使った方が良いと考え、チーム内で助け合う作用が無くなっていきます。

僕らの解決策

1. CTOが全設計に入る
   僕らの開発組織では、全部のプロジェクトの設計レビューにCTOの辻が入っています。 エンジニアの設計力向上を一番の目的としてCTOのレビューを通しているのですが、結果としてこのプロジェクトはこのくらいのptになるという基準も最終的にCTOが目を通すことになるのでptを過剰に見積もるということを防ぐことにもつながっています。 もっというと、「こういう設計にしたらこんなにポイントをかけなくても同じことが実現できる」みたいに、ポイント（＝工数）をかけずにビジネス上実現したいことを実現する意識もそこで鍛えることになっています。
2. ストーリーポイントの評価を全メンバー一律に適用しない
   ストーリーポイントによる評価は問題点がある一方で、自分がどれだけアウトプットを出せるようになったかを定量的に測る良い指標だと考えています。
   特にジュニアな時期ほどこのストーリーポイントで成果を見ることは分かりやすく成長を実感できるので、ジュニアメンバーの評価はこのポイントによる評価の割合を高めに設定することが多いです。
   一方で、ある程度力が付いてきたエンジニアに対しては自分自身の生産性もそうですが、チームの生産性に目を向けてほしいので、自分が見ているチームやメンバーの生産性向上を目標にしてもらってます。 そうすることで、結果的にチームの生産性を最大にする力が働くようにしています。

ちなみに、ベロシティはエンジニアチームの能力だけで上下するものではありません。例えば、ミーティングが多かったりしたらそのチームの能力に関わらずベロシティは落ちます。 そのため、一概にベロシティが遅くなったからダメという訳では無く、なぜその期間のベロシティが落ちたのか振り返って、その理由次第で評価に反映させてます。定量的に振り返る指標になるので、PDCAが回せて改善できるのがストーリーポイントの良いところだと思っています。

スキルマップに基づく行動の評価

ストーリーポイントで速度を評価しても、その実装したコードの品質が悪くてバグを産んでいたらどんなにスピーディな開発をしても意味がありません。

どのレベルのエンジニアがどのくらいのことをできて欲しいのかを、大きく設計力・実装力・コミュニケーション力に分けて言語化したスキルマップを用意しているのですが、それが実現できているのかCTOが評価しています。

具体的には3ヶ月に1回、全メンバーのPullRequestをCTOが見て、各個人にフィードバックするということをやってます。今はエンジニアが20人弱くらいの人数なので、CTOが直接見れているというのも、ベンチャーの良いところなのかなと思います。（CTO自身は大変そうですがw）

エンジニアリングの量を評価するのがストーリーポイントで、エンジニアリングの質を評価するのがスキルマップに基づくCTO評価になります。

チーム課題解決の成果の評価

プロジェクトの中で提案から設計・実装・テスト・リリースまでが主にエンジニアに担ってもらってる仕事ですが、お客様向けの開発だけじゃなく、チーム課題への取り組みも担って欲しい役割になります。

そのため、リーダーレベルからその時のチームの課題をチーム方針として設定されるのですが、それに対してどうアプローチするのかを考えて目標に入れてもらっています。

例えば、今はメンバーが増えてバグの発生率がこれまでよりも高くなってしまっているのがチームとして課題感があるところになってます。そこに対してts化を進める、テスト項目のマスタを整理するみたいな目標をおいて、チームとしてのレベルアップに寄与したものを評価に組み込むってことをやっています。

まとめ

今の僕らでいうと、「ストーリーポイントによる成果の評価」「スキルマップに基づく行動の評価」「チーム課題解決の成果の評価」が大きな評価項目になってます。

エンジニアのレベル・期待値によってこの評価項目の割合を変えたり、具体内容が変わったりしますが、大枠はこのフレームワークの中でやってます。

ですが、この評価方法が最適だ！これ以上なものはない！と思っている訳では無く、現時点で僕たちが考えうる最善なのではないかと思う基準で評価しているに過ぎません。なので、もっと良い方法が見つかったり、会社のフェーズが変わったりしたらより良い制度に変えていかなければならないと思っています。

最後に、まだまだエンジニア・デザイナーの方も積極的に募集中ですので、興味がある方はぜひまずはカジュアルにお話しできればと思いますので「話を聞きに行きたい」からご連絡をお待ちしております。