エンジニア評価制度の取り組みを振り返ってみた

はじめに

Rettyでは2018年から組織的な改善活動を数多く始めており、その一つにエンジニアフィードバック（以下、フィードバックはFBと省略します）制度があります。
本記事はRettyのエンジニアFB制度への取り組みの紹介を兼ねた、これまでの改善活動の振り返り記事となっています。

（2018, 2019年のアドベントカレンダーの小迫の記事に組織的な改善活動についての紹介がありますので興味がありましたらご参照ください）

engineer.retty.me engineer.retty.me

エンジニアFBは今なお半年の評価ごとに継続的に改善を繰り返していて、今は4回目の改善サイクルとなる2020年上期のエンジニアFBが終わった頃となります。

対象としたい読者

下記のような項目にピンと来る方に読んでいただけると嬉しいです。

• 会社のエンジニアが評価に対して不満を抱えており、他社の評価制度の取り組みに興味がある
• エンジニアへの評価をどのようにしていったらいいかわからない、といった場合の参考例

あんた誰？

RettyでEngineering Managerをしている櫻井 (@saku2saku)と申します。
Rettyの在籍年数は7年半くらいと、社内でも社歴はわりと長いほうです💪
そのため、この記事に書いた時期のほとんどを中からずっと見てきた一人でもあります👀

2018年から始まったエンジニアFB改善への取り組みの最初から参加してきたこともあり、このタイミングで一度振り返ってみたいと思い記事を書いてみました。

↓遅くなりましたが本記事の目次はこちらとなります↓

RettyにおけるエンジニアFB制度への取り組み

Rettyにおける評価制度の課題と取り組みの変遷

Rettyの評価制度の課題と取り組みの変遷をまとめてみました。

時期	課題	解決策	結果
2015年頃	人数的に社長で見れる数を超えた	個人目標(MBO)とPeerReviewの導入	半期の目標をメンバーと合意し、その結果に基づく評価が行われた
2018下期	サービスグロースのKPIにおける貢献成果だけで評価されることの違和感	エンジニア評価をエンジニアが行うようにした	納得度の高い評価を得られた人が増えた
2019上期	FBの工数がとても高い 成長に繋がるFBが得にくい	エンジニアFBのフロー簡略化 FBフォーマットを成長を軸としたものに変更	エンジニアFBの負担が減った 成長にフォーカスしたFBが得られるようになった
2019下期	FBの結果が評価に反映されていない感	エンジニアFBの結果が評価への影響するように会社の評価制度を変更した	エンジニアFBが評価に繋がるようになった
2020上期	評価シートの項目数が多すぎる 評価基準がわかりにくい	コンピテンシーの定義とそれに沿った評価項目へのFBフォーマットの変更	評価項目がシンプルになった

取り組みを始める前のRettyにおける課題

2018年当時、Rettyではエンジニアへの評価を個人目標とPeerReviewによる成果評価のみで行ってきました。
（PeerReviewとは360度評価とも呼ばれており、匿名で同じチームや別のチームのメンバーからRettyの行動規範(弊社ではRettyWayと呼称)についての評価をしています）

それらの評価方法に対して、エンジニアは以下のような理由で評価のたびにモチベーションが下がるといった想いを持つ人が出始めていました。

• エンジニアの現場のことをわかっていない人からのFBがつらい
• 匿名によるPeerReviewの納得感の薄さ
• 保有しているスキルとそれを発揮できる実務にギャップ
• Developer Experienceや仕組み化、負債解消といったところの成果に対する評価がない
• 具体的にどう改善（成長）していったら良いのかがわからない
• 一方通行でしか評価を受け取れず、アピールする機会がないことによる納得感の薄さ

これらの課題を解消するべくエンジニアFBのワーキンググループが発足しました。

Rettyにおける評価制度の歴史

2018年下期

取り組んだこと
解消した課題は サービスグロースのKPIにおける貢献成果だけで評価されることの違和感 をなくすことでした。
そのために、エンジニアの評価をエンジニアが行うようにエンジニアFBという制度をはじめました。

2018年下期に始めた当初は、納得のいくエンジニアFBをするという目的のもと下記のような評価フローにて実施しました。
説明をわかりやすくするため被評価者をAさん、評価者をB1, B2さんとします。

1. Aさんが評価シートを作成し、GithubにPushしてPull Request（以下、PRと省略します）を作成します
2. B1, B2さんが評価シートを見て、より詳しく知りたいところなどをPRのコメントとして記載する
   • 評価シートへのコメントがあった場合、Aさんはそれに対してコメントの返信か評価シートの修正を行います
   • Aさんからの修正やコメント返信に対して納得がいったらB1, B2さんはそれぞれPRにApproveをつけます
3. B1, B2さんから評価シートのPRのApproveを受け取ったら、AさんはPRをマージします
4. B1, B2さんがAさんに対する評価結果シートを作成し、GithubにPushしてPRを作成します
5. AさんはB1, B2さんからの評価結果シートを確認し、それに対して納得いかないことや補足説明などがあれば、PRのコメントとして記載します
   • 評価結果シートへのコメントがあった場合、B1, B2さんはそれに対してコメント返信か評価結果シートの修正を行います
   • B1, B2さんからの修正やコメント返信に対して納得がいったらAさんはそれぞれPRにApproveをつけます
6. Aさんから評価結果シートのPRのApproveを受け取ったら、B1, B2さんはPRをマージします

改善されたこと
結果としては、納得度の高い評価を得られた人が期待通り増えました。（下図はアンケート結果より抜粋）

初回のエンジニアFBのアンケート結果の抜粋

新たに生まれた課題
アンケート結果で多くあがった声として、フローが複雑な上にとても時間がかかるという課題が出ました。
初回の取り組みということもあり、納得感というのに重点を置いてフローを考えてみた結果必要以上に複雑なものになってしまいました。
また評価シートのフォーマットとして、半期でやったことベースで記載するようになっていたため、得られるFBがやったことを褒めるだけで成長に繋がりにくいという課題もあがりました。

2019年上期

取り組んだこと
解消したい課題は下記の2点です。

1. エンジニアFBの工数がとても高い
2. やったことを褒めるだけで成長に繋がりにくい

まず工数かかりすぎ問題については以下のポイントを改善し短縮化しました。

• 双方向にPRを作成していたのを、被評価者が評価シートを作成するときのみPRを作成するようにした
• 評価結果シートに関して気になる点がある時には個別にコミュニケーションをとって解決する

次に、やったことを褒めるだけで成長に繋がりにくい、という課題ですがこれは評価シートと評価結果シートのフォーマットの見直しを行いました。 これまでの評価シートと評価結果シートでは半期に何をやったか、ということにフォーカスしており成長に関してフォーカスできていませんでした。 そのため、その人が仕事を通してどういったところで成長したのかを具体的な仕事のエピソードを交えて書いてもらう、というように変えました。

改善されたこと
まず評価フローの簡易化により、大幅にエンジニアFBにかける時間が減りました。
それまでのフローでは待ち状態となってしまう箇所が多く無駄に時間がかかってしまうことも多くありましたが、それもほとんどなくなりました。

評価シートのフォーマットを成長をテーマに変えたことで、その人がそれまでに比べてどう成長できたのかを意識できるようになりました。 またそれに応じて、さらに成長するためのFBといったことも評価結果シートに記載されるようになり、今後どう成長していけばいいのか、というFBも得られるようになりました。

新たに生まれた課題
成長に向けた評価を得られた一方で評価への影響が限定的なため、時間をかけてFBをやるモチベーションが湧きにくいといった課題もあがってきました。

2019年下期

取り組んだこと
解消したい課題は2018年下期から課題としてあがっていた FBの結果が評価に反映されていない感 です。 また表立って課題として上がってはこなかったのですが前半期で成長をテーマに書くようにしたこともあり、会社における理想のエンジニア像について考え、それを評価シートに取り入れようという取り組みが行われました。

改善されたこと
FBの結果が評価に反映されていないという課題に対し、最初の活動から1年が経過したこともありその間にVPoEの小迫が評価制度の変更を働きかけてくれました。
結果、この半期からエンジニアFBの結果が評価に影響を与える仕組みに変わり、エンジニアFBの位置付けも以前に比べると重要なものとなりました 🎉

また、この半期ではRettyにおいて活躍できるエンジニアとはどんな人なのかについてをEMを中心に考えました。 リクルートの6つのスキル・4つのスキル、CircleCIのコアコンピタンス、Opt Technologiesの評価制度など様々なものを参考にさせていただきながら最終的には下記の8つの項目を定義して言語化しました。

技術力, 分析力, デリバリー（価値を届ける）, ドメイン力
影響力, チーム開発（チームワーク）, 育成力, リーダーシップ

それにあわせて評価者は上記の8つの項目から最低1つ最大3つの項目を選んで、自分の成長をアピールするという評価シートのフォーマットに変更しました。

新たに生まれた課題
今回改善点となった理想とするエンジニアの評価項目を評価シートに取り入れたはいいものの、項目が8つと多くなってしまったため数が多くて選びにくいという声が多くあがりました。

2020年上期

取り組んだこと
2019年下期の課題としてあった、評価シートの評価項目の数が多すぎて選びづらいという課題に対して、コンピテンシーの定義とそれに沿った評価項目への変更を行いました。
2019年下期に作成した評価項目はたくさんあるものの、本当に重要なものはどれなのかや重複している観点もあったため、Engineering Manager中心に協議し最終的に4つの項目に絞り込みました。
絞り込みを行う上ではCircleCIのコンピテンシーマトリクスの記事をかなり参考にさせていただきました。

この頃になると4回目ということもあり、評価シートを書くということ自体も全体に浸透してきました。

改善されたこと
求められるエンジニア像がより明確化されたことで、どんな方向性に成長していけばいいのかについてが以前に比べてわかりやすくなったと思います。 また、これまでと比べて運営にかかるコスト（評価委員会の活動にかかる時間など）が圧倒的に減りました。

新たに生まれた課題
これはちょうど現在評価が終わったばかりということもあり、今後改めて振り返りを行う予定です。

今後について

これまで半期ごとに改善活動をしてきましたが、今後も同じように続けていく予定です。 現状予定されていることとしては定めたコンピテンシーを評価のレベルに沿ってコンピテンシーマトリクスへと変えていくことを考えていたりします。

それとこれは持論ではありますが、会社が求めるエンジニア像を明確化し、エンジニアが会社でキャリアを築いていくうえでの指針とできるように整え、エンジニアFBはそれをサポートして後押しをしていける取り組みとして改善を継続していきたいと思っています。

まとめ

Rettyにおいて2018年から始めたエンジニアの評価制度についての取り組みについてご紹介しました。
過去にどのような課題があり、どのような解決策をもって改善を行ってきたかについて、半年ごとの活動についての紹介を行いました。
今後も改善活動を続けていき、Rettyで仕事をすることを通してエンジニアが自身の望むキャリアを見つけ歩んでいけるようにしていきたいと思っています。

また、参考までに2020年上期で使用した最新の評価シートテンプレートについてもGistで公開します。
Rettyエンジニアフィードバック_評価シートテンプレート_202004

おわりに

2018年下期からのエンジニアFBを行うにあたって協力してくれた評価検討委員会のメンバーおよび評価制度に参加してくれたエンジニアメンバーのみんなに感謝を。 また、私が社内でこの活動をするキッカケとなったVOYAGE GROUPの社外評価者制度に声をかけてくれた坂田さんと、2018年下期の最初の活動の際に相談にのっていただいたVOYAGE GROUPの小賀さんには本当に感謝しております。

これからエンジニアFBに取り組む方へ

これから評価制度に関する同様の取り組みをされようとされる方がおられたら以下のポイントを認識しておくと良いかと思います。

1. 本業以外のMTGの時間が沢山かかる
   • 思った以上に時間がかかる
   • 初回は型も何も存在しないところから始まるためかなりの苦労がある
2. 味方は大事
   • 同じ課題感を抱いている熱量の高い仲間を見つけ一緒に頑張る
3. 小さく始める
   • 影響範囲は徐々に大きく
   • RettyにおいてエンジニアFB制度は評価とイコールではなく、評価の一部という位置づけとなっています
     • 現在は2018年の下期に始めた頃よりもだいぶ評価への影響度合いは増しています
     • あわせて、一部のマネージャから参考になるという声ももらえるようになってきました
4. 議事録や文書化しておくことがとっても大事
   • 下記の資料を作成してすぐに見つかるようにしておくと便利です
     • その時の組織の状況と抱えている課題
     • ミーティングの議事録および、次の半期の改善活動を行うメンバーへの引き継ぎ資料

もっと詳しく知りたいのだけど？

最初は2018年下期の取り組みのときだけの記事を書いてみようかと思いましたが、それだと結局全体としてやってみてどうだったのさ？というのがよくわからなくなるかもと思い、記事をこれまで一連の活動に対する振り返りの内容に変えました。 結果半年ごとの取り組みで行っていたことの情報量はかなり減ってしまいました（多分半期の活動の詳細記事だけでこの記事と同じかそれ以上のボリュームで書けますw）が、こちらの方が記事としては良かったのではないかと勝手に思ってます。

とはいえ、詳しく知りたいぞ、という人にとってはもしかすると内容が薄まりすぎてちょっと物足りなさを感じられたかもしれません。 もし半期ごとの詳細記事を読んでみたいぞ！とかの反響が万が一あるようだったらその時はまた記事の作成をしたいと思います。

この活動において参考にさせていただいた様々な記事

• 2018年下期の活動
  • VOYAGEのエンジニア評価制度の全貌。「技術力評価会」による、人が育つ組織の作り方 | SELECK [セレック]
  • はてなのエンジニアに期待する「アウトプット」 - Hatena Developer Blog
  • 「給料の見える化」記事にホラクラシー企業の見解をぶつけてみる - Kozo Takei's Blog（武井浩三のブログ） | 「組織クリエイター」自然の摂理に則った自然経営(じねん)
  • エンジニアの評価基準、短期評価をやめてみたら？ | サイボウズ式
  • エンジニアの評価制度について - console.blog(self);
  • エンジニア評価のしくみをイイ感じにいじりましたであります | ジンジン（ペパボ人事のブログ）
  • ペパボのエンジニア評価制度を、社内の一般エンジニアはどうみているのか？ - 彼女からは、おいちゃんと呼ばれています
  • プログラマー風林火山 : 小野和俊のブログ
  • エンジニアのキャリアパスと役職定義 | GMOメディア エンジニアブログ
• 2019年下期の活動
  • 企業インタビュー｜リクルートホールディングス： 「起業家精神を持ち、成長し続ける人材」をいかに育てていくか？ - 『日本の人事部』
  • 【評価期間だよ全員集合】Opt Technologies の評価制度について - Opt Technologies Magazine
• 2020年上期の活動
  • Engineering management - CircleCI's engineering competency matrix | CircleCI