キャディのテクノロジー本部でエンジニアリングマネジメントをしている むらみん (@mura_mi) です。 Tech Blog ではありますが、技術者をマネジメントする立場として、最近取り組んだ 評価制度の改善についてご紹介します。
大事な話を先に！
キャディでは、各領域のソフトウェアエンジニアのみならず、 エンジニアリング・マネージャーも絶賛採用中です!! この記事で紹介しているような、エンジニアリング職メンバーの生産性やキャリア開発に直接関わるような仕事を日々頑張っています。少しでも興味をお持ちいただけたら、当ブログ右上のリンクや、Wantedly の求人記事からカジュアル面談申込みいただけると幸いです。
状況
キャディには "HELIX" という人事評価制度と, ミッショングレード制度があります。
https://twitter.com/yushirodesu1/status/1266729912192270338?s=20
これは社員数がかなり少ない時代から整備され運用されてきたものであり、この制度に基づいた四半期ごとの人事評価 (正式評価は半期ごと) はすでに1年以上運用されていました。私自身、前職のスタートアップ企業にて評価制度やグレード制度が無いまま組織が拡大したことの負の側面も体験していたので、これらの制度の存在を知った際には良いことだなと素直に感じました。
一方で、HELIX 自体は制定当時のキャディの人数構成比もあり、ビジネスメンバーの評価に重きが置かれていた節がありました。具体的なポイントは後述しますが、ソフトウェアエンジニア (以下、単純にエンジニアと呼びます) のメンバーが増える中でそのギャップを早めに埋める必要がありました。
また、エンジニアメンバーが増えていったことで、それまでの「CTO ひとり による全エンジニアの評価」に様々な課題が生じていました。 CTOも人間なので与えられた時間は有限であり、エンジニアのヘッドカウントが20人を越えたあたりで、「CTO ひとりが全員の自己評価に目を通し、全員のアウトプットを直接確認して評価を下す」という運用には限界が来ていました。単純に評価対象者が増えたことだけでなく、人数が増えることで、CTOが普段の仕事を直接見る機会が少なくなったことも難しさの背景でした。そこで、自然と、テクニカルリード的な役割を果たしているメンバーを評価者に任命し、評価という行為を組織の機能に埋め込もう、となりました。
こういった課題について CTO の小橋と私が話し始めたのが2020年6月頃で、2020年9月の評価期に間に合うように評価制度運用の改善に着手しました。
やったこと
まず、評価制度運用の改善に取り組むことをエンジニアのメンバーに伝えつつ、CTO判断で評価者となるメンバーを決めました。このときのアナウンスは社内Wiki (Docbase) に内容をまとめつつ、定例ミーティングにてスライドモードで表示しながら説明しました (以下一部抜粋)。
その後、実際に行った取り組みは、細かいものを挙げるとキリがありませんが、大きなアクションは以下の2点でした。
- 評価水準の適度な具体化
- セルフレビューシートの改善
それぞれ詳説します。
評価水準の適度な具体化
キャディのエンジニア向けのミッショングレード (以下, MG) は、「技術力(専門性)」「価値提供」「組織貢献」の3つの評価軸から構成されています。(以下は社内向け資料より抜粋)
しかし、MGの評価軸と、各軸の水準に関する記述は以前より設けられていましたが、その記載内容は比較的ファジーでした。その記載を元にこれまでどのように評価を下していたかを素直に述べると、それは CTO のさじ加減でした。実際、取り組む問題が移ろうスピードも早く、エンジニアリング組織としての熟達度も高まりきっていない中、業務の中で重視されるスキルや働き方を敢えて予め定義せずに、評価を CTO の判断に任せるというのは一定の合理性がありました。
また、「CTO が評価を一人で回すこと」の大きなメリットのひとつは、評価基準が一貫し、被評価者間での評価結果のズレが起きづらかった点です。複数人で評価を回すことで、評価結果が評価者によって高く or 低く付くという傾向を後から調整する必要が出てきますが、予めそのブレが生じないような工夫ができるならしたいものです。
そこで、ミッショングレード水準の記述について「評価要素の分解および具体化」と「記述の適切な詳細化」をすることにより、評価者間での目線を揃えやすくするようにしました。
具体的には、以下のステップで評価要素の分解と詳細化を行いました。
- 直近の評価 (CTO一人で行ったもの) の評価結果の理由についてヒアリングする
- 評価要素の候補となるものを洗い出して、仮で評価要素と水準のマトリクスを作成
- 仮で作ったマトリクスに従って、2020年6月時点のメンバーの評価を改めて行ってもらう。 (これを "バックテスト" と呼びました) ・・・①
- バックテストの内容を鑑み、「実は評価には大きな意味をもたらしていない」要素のあぶり出しや、評価水準の記述の改善を行う ・・・②
- 上記の①→②を2回ほど繰り返して一旦確定
この MG水準 の文書化にあたっては、CircleCI の Competency Matrix が大いに参考になりました。
また、このMG水準の具体化に取り組むにあたり、以下の点に注意しました。
適度な抽象化/具体化
具体的すぎると、スキルや実績の星取表となってしまうが、ミッショングレードは従業員に期待する職責の表現であるべきであり、ある程度、マネジメントや評価者による主観やメッセージを入れられる余地を設けたい。一方で、抽象的すぎて解釈の幅が拡がりすぎてしまうことは避けたい。
過度に厳密性や客観性にこだわらない
人事評価は「最強の評価関数づくり」ではない。メンバーが評価内容や報酬に納得感を持ち、成長支援につながることがメインミッションであることを常に念頭に置く。
評価基準の「刷新」ではなく「明文化・形式知化」
これまでの評価要素を明文化して、これまで行っていた評価を CTO に過度に依存せずに行えるようにすることが目的。今回のプロセス見直しが理由で過度に「評価されるようになった」「評価されなくなった」と思うメンバーが極力出ないようにする。
セルフレビューシートの改善
HELIX では、評価期間の終わりに「セルフレビューシート」に自己評価を記入して評価者に提出し、評価者はこれをベースに評価を行います。 このレビューシートは、個人レベルまで OKR や実績数字を事細かにトラックするビジネス職メンバーの評価を主眼としたものでした。そのため、「期初に建てた評価軸ごとの目標」と「目標達成のために行ったこと」を記入するフォーマットとなっていました。
これが、エンジニアリング職のメンバーが記入するには少々不便なものでした。キャディのエンジニアの仕事には、数字には表れない部分も含めた技術的投資の判断をすることが求められたり、計画に追従することより変化に対応したり、複雑な業務をチーム全体で理解・モデリングしながらの価値提供といった定性的な側面が重要であると考えています。実際、期初に立てた目標の通りに行動できたかを検証するフォーマットであったが故に、期中に生じた突発的な対応についてセルフレビューにて全く言及されない、という現象も過去の評価ではしばしば発生していました。
そこで、エンジニア向けのセルフレビューシートのフォーマットを少々改良し、「期初に建てた評価軸ごとの目標」と「各MG評価軸についての自己評価」の間に、「期中の主な仕事について振り返る」セクションを設けました。これは、いわゆる "アジャイル開発" における振り返りにおいて、アイディアを出す前にデータ (事実) を収集する ステップに似ています。 3ヶ月に渡って濃い時間過ごしていると、評価対象期間の序盤については記憶が定かではないこともよくあるので、GitHub の評価期間中の Pull Request 一覧や、Docbase (社内用wiki) に期中に書いた記事一覧を確認できるようなリンクを設けるなどの配慮をしました。
実際、メンバーの Slack times チャネルを見ていると、この変更はかなり好評だったようで、企画冥利に尽きました。実際、評価する側にとっても実際に書いたコードや Pull Request などのアウトプットを確認するポイントを絞って重点的に見ることが出来るようになり、印象での評価や「振る舞いが目立った者の勝ち」な評価を防ぐ上でも大きな助けになりました。
やってみてどうだったか
これらの取り組みを経て、2020年9月末のエンジニア評価はなんとか無事完了しました。次回以降、しばらくは今の仕組みの微修正で評価プロセスを回していくことは出来そうです。 (初回特有のモタツキも次回以降改善できるはず！) また、ちょうど現在、キャディのテクノロジー本部では評価結果の被評価者へのフィードバックの真っ最中であり、実際にメンバーがこのプロセスを経験してどう感じたかの意見はヒアリングしなければなりません。 そして当然ながら、人事評価制度の良し悪しは、短期的な視点よりも、その制度の上でメンバーが実際に成長していったかどうかが重要です。評価自体は目的ではないことを忘れず、今後も、組織の状況を踏まえて柔軟にアクションを取ってゆく必要があるんだろうなと考えています。特に、ミッショングレード水準の記述は継続的に見直していく必要があるでしょう。
加えて、思わぬ副作用として現れたのは、MG の要素分解や詳細化を行ったことで、採用面接がスムーズになったことでした。採用面接の質問項目や、どのような側面をどの程度深堀りするかはいつも悩む難しい問題なのですが、MG表として明文化した評価要素を念頭に入れることで、社内での具体的な活躍イメージや期待を持ったり、その期待が妥当なものかを確認する面接が出来るようになってきました。これは、スクラムに於いて完了の定義 (Definition of Done) に基づいてスプリントバックログを書き出す作業に似ているな、と感じました。
というわけで
自分自身、前職にてピープルマネジメントに従事していた時期はあったものの、ここまで人事企画的な仕事に携わったのは初めての経験だったので、非常に刺激的でした。 キャディのエンジニアリング・マネジメントは、今回紹介したメンバーマネジメントのみならず、チームビルディング、プロジェクトマネジメント、開発プロセスマネジメントといった領域でその時々の課題を解決しています。 未だエンジニアリングマネージャーがいない (けど、課題が山積みな) チームもあります。興味を持った方は、ぜひカジュアルにお話できれば幸いです。
それでは。
