エンジニア出身のマネージャーがやってしまったマネジメントの失敗（指示待ちメンバーの作り方）

こんにちは。
スタートアップでプロダクトマネージャー兼エンジニアリングマネージャーとして働いているjunpeiです。

エンジニア出身マネージャーとして働く中で、エンジニア出身だからこそやってしまったマネジメントの失敗を紹介します。誰かの役に立てれば幸いです。

想定読者
・エンジニアリングマネージャー（EM）
・エンジニア
・エンジニア出身プロダクトマネージャー（PdM）

伝えたいこと

マネージャーの仕事は何でもかんでも決断することではない。
決断する内容は、プロダクトのHowではなく、why、whatを決断すること。
指示待ちメンバーは、Howまでマネージャーが管理した時に出現する。

はじめに

新規Webサービス事業のエンジニアリングマネージャーをしていた時の話です。スクラムガイドをチームで読み、スクラムイベントを守りながら、開発を進めていました。（少なくともそのつもりでした。。）
開発開始からずっとリモートという環境でのスタートでした。

どうやって進めた？

スプリントは1週間。開発チーム5名ほどの体制で、振り返り（KPT）を毎週しながら、進め方を改善しながら開発を進めていました。
マネージャーとして決断を大切にしていたので、エンジニアリング経験をフルに活かして、チーム開発での不明点などをバシバシと決断していきました。また、チームが開発している間に、今後の開発が止まらない、後戻りしないよう、先のスプリント分の仕様詳細まで決めて進めていました。
この時点では開発者からも、不明点が少なく進めやすいという声ももらい、今のやり方でいいのかなと思っていました。。

発生した問題は？

あるときから、「ここの仕様を決めてください」「ここの仕様が決まらないと進めません」という言葉が聞こえてきた。どうやったらいいか提案・決断してきてくださいと伝えると、「全体感がわからないので、提案・決断もできない」となった。
あれ、これなんかスクラムじゃない？と気付き始めたのはここでした。
自己管理化した組織にしたいのに、自主的に進めてもらえない。そして気付けば、多くの指示待ちメンバーを作り出していました。

原因はなにか？

マネージャーの自分が仕様まで決断していることが問題だと気づきました。
決断することがマネージャーの重要な仕事と考えていました。しかし、それが負のループに入っていることに気づかず、最終的にマネージャーのみが仕様を知っており、孤立したチームのボトルネックになってしまっていました。（下図）

なまじエンジニアリングがわかるせいで、仕様の詳細まで見通すことができてしまい、スクラムにおける開発チームの仕事を奪い、支持待ちメンバーを作り出してしまっていました。

指示待ちメンバーの出現の負のループ

どう対応したか？

３つあります。

１つ目は、プロダクトのHow（仕様）を決めることをやめました。
具体的には、基本設計、詳細設計にあたるような、項目詳細仕様や画面のデザイン、データベースなど検討は開発チームにまかせるようにしました。
任せはするものの放置というわけにはいかないので、ティール組織での意思決定プロセスである、助言プロセス が取れるように目指し始めました。（当事者に意思決定が委ね、広く助言を集めるものの、最終的にどの意見をどう反映するかは当事者が決めるというものです。）

２つ目は、プロダクトのWhy、What（要件）に注力しました。
開発者にHow（仕様）を考えてもらうためには、Why、What（要件）がしっかり定まっている必要があります。プロダクトバックログに要件をしっかりと記載し、逆に仕様は書かないように要件だけに止めるようにしました。

３つ目は、開発者がチームで考える時間を確保しました。
正しくスプリントプランニングをするようにしました。実は、事前に仕様を決めていたので、スプリントプランニングがマネージャーからの仕様の共有の場になっていました。それを開発チームが考える時間にしました。
具体的には、スクラムガイドに書いてある通り、見積もりとプロダクトバックログの要件をスプリントバックログに分割するまでやるように変更しました。

結果どうなった？

まだまだ自己管理化組織とは言いづらいですが、マネージャーのボトルネックはかなり解消されました。スプリント内でマネージャーに確認依頼が来ることはほぼなくなり、本来の仕事である将来のことや重要なことに注力することができています。

まとめ

マネージャーの仕事は何でもかんでも決断することではない。
決断する内容は、プロダクトのHowではなく、why、whatを決断すること。
指示待ちメンバーは、Howまでマネージャーが管理した時に出現する。