見出し画像

新卒3年目のひよっこマネージャーにも効果的なフィードバックがほしい!

こんにちは。プロダクトディビジョンChatworkプロダクトユニットファサード開発チームの須田です。2023年4月に入社してもうすぐ新卒4年目です。昨年(2025年)10月からはいろいろとあってチームのエンジニアリングマネージャーを任されています。

昨年末のアドベントカレンダーで、1 on 1 についての記事を書きました。ありがたいことにそれなりの方に読んでいただき、私が勝手に推しているエンジニアの方から X でいいねをもらうという実績も解除しました。すっかり気分が良くなったので、続編をしたためます。

この記事は kubell ブログリレー の記事です。


前回のあらすじ

前回の記事 では、1 on 1 を効果的にするためのアイデアを書きました。1 on 1 の README を作る、メンバーとしっかり期待値調整をする、良い感じのテンプレートを整備しておく、といった内容です。これはそれなりに上手くいき、あれから3ヶ月たった現在も毎週ほとんど欠かさずにメンバーと 1 on 1 を重ねています。

一方、前回の記事では課題として「いくらテンプレートを用意したところで、メンバーからエンジニアリングマネージャーにフィードバックをするのは難しいようだ」というものを挙げました。前回の記事の時点ではテンプレートの中に「相互フィードバック」という欄を設け、マネージャー → メンバー / メンバー → マネージャーが相互にフィードバックをする場を設けるというプラクティスを実行していました。ただ、この項目は空欄になっていることが多く、また私から 1 on 1 の中で「何か私に対するフィードバックはありますか?」と聞いても「いやー特に思いつかないですね」という反応が大多数でした (私も上長から同じ質問をされたら同じことを返すと思います)。

発見: デリゲーションポーカー

まぁでも上長に対してフィードバックするというのはなかなか難しいか、仕方がない、と半ば諦めていた (というか忘れていた) 頃、1 on 1 とはまったく別のコンテキストで「デリゲーションポーカー」について考える場面に遭遇しました。

デリゲーションポーカーとは、Management 3.0 の中で紹介された権限移譲のためのツールで、次のようなものです。

デリゲーションポーカーとは、チームとマネージャーが「誰がどの程度の権限をもって意思決定するか」を視覚的に合わせるためのワークショップツールです。1〜7のカードを使い、各レベルは「指示する」から「完全に委任する」までの権限の度合いを表します。参加者がそれぞれカードを出し合うことで、認識のズレを明らかにし、健全な権限移譲の文化をチーム内に育てることができます。

Claude

デリゲーションポーカーにおける7つの移譲レベルは、次のように定義されています。

レベル1 告げる: あなたが判断し、それらをあなたの部下に知らせる。(これは、実際には全然委任ではない。)
レベル2 売り込む: あなたが判断するが、あなたは実務者たちに自分のアイデアを「売り込む」ことによりそれらの人たちの関与を得ようとする。
レベル3 相談する: あなたは、判断に至る前に、実務者たちを招き、意見を熟考する。それでも、判断を下すのはあなたであることは明確にする。
レベル4 合意する: あなたは、実務者たちを議論に参加するように呼びかけ、グループとして合意を得る。あなたの意見は、他の人たちと等価である。
レベル5 助言する: あなたは、実務者に自分の意見を説明することで実務者たちに影響を及ぼそうとするが、最終的にあなたは実務者たちに判断を任せる。
レベル6 尋ねる: あなたは、厳密に必須ではないが、あとでチームが自分を説得できればうれしいという提案とともに、チームにまず判断してもらう。
レベル7 委譲する: あなたは、そのことへの対応をすべてチームに委ねて、その場を離れて愉快な時間を過ごす。(あるいはそのシステムをマネージするためにその時間を使う。)

マネジメント 3.0 (丸善出版)

デリゲーションポーカーの良いところは、権限移譲が白か黒かの二択ではないことをチームもマネージャーも認知できるところと、本来権限を持っている人には伝えづらいであろう「これくらい移譲されるべきだと思っているんだけど…」というのをさらりと伝えられるツールであるところです。

これを発展させれば、メンバーからマネージャーに対して期待値を伝えるきっかけを生むフレームワークを作れるのではないか、と考えました。

提案: マネジメントキャリブレーター

デリゲーションポーカーは権限移譲についてのみ取り扱うフレームワークです。マネージャーがメンバーにどれだけの仕事を任せるか (≒ 権限移譲) をすり合わせることはマネージャーの重要な仕事の一つですが、マネージャーの仕事はそれだけではありません。メンバーの相談に乗ったり、メンバーにフィードバックをしたり、壁打ち相手になったり、キャリアについて悩んだり、マネージャーしか持ち得ない情報を共有したりする必要があります。

これらいずれの仕事にもグラデーションが存在します。ずっとマネージャーに隣にいてもらいいつでも相談に乗ってほしいと希望するメンバーもいれば、マネージャーに相談に乗ってもらうのは週に一度程度で良いかな、というメンバーも存在します。常にマネージャーが知っている情報はすべて開示してほしいというタイプのメンバーもいれば、本当に仕事に必要な最低限の情報だけ厳選して伝えてほしいというタイプのメンバーも存在します。そしてこれらは本当に人によってさまざまで、もっと言えば同じ人でもタイミングが違えば違う希望を持つのが自然です。

マネージャーとしては、十人十色なメンバーにそれぞれ適切な対応ができているのかどうかが非常に気になるポイントです。それこそをメンバーにフィードバックしてほしいと考えています。しかし「ちょっと情報過多なのでもう少し減らして」とか「もっとこまめに相談に乗ってほしい」とかそういった類のフィードバックは、冒頭に述べたとおりメンバーからマネージャーに伝えるのは非常に難しいのが現実です。

ということで、次のような「マネジメントキャリブレーター」を作ってみました。「キャリブレーション」というのは「すり合わせる」「調整する」といったニュアンスの英語で、それをするためのツールということで「キャリブレーター」という名前にしています。



この8つの軸は、私がこれまで行ってきた 1 on 1 で出た話題を抽出して整理したものです。おそらくまだまだ他にも軸はあると思いますし、逆に似たようなことを表していて概念が重複している軸もあるので、今後実践していく中で入れ替わっていくことでしょう。またこの軸が全マネージャーに当てはまるとは思っていません。マネージャー各々が、自分が担当しているチームやメンバーの特性・状態を見ながら軸やタイプを作っていくのが良いのではないかと考えています。

ところで、マネジメントキャリブレーターはメンバー → マネージャー方向に要望を伝えるようなツールに見えますが、それだけではないと考えています。マネジメントをする上では、メンバー → マネージャー方向の期待値とマネージャー → メンバー方向の期待値が適切にすりあっている必要があると思います。メンバー → マネージャー方向だけではマネージャーがチームの方向性を指し示すようなことが難しくなりますし、マネージャー → メンバー方向だけではメンバーの自主性が活かされません。マネジメントキャリブレーターはメンバー → マネージャーの単純な要望伝達ツールではなく、相互の期待値調整の対話のきっかけとして使われるのが適切だと考えています。

実践: 1 on 1 でのマネジメントキャリブレーターの活用

実際に、自分が担当している何人かのメンバーに対してマネジメントキャリブレーターを使ってもらっています。だいたい、1 on 1 がスムーズに進んで時間があまったときの「もう1トピック」として使うことが多いです。

使ってみている手応えは非常に良好です。「やはりこの方はそういう考え方だよな」と思うこともあれば「あ、そのタイプを選ぶのか。これまでちょっと期待とズレた接し方をしてしまっていたな」と思うこともあります。特に関係性の深いメンバーが意外なタイプを選択してきた際には、自分の色眼鏡がいかに色の濃いものであるかを思い知らされます。

実在するメンバーについては具体的な話を書くことができないので、仮想事例を紹介します。

仮想事例: メンバーAさんの場合

例えばあるメンバー (実在しない仮想のメンバーです) Aさんについて妄想してみましょう。

Aさんは気になる軸として「情報共有の量と形式」を挙げてくれました。なぜその軸なのかを聞いてみると、どうやら最近チームのミーティングが長引きがちなことに少し違和感を覚えていたようです。たしかに最近、以前は15分で終わっていた朝会が20分, 30分と伸びていました。新しいプロジェクトが始まったこともあり、チーム内での議論が活発になっていたのです。

続けてAさんにAさん自身はどのタイプのマネジメントを希望するか聞いてみたところ、「B: 決まったことだけ共有して」を選んでくれました。なるほど、最近の自分は、新しいプロジェクトの情報は透明性を高めて共有した方が良いと考え、なるべく事細かにメンバーに情報連携することを心がけていました。ところが話を聞いてみると、Aさんはどうやら「そこまでの情報はいらないなぁ、もっと少ない情報でも仕事はできるから、開発の時間を削らないでほしいなぁ」と考えていたようです。さらに聞いてみると、Aさん自身はプロジェクトの進捗をとても気にしており、今は why / what を議論するタイミングではなく、とにかく動くものをまずは作ることが重要だと考えているとのことでした。

Aさんとの対話を踏まえて、他のメンバーにもそれぞれの 1 on 1 を通じてどう思っているか聞いたところ、多くのメンバーが「最近マネージャーの話が長い」と薄々感じていたことが分かってきました。良かれと思ってプロジェクトの詳細情報を事細かにメンバーに伝えていましたが、どうやら今のやり方では時間を使いすぎているようです。なるほどこれはいけないということで、朝会で話す内容は決定事項のみとし、周辺情報はドキュメント化して必要な人だけ読める状態にすることにしました。

メンバーからは後日の 1 on 1 で「開発に使える時間が増えたし、必要なときは情報もあるし、最近集中して仕事ができています」とポジティブフィードバックがありました。めでたしめでたし。

さいごに

チームのマネージャーはチームをマネジメントするのが役割です。ではチームのマネージャーを誰が「チームのマネージャー」としてマネジメントするかというと、それはチームでありチームメンバーなのではないかなと思います。もちろんマネージャーの上長 (VPoEなど) もマネージャーをマネジメントする役割ですが、それはチームから一段上のレイヤーからのマネジメントであり、「チームのマネージャー」のマネジメントではないようにも感じます。

マネージャーがチーム から 適切にマネジメント される ためには、メンバーからのフィードバックが命綱だと感じます。メンバーからのフィードバックがなくなれば、マネージャーは一人暗闇の中を歩くようなことをしなければならなくなります。これはマネージャー自身にとっても、チームにとっても幸福なことではないでしょう。

メンバーにマネージャーに対するフィードバックの機会を提供し、マネージャーのマネジメントスタイルを対話を通じてキャリブレーションする手段として「マネジメントキャリブレーター」はなかなかに役立つツールなのではないか、と期待しています。

参考文献

今回ブログを書くにあたって改めてパーッと読み直しましたが、良いことしか書いていません。オススメです。

いいなと思ったら応援しよう!