誰向けの記事？
EM（Engineering Manager）の方に向けた記事です。
ただ、一般的な評価者全般にあてはまる内容を書いているので、評価を行う方なら誰でも参考にできると思います。
評価をする側ではないけど、どんな気持ちで自分のマネージャーが評価しているのか知りたい！といったエンジニアの方にも楽しんでいただけるかもしれません。
要約
メルカリエンジニア組織で、評価の負荷を削減しつつ、品質をあげるために、「Continuous Feedback」という仕組みを導入しました。
Continuous Feedbackは、通常よりも高い頻度でフィードバックを行うことで、負荷分散や、フィードバックサイクルの高速化などをはかる手法です。
導入した結果、評価に対する満足度や、評価を自身の成長に使えてると感じるようになったメンバーがとても増えました。現在では多くのEMの方が、評価に利用してくれています。
自己紹介
メルカリ Engineering Office マネージャーのhiroiです。 我々のチームでは「全てのエンジニアに最高の従業員体験を」というミッションを元に、様々な活動を行なっています。あまり馴染みのないチーム名だと思いますが、もっと詳しく知りたいという方は、こちらの記事で活動の紹介をしています。
ここ2年の間、組織改善の一環として、評価周りの改善に大なり小なり関わり続けています。そこでマネージャー向けの社内研修の一部講師を担当するなど、メンバーとともに様々なことに取り組んできました。その中でも効果が非常に高かったものの1つ「Continuous Feedback」を紹介します。
そもそも良い評価って？
評価は大きく分けて、2つの役割があると思っています。
- 成長促進
- 会社への貢献度の可視化（アウトプットや行動など全て含む）
もちろん組織によっては他にも役割を定義していたり、役割をさらに細分化していたりすると思いますが、私が一番重要だと思っている役割は上の2つです。
「評価」という単語自体は「価値を見定める」という意味で、ここで紹介している後者の意味合いが強いです。しかし、昨今、前者の成長促進の役割が大きくなり、その重要性は増してきています。メルカリでは、成長促進のための評価、およびフィードバックが行われることがマネージャーには期待されます。まずは、この2つの役割ごとに、良い評価とは何かを考えてみます。
成長促進のための評価
まず、成長促進のためには、「何が良いことか」「何が改善できる点か」を共有することで、気付きを与えることが基本です。何が良いことかを知ることによって、その行動をより行おうという意識づけができますし、改善できる点を知ることで、アクションを変えることができます。
この時、良い評価になるかどうかの分かれ道の1つとしてあげられるのが、フィードバックがアクショナブルであるかどうか、という点です。アクショナブルかどうか、つまり実行にうつしやすいか、何をすればいいかが明確かどうかです。例を見てみましょう
例1
「最近いい感じだよね！その調子で頑張って！」
これはアクショナブルとは言い難いです。フィードバックを受ける側が「最近この点を改善したからかな？」といったように心当たりがあるかもしれませんが、それがフィードバックを与えた側ともらった側で一緒とは限りません。モチベーションはあげてくれているかもしれませんが、気付きを与えているとは言えません。何を継続して実行すればいいのかが不明瞭です。
例2
「最近、議事録のとり方が良い感じだよね！」
何について話しているかがわかりましたね！ここまで情報があれば、議事録を今のままのやり方でやればいいんだ、となります。少しアクショナブル度が上がった気がします。
例3
「最近、議事録が読みやすくなったね！前と比べて、ポイントポイントで、箇条書きを使うようになったのが見やすい。あと、最初にサマリつけてくれたのがすごい良いと思う！」
少し長いフィードバックに見えますが、何が良かったのかが、より明確になりました。箇条書きを使った点、サマリを使った点の2つが良かったようです。この2つに関しては引き続き行った方が良さそうだ、という気づきを得られます。アクショナブルなフィードバックだと言えるのではないでしょうか。
貢献度可視化のための評価
貢献度の可視化に関しては、会社ごとにそれぞれ異なります。基準や、可視化の方法が異なるからです。基準が文書化されていることもあれば、不明瞭であったり、もしくは文書化されているけれども、実際は使われていない、ということもあります。可視化の最終方法がコメントなどの定性情報で終わる場合もありますし、A、B、Cもしくは、1, 2, 3のような定量的なレーティングを利用している場合もあります。
どのような方法にせよ、多くの場合、貢献度の可視化に重要なことは納得度です。このくらいの貢献をしていると思う、だからレーティングはCだと思う、といった形です。この際に、評価をされる側が「いや、私はBだと思っている」となると、納得度が下がります。なぜCだと思うか、なぜBだと思うか、すり合わせが必要です。
どうしたら納得度が高い良い評価ができるのか。重要な点が2つあります。事実に基づいているかどうかと、明確な基準と照らし合わせているかです。また例をあげてみようと思います。
例1
「最近、仕事が遅い気がする。期待値と合っているとはいえない」
仕事が遅いかどうか、というのが感覚で言っているように聞こえます。実際に遅れたことがあるのかもしれませんが、事実かどうか、というのを明確には提示できていません。また、基準も不明瞭で「期待値」が何なのかがわかりません。メンバーが「どの仕事のことを言っているんですか？」などと、積極的に発言できるタイプならいいですが、マネージャーにそういった反論をしづらいと感じる人も多いです。気づかずにストレスだけを溜めて、終わりになっているかもしれません。
例2
「Aの仕事に関して、予定より一ヶ月以上遅れていた。原因として、設計時にCのことを事前に想定できていなかったことがあげられる。君のレベルだと、設計含め、十分にユースケースを想定した上で、仕事ができることを求めている。」
事例に加え、それがどれくらい遅れたのかという詳しい情報、更に原因まであるため、責任の所在がどこにあるかの説明がされています。また、どのくらいの期待値が求められているかもより明確です。この期待値に関しては、会社や組織側で出来る限り文書化したものがあると、マネージャーとしては評価が楽になることが多いです。メルカリのエンジニア組織ではEngineering Ladderがこれにあたります。
もちろん、現実の評価はこんなに簡単なものばかりではないのですが、アクショナブルであること、事実をベースにしていることが、良いフィードバックにとって重要であるということが伝わっていればOKです。
Continuous Feedback（継続的評価）とは
メルカリのエンジニア組織では、評価やフィードバックを短いサイクルで、定期的に行うことを、Continuous Feedback（継続的評価）と呼んでいます。非常にシンプルですが、とても効果がある手法です。
例えば、メルカリのエンジニア組織の場合、月1前後のContinuous Feedbackを推奨しています。通常の評価は半年に一度ありますが、それを6個の小さい評価に分ける形です。
メルカリエンジニアリング組織でのContinuous Feedbackの頻度。毎月、毎週、隔週の順に多い
もちろん、毎月1度、評価を自分の中でまとめる、文書化するというだけでも価値がありますが、メルカリのエンジニア組織では以下のような形で行うことを推奨しています。
- EMがメンバーに対しての評価を書く
- メンバーは自身に対する自己評価を書く
- それぞれ書いたものを30分程度のミーティングで共有し、認識ズレがないかや、どういった点を改善できそうかといったことをディスカッションする
私はこの自己評価があるという点が気に入っています。フィードバックは一方通行になりがちですが、本来は評価を受ける人が成長するための、マネージャーとメンバーのコラボレーションになるべきです。自分で評価を行い、それをマネージャーが客観的な視点で見た評価とくらべることで、新しい改善点や強みを一緒に発見することができます。
Continuous Feedbackがなぜ効果的か、我々がなぜ推奨するのか。1つずつポイントを説明しようと思います。
鮮度があがる
意外と見落とされがちなのですが、評価において最も重要なものの1つが鮮度だと私は考えています。なぜなら、どんな評価、どんなフィードバックをするにしろ、それは特定の出来事、特定の事実に対するリアクションであり、その事実や出来事に対する人間の記憶や印象は、時間とともに薄れていくからです。
記憶が薄れていくことで、そもそも何があったのか、思い出しづらくなります。半年分の評価をしていて、ここ1、2ヶ月のことばかり書いていると感じたことはありませんか。昔のメモなどを頑張って引っ張り出したことはありませんか。何ヶ月も前の出来事を鮮明に思い出せるという方は少ないはずです。せっかく良い行動、もしくは改善点を見つけたのに、それを忘れてしまうのはもったいないと思いませんか。
仮に評価をする側が思い出せたとしても、評価を受ける側が思い出せなかったり、ほとんど印象に残っていなかったらどうでしょう。それは事実として感じづらいですし、実感として受け止める際の理解度が下がる可能性があります。
頻度をあげることで、話す対象の期間を絞る、それにより評価者は思い出しやすくなる、聞く側も、思い出しやすいですし、その結果、納得しやすくなる、という効果が期待できます。もちろん事実の認識が評価者とズレている場合も、簡単に思い出せますし、認識の差異を修正するのも、簡単になります。
負荷を分散できる
評価は給与などを決める非常に重要な仕事ですし、特にネガティブな内容を伝えるのは気が重いという方は少なくないと思います。また、そもそも数カ月分の内容を整理する手間もかなりかかります。評価期間の前後に忙しい仕事がある場合など、精神的に非常に大きな負担になったという経験をしたことがある方もいるんじゃないでしょうか。「そうだ、この時期は評価と重なってるじゃないか」といって頭を抱えているマネージャーを私は何度も見たことがあります。
これを例えば月1でContinuous Feedbackを行っていると、毎月少しづつ評価の結果がたまっているため、その内容をまとめて、総括を加えるといった簡単な作業だけですみます。昔の出来事も既に一度伝えている内容のため、簡単に思い出せます。何ヶ月も前のことを、様々な資料やスケジュールを確認しながらうんうん悩む必要はありません。
一回一回の時間はもちろん個別にかかりますが、評価という精神的にも、時間的にも、負荷が大きい仕事を分散できるので、実際にやってみると負荷が減ったと感じるEMが非常に多いようです。
一回のContinuous Feedbackに、EMがどのくらい時間をかけているかという情報。30分未満がほとんど
サプライズを避けられる
評価の頻度が半年、一年といった長い期間だと、評価を受ける人にとって、その評価はサプライズになりやすいです。普段から評価を受けていないので、良いのか悪いのかはなんとなくの雰囲気で判断されがちです。人によっては「特に注意されていないし、悪くはない評価だろう」と思っていたり「あの仕事は上手くいったし、良い評価なんじゃないかな」といった形で、強いエピソードに気持ちが引っ張られていたりします。
これがある程度短いスパンで評価していると、そもそもマネージャーとメンバーがどう思っているかを小出しにしているので、そういったサプライズが非常に起きづらい状態になります。プルリクエストやリリースと同じで、小出しにすることで、ビッグバンリリースを避けられるし、サプライズや認識の違いが見つかったとしても、小さいうちに、問題に対処できます。
やってみるとわかるのですが、このサプライズをきちんと避けて丁寧にやるということで、評価する側とされる側の信頼関係の向上に非常に効果があがります。仮に同じ悪い結果だとしても、納得度が全く違うからです。納得度に関しては、メルカリのエンジニア組織で定量的に数値をとったものがあるので、後ほどご紹介しようと思います。
成長サイクルが早く回る
評価が年に1度、2度しかない場合、改善の機会、速度感としては決して早いとはいえません。そもそも評価の際に「こういう点を改善してほしい」と言われるよりも、評価前に改善点を伝えられて、それを実行する機会を与えられた方が良いはずです。
また、課題に気づいたからといってすぐに劇的に改善するというよりは、徐々に改善したり、改善の方法に工夫が必要だったりと、そう簡単にはいかないことがほとんどです。改善点を伝えた後に、それが上手く回るかを見て、次の手をうつ、リリースや、PDCAサイクルと同じように、評価と改善も、同じように何度も何度も回すことで良くなっていきます。年に1度、2度ではなく、もっと早いサイクルを回すことで、より大きな成長の後押しが可能になります。
メルカリでの取り組みの結果について
このようにさまざまな点で効果が期待できるContinuous Feedbackですが、メルカリのエンジニア組織では実施を始めて1年ほどになり、今では半分以上のEMが積極的にこのやり方で評価を進めてくれています。
このContinuous Feedbackを始める際、我々は仮説として上に述べたようなことを考えており、上手くいくと思っていましたが、実際の結果としてどうだったかを調べるために、評価に関する定期サーベイの結果を確認し、Continuous Feedbackを利用したメンバーと、そうでないメンバーで、どのような差異が発生しているかを確認しました。
期待は我々の想像以上のものでした。全ての質問において、我々がメトリクスとして数値向上を目指している、肯定的な答えを選んだ人の比率が向上したからです。
Continuous Feedbackを行った際の分析結果の資料の抜粋
全体的に良かったのですが、特に著しい効果として、マネージャーからのフィードバックの内容を成長に利用できたと感じる人が約20%増えていた点、定量的に書けたと感じる人が約30%増えていた点があげられます。
前者に関しては期待していた方向性だったのですが、定量的に書けたというのは我々の想定していなかった大きな副次効果でした。これはコメントなどから我々が考えた仮説なのですが、評価に対する理解度が上がったことにより、より評価の会話をしやすくしたり、目線合わせに対する意識もあがり、目標設定の定量化が進み、このような結果になったのではと思っています。
正直あまりに結果が良すぎたので、Continuous Feedbackを行ったマネージャー達が、そもそも評価が上手い人に偏っていたのではと考え、それぞれのチームの過去の結果とも比較したり、色々他の要因も調べたのですが、やはり明確に結果は良くなっていました。定性情報として、この取り組みに関わるコメントも一通り読んでみたものの、細かい仕組みに対する改善要望はありつつも、ほとんどが肯定的なものばかりだったため、どうやら本当にこれだけの効果があるらしい、という結論に至りました。
また、上記のサーベイとは別に、Continuous Feedbackを導入した人たちに、「どんな点が良いと感じるか」というサーベイをとった結果は以下のようなものでした。
- フィードバックされた内容を、次のQをまたずに行動に取り入れられた： 44%
- 評価記入の時間を短縮できた： 42%
- 評価にかかる時間を、評価期間に集中させずに期中に分散できた： 37%
- フィードバックの機会を損失することが防げた： 33％
- Ladderの解釈や理解を上長と揃えることができた： 33%
改善が早く回るといった点や、評価記入のコストを下げられたことや、評価自体を分散できたことに良さを感じている人が多いようです。
ちなみに、うちの組織すごい良いな！と思ったことなのですが、この仕組みを導入する際、我々は半年後に20%くらいの人に使ってもらうことを目標としていました。そのくらいのデータがあれば最低限のABテストができると考えたためです。大した認知活動はせず、Slackでの共有や、幾人かのEMに声をかけた程度だったのですが、我々の想定を大きく超えて、半年後には、半分以上のEMが使っていました。新しいものを好み、行動力が高いEMのみなさま、いつも本当にありがとうございます。
利用していて気づいたこと利用していて気づいたこと
ここまで良いことを中心にお伝えしてきたContinuous Feedbackですが、利用する際の注意や、効果が薄いと感じられるケースもありました。
効果が薄いケース
まず効果についてですが、評価に対する納得度が低い人に対して行うと、納得度が急激にあがる傾向があり、効果が高いようです。逆に、元々評価に対して納得度が高い、満足度が高いという方に対しては、強い効果を発揮しないことがあります。
また、あくまでマネジメントスタイルの一環であるため、我々はこの手法を全員のEMに強制するといったことはしていません。利用しないEMもいますし、一部のメンバーに対してのみ行っているという方もいます。よく聞くのは、若手や、入社して間もないメンバーにだけやっているという声です。評価やお互いの理解度をあげるために役立つため、そういったメンバーには重点的にやっているというEMが多いようです。私の体感的にはシニアメンバーに対しても十分効果があるのですが、効果が比較的薄いと感じるEMもいるようでした。
利用する際の注意点
注意点については、大きく2つあります。1つは、マネージャーときちんとすり合わせていたとしても、それより上のレイヤーとのすり合わせをしているわけではないという点です。マネージャーが最終的な評価を決定するのではなく、その上司が決定するといった場合に、せっかくマネージャーと丁寧にすり合わせても、その上司との認識がズレるということが発生することがありえます。
ただ、これは同じように、マネージャーが更に上のマネージャーと、同じようなことを定期的に行うことで避けることができます。また、Continuous Feedbackによって、多くの場合、評価の理解度があがるため、メンバーに対する評価をなぜこうしたのか、という説明力もあがっており、リスクを下がられることがほとんどだと思います。
もう1つは、エピソードに寄りすぎて、全体の評価として発散しやすくなってしまうことです。例えば私の場合、ひと月前のことを思い出すのも正直記憶力に自信がないため、良い行動だな、と思ったことや、これは改善点だな、と思ったことは逐一メモをとっているのですが、このメモが集まると「私が感じたリアクションのまとめ」になります。これをそのまま全部伝えると、そもそもフィードバックの量としては多すぎたり、全体として何を改善していいのかがわかりづらくなるといったことがありました。
これに対応する策として、メンバーと「どういった点を伸ばしていくといいか」というフォーカスポイントを事前に話しておいて、それに関わるフィードバックがあれば、そこを重点的に行うということで、議論や成長の方向性が発散することを避けるようにしています。
今後のねらい
EMからメンバーに対してのContinuous Feedbackについてはマイナーチェンジは行うかもしれませんが、大枠としてはしばらくはこれで良いと考えています。EM向けのOnboardingなどにも今後は取り入れていき、継続して有効に使われるための仕組み作りを進めていく予定です。
評価周りに関して、まだ伸びしろがあるなと強く感じているのは、Peer Review（同僚間の評価）です。メルカリでは同僚同士で評価をすることができるのですが、以下のような課題があげられます。
- お互いのグレードを知らないため、期待値をそもそも持てない
- 関係性に気を遣いすぎてどうしても良いことばかりを書きがち
- 頻度が高くないため、評価時期の直前のイベントにエピソードがよりがち
Peer Review自体は、色々な人から意見や気付きを得られるきっかけとなっており、本当に良い仕組みだと思うので、より良い形にできればと考えています。
評価やフィードバックは気の重い仕事ですし、正直、楽しいことだとはあまり思いません。ただ、メンバーを成長させるためにマネージャーに出来る、数少ない直接的な場ですし、処遇決定という意味では、相手の人生に影響しうる、大きな意思決定をする大事な仕事だと思います。また、メンバーの成長は、チームや組織の生産性をあげるための長期的な投資として、不可欠な仕事です。そのような仕事をするマネージャーの助けになるべく、これからも改善を続けていければと思っています。
少しでもここに書いた情報が参考になり、より効果的なフィードバックや評価が行えるための一助となれば幸いです。もっとこんな良いやり方もあるよ！評価の仕方、議論したい！という方、いつでもお待ちしております。一緒に働きたいよという方も大歓迎です。この記事へのみなさまのフィードバックをお待ちしております。
