私がEMとしてメンバーと向き合うときは「彼らのポテンシャルやエネルギーを100％発揮できる状態をつくれているか」と考えることを心がけています。『観察』と『フィードバック』はこれを実現するための最も大事な手段といえます。

ここ最近の自分自身のマネジメント業務を振り返ってみると、『フィードバック』のほうはある程度の型ができていると感じます。ベースとなる型があって、それをチームメンバーや状況によってアレンジしながら使っている感覚です。

そこで今回は私が5年間のマネジメント業務経験で培ってきたフィードバックの型を紹介してみます。世の中には数々のフィードバック方法論があるので体系的な知識はそれらに任せて、ここではより実践値の高い具体的な手法をお伝えします。

前提 - フィードバックのタイミング

人事評価の時期にはこのあと紹介するフィードバックの観点のすべてを整理し伝えますが、1on1等日々のコミュニケーションの中でも伝えられる内容があるときはすぐ伝えます。言い換えると、日々の小さなフィードバックを収集して体系化したものが人事評価のタイミングでのフィードバックとなるので、受け取ったメンバーが「半期が終わって評価のタイミングで突然思いも寄らないフィードバックを伝えられた」とはならないはずです。 ……ならないよう心がけています。

「フィードバックはナマモノ」と言われたりもしますが、マネージャーとメンバーとの間で期待役割や評価の認識がズレない状態を維持することがフィードバックにおいて最も重要だと考えています。

観点1　「現在の期待役割とその達成度」

期待役割と、現時点でそれをどれほど達成できているかを伝えます。
グレード、担当業務、職種、スキルなど様々な要因で期待役割は決まりますが、マネージャーはメンバー一人ひとりの期待役割を解像度高く理解し、彼らにその解像度を共有することが必要です。そしてその期待値をどれだけ満たしているかを併せて伝えることで、メンバーは「今の働き方を継続していこう」「足りない〇〇を意識するよう軌道修正しよう」と日々の行動を修正する指針を得られます。

期待役割は『やってほしいタスク』ではなく、ふるまい、責任、成果、インパクト等で伝えます。
これらを伝える際、ジュニアなエンジニアほど具体的に、シニアなエンジニアほど抽象的に伝えることになります。ジュニアメンバーはいわゆる一人前と呼ばれる共通の水準に到達するための段階的な期待役割が設定されることが多いので内容が具体的になりやすく、シニアになるほど「エンジニアリングを通じて事業目標に貢献する」などの抽象度の高い成果が期待されることが増えるからです。

この観点でのフィードバックの要は、評価者である自分と被評価者であるメンバーとで、期待役割と現在地についてどれだけ高解像度に目線合わせできるかです。そのためにはまずマネージャー自身が解像度を上げる必要があります。
会社や部署の評価基準が曖昧なままであったり、全社共通のグレード毎の期待役割が抽象的過ぎたりする場合は、それらを掘り下げることが必要になるでしょう。その場合マネージャーひとりでは解決できないですし、ましてやチームメンバー自身で解決するのは不可能なので、有識者や意思決定者を巻き込んで期待役割の掘り下げをすることが最初の一歩となるかもしれません。

観点2「一歩先の期待役割と伸びしろ」

現在の期待役割と併せて伝えるべき2つ目の観点が、次の段階のキャリアで求められる期待役割です。

自分自身がチームに属するいちエンジニアとして働いていた頃、あと何をがんばれば自分の評価が伸びるのか、新しい仕事を任せてもらえるのか、より裁量が与えられるのかが分からず悩んだことがあります。この要因は次のステップでの期待役割を理解していなかったこと、ひいては現状と次ステップとの差分を測れていなかったことにあります。
この例のように、キャリアアップの伸びしろを示すことが、メンバーが持つエネルギーを適切な方向に放出させることに役立つ場面があります。努力の方向性を間違えさせない環境づくりとも言えます。

この観点をフィードバックする際に私が気をつけていることは、現状との差分、つまり伸びしろを伝えるようにし、伸びしろを埋める行動はメンバー自身に考え実行してもらうようにすることです。例えば先述した「一人前のエンジニアになること」が次のステップである場合、

任された案件の進行中に仕様漏れや見積もりミスなどの問題が発生しても、関係者とともに軌道修正しながら完遂することを期待しています。すでにトラブルのない案件は滞りなく進行できているので、軽微かつ頻出な問題が発生した際にも進行できることで『一人前』の水準に近づきます。

他にも、任された案件をこなすだけでなく、プロダクトやチームの課題を自ら見つけ解決に取り組むなどの自主的な行動も一人前のエンジニアに求められる期待役割です。

といった具合にフィードバックします。『一人前』という期待役割の解像度を上げ複数の視点で伸びしろを伝え、メンバー自身が差分を埋める具体的な行動を判断し実行することが、彼らのポテンシャルを引き出すことに繋がると信じているからです。
もちろん行動が思いつかないようであれば具体例を出すこともありますが、メンバー自身が考える余地を残すことに意味があります。

ところでここで言う『一歩先』とは必ずしも次のグレードを指すわけではありません。メンバー一人ひとりの成長速度や直面する障壁の難易度などによって変わります。「各メンバーが次のフェーズにステップアップするためにどのような階段を登るだろうか」と考えながら、メンバーによっては1段ずつであったり2段飛ばしであったりと適切な『一歩先の階段』をフィードバックするよう意識しています。

観点3「成果の価値の掘り下げ」

メンバーが出した成果にどのような価値があるかを様々な視点から伝えます。

あるメンバーが「既存のプロダクトにTypeScriptを導入しました。開発スピードが上がり、QA時のバグも減りました」と自身の成果を捉えていたとします。しかしこの成果には他の側面でも価値があります。たとえば

  • 今まで通り開発案件をこなしながらTS導入の時間を捻出しやり遂げたことは、開発リードタイムの短縮や効率化など業務改善の成功事例という側面があります
  • デグレを起こすことなく既存のコードをTS化した開発プロセスそのものに価値があります
  • チームメンバー間でTSの技術レベルの差がありながらも導入し、その後もチームのベロシティが落ちていないことから、チームの技術力を底上げする工夫がなされていることが読み取れます

といった具合に様々な側面から成果を捉え、本人が気づいていない価値をフィードバックします。

加えて、その成果が期待役割に噛み合っているかを伝えること重要です。たとえばジュニア寄りのエンジニアが上述の成果を上げたのであれば「自主的な改善活動は期待に沿う成果です」となるかもしれませんし、シニアエンジニアであれば「その活動が事業に与える効果をステークホルダーに説明するところまでやり遂げることを期待しています」となるかもしれません。これは観点1の『現状の期待役割に対する達成度』のフィードバックとも言えますね。

観点4「強み」

多くのマネージャーがすでにしていることと思いますが、マネージャーが観測した強みを伝えることも重要です。これは言葉の通りなのでこれ以上の説明はないですが、私が意識していることは、1度伝えた内容であってもその強みが見られる事例があった際には何度でも伝えることです。

強みとは、言い換えれば「苦労したとは思ってないのに人よりうまく出来ていること、評価されていること」だと思います。人より簡単にできてしまうことを特別なスキルや長所だと自覚するのは案外難しかったりするので、繰り返し何度でも伝えようと心がけています。

観点5「挑戦機会」

ここまで紹介した観点1〜4を踏まえて、挑戦機会を提供します。
メンバーの次のステップの期待役割と現在地との差分を明らかにし、伸びしろを埋めていくためにどんな強みを生かしてどんな挑戦をすると良いかを計画し、日々のマネジメント活動(EMとしてのあらゆる活動)を通じて挑戦機会を見つけてフィードバックします。

『挑戦』というと目新しい仕事に目が行きがちですが、長く続けている業務の中にも挑戦できるポイントは潜んでいます。もちろん最適な挑戦機会がすぐに見つからない状況もありますが、挑戦機会が必要になって初めて探すこととならないよう、メンバー各々に対する観点1〜4を頭の中に描きアップデートし続け、適切な挑戦機会を日々探し続けておくことが大切です。
「今の仕事に飽きてしまったし成長を実感できないので転職を考えています」と打ち明けられてから挑戦機会を探すのでは遅い……ということはマネジメントをしている方々には想像に難くないと思います。

おわりに

実践しているフィードバックのうちベースとなる部分を整理して紹介してみました。
繰り返しになりますが、「フィードバックをしよう」と思ってからこれらの観点について考え始めても手遅れになってしまうので、常にメンバー一人ひとりと各観点を同期し続け、自分と近い解像度を維持してもらうことを意識しながらフィードバックし続けることが重要です。そしてそのためには常に観察し続けることもセットで必要になります。

私の職場環境だから成り立っている内容も多分にあったかもしれませんが誰かの役に立てれば嬉しいですし、そうでなくとも数年後自分自身で読み返してレベルアップを実感できれば良いなと思って書きました。

思ったより長くなってしまいました。ここまで読んでくれた方はどうもありがとうございました。