プロフェッショナルチームのマネジメント 2:課題発見アプローチ

前回の続きです。個々のトピックについて、もう少し具体的な話を書いていこうと思います。

改めてですが、プロダクトマネージャーの役割は、一言で言うと、何らかのプロダクト・サービスを通じて、ユーザーに最大限の価値をもたらすことです。そのために、ユーザーに提供する価値を定義し、それをビジョンとして関係者と共有しながら、必要な全てのことを手段を選ばずに実行するのがミッションです。

ただ、全てのことをやると言っても、時間は限られています。その限られた時間の中で本当にやるべきことをどう見つけるのか、今回は課題発見のアプローチについて書いてみます。

ボトルネックを見つける

最初に結論を書きますが、その瞬間で何をやるのか、それは一言で言うと"ボトルネックを解消する"ことです。ここでの"ボトルネック"は、製造業などのSCM(サプライチェーンマネジメント)で課題解決に用いられる理論の一つTOC(Theory of Constraints)=制約条件理論の基本的な考えの一つです。
#詳しくは "The Goal"という本に詳しいので、お時間のある方はぜひ読んでみて下さい

簡単に図で表すと、インプットからアウトプットまでにA~Dの工程があった時、全体のスループット(アウトプットのスピード)を上げるためには、一番弱いBを強化する必要がある、ということです。

スクリーンショット 2020-02-27 0.07.35

この時、少なくともその瞬間は、A/C/Dをいくら強化しても、全体のスループット向上には貢献しません。それどこか、これらを改善するために、Bを担当するの人の時間を奪ったり(よくあります)、手前のAを改善しすぎてBの目の前に必要以上のToDoができたり(これもよくありますw)、どちらも逆効果で全体のスループットが落ちる結果になります。

つまり、その瞬間に取りかかるべきことは"B"を改善し強化することただ1つであって、この"B"が即ちボトルネックになります。

理屈としてはとてもシンプルなのですが、実際にはこんな簡単なプロセスで動いていることはないので、ボトルネックを見つけるのは簡単ではありません。簡単ではないが故に、価値を生み出す上での"ボトルネック"を見極めて解消することは、プロダクトマネージャーにとって非常に大事なタスクになります。

現実の複雑さ

実際は、一つのプロダクト、サービスをつくり上げるために必要に多くの人が関わってきます。今、私が担当しているAI事業のプロダクトは、音声認識や自然言語処理など、多くの要素技術の組み合わせから成り立っており、非常に複雑です。その複雑さをあえて2次元的に書いてみるとこんな感じです。

スクリーンショット 2020-02-27 0.07.46

このような状態では、プロセスを分解し個々のアウトプットのスピードを測定したところで、ボトルネックを見つけるのは困難です。何故なら、依存関係が多すぎるからです。

また、当たり前のことなのですが、ボトルネック自体は、それを解決すると別のところにボトルネックが移ります。ボトルネックが次々と移っていくということは、ボトルネックの発見するコスト/労力を最小化する必要があるということです。発見コストが大きいと、変わりゆくボトルネックをクイックに発見し続けることが現実的に難しくなります。そのため、プロセスを分解してボトルネックを発見するのはコストがかかりすぎて、効果的な方法とは言えません。

では、どうするか。"人の関係性と情報のフロー"に着目します。

コミュニケーションパスが集中するところ(人)に着目する

下記の図のようにコミュニケーションが集中する人を見つけます。

スクリーンショット 2020-02-27 0.07.55

チームの内外の関係する人にインタビューを繰り返していくと、質問さえ間違えなければ、割と簡単に明らかにすることができます。"関係する人は誰か? その人とはどういう役割分担か? どういうやり取りをするか?" などを通じて、上の図のようなコミュニケーションのパスを描き、パスが集まる人を把握していきます。

見つかった後の解決方法は、その時々に応じて変わるのですが、例えば、頼られすぎちゃってる人であれば、
1. その人だけにしかできない仕事と、そうじゃない仕事を分けて役割を分散する
2. それができなければ、その人の仕事をなるべく自動化/省エネ化する。
3. それすら難しい状況であれば、踏ん張り所として励しつつ(?)、余裕ができた時に1,2ができるように準備する
などなど、その人の置かれた状況、役割、気持ちも含めて最適な解決方法を選びます。

その他、抱え込んじゃうような人であれば、割と強引にでも仕事と役割を再配布することが多いです。

パスが集中する場合、割と発見は用意で、解決に時間がかからないことも多いです。ただ、これ以外にもボトルネックになりやすいパターンがあります。それはループ構造です。

コミュニケーションパスがループするところに着目する

下の図のようにコミュニケーションがループするところ、つまり、話が進まないようなポイントも要注意です。

スクリーンショット 2020-02-27 0.08.08

この場合、大体は、そのループしている人の間で、コミュニケーションプロトコルが合致しおらず、意思疎通ができていない可能性が高いです。例えば、企画とビジネス、ビジネスと開発、企画と開発など、同じことを表現しているはずなのに、プロトコルが違いすぎて会話が成立していないことがあります。

また、ダイバシティーが強い環境、例えば色々なバックグラウンドを持つ人たちが集まっているような環境であれば、ワークスタイルの思想の違いに起因することもあります。例えば、自主性と合意を重んじる文化と、責任範囲が明確で上意下達を是とする文化、こういう文化を持つそれぞれの人やチーム間のやりとりは、信頼感を削り合う構図が生まれやすいです。何故なら、意思決定に対する捉え方が違うからです。このようなコンフリクトは言語化されないことが多く(当事者間でもどこに溝があるのが想像しにくい)、勘と経験でさぐり当てる必要があります。

このような場合、当事者間での解決を短期間の中で期待するのは難しいことが多いです。時間がないのであれば、多様なプロトコルを話せるディレクターに助けてもらったり、もしくは自分で間に入るなどして、橋渡しをすることで対応します。

時間的な変化を読む

これは、プロフェッショナルなチームならではのポイントです。能力のとても高い人は、例外なく何かを学んだり成長するスピードが非常に早いので、1つの事業やプロジェクトをやっている間にも、止まらずに成長していきます。

ですので、ある瞬間にボトルネックだったとしても、その成長のスピードによって自然とボトルネックではなくなっていくケースがあります。そのため、プロフェッショナルなチームに対しては、それぞれの人のその役割における成長スピードを千里眼的に見通して、時間軸も考慮した上でのボトルネックを見つける必要があります。

スクリーンショット 2020-02-27 0.08.20

上記の図の場合、塗りつぶしているところが現在のスループット、点線が未来のスループットですが、"B"を改善するのは効果的ではなく、取り組むのは"D"が正解になります。

これを正しく予想するのは本当に難しいです。私自身、後になってこっちじゃなかったなと思うことはよくあります。その理由はシンプルで、想像を超える成長をする人が多いからなのですが。。。

ユーザーとチームとステークホルダー

これまでは、チームの中にある課題解決のアプローチを書いてきました。もちろん、ユーザーとの間に課題があるとするとビジョンが良くない、つまりそれを実現したところで大きな価値にならないということですし、ステークホルダーとの間に課題があるのであれば、会社として、その事業に対しての意味付け、KGI/KPIの設定がずれているということになります。

スクリーンショット 2020-02-27 0.08.28

もちろん、全く何もない状態からビジョンを作るのであれば、その策定やステークホルダーとの期待値整理をイチからやっていく必要があります(ビジョンの定め方、KGI/KPIの決め方みたい話しは、今回の主題とは違うので割愛)。

一方で、途中から参画した場合など、何らかチームが存在することも多いと思います。その場合は、まずチームに対してのアプローチすることをお勧めします。結果的に、ボトルネックが、チームの中にはなく、ユーザーとの間や、ステークホルダーとの間にあったとしても、チームへアプローチすることで、どの場所にあるボトルネックでも一番早く発見できることが多いです。

何故なら、そのチームの人たちは、ボトルネックの見極めや、解決方法がわからないだけで、課題そのものはすでに理解されていることがほとんどだからです。ですので、先にも書きましたが、何かの事業をやる時、そこにチームが存在するのであれば、自分で考えることからは始めず、まずはその人たちとの会話を真っ先にします。一人で考える前になるべく多くの人と会話をする、一言で言うとこれが最初に解決すべきボトルネックを見つける最速の方法だと思います。

最後に

多くの人や物事がダイナミックに動く中でのプロダクトマネジメントにおいて、プロダクトマネージャーが解決すべき課題発見のアプローチを書いてみました。生産性の話がよく話題に上がりますが、生産性が異次元に高い人は、課題解決の迷いがないのも当然ですが、その前の本質的な課題を見極める正確性、その見極めのスピードがとても早いように感じます。

私自身、そう感じる人に対して、常に"自分だったらこうするな"という勝手なロールプレイをした上で、どう課題設定したのかを直接本人に聞いてみることも多いです。どう課題"解決"したのかは外から見えやすいのですが、どう課題"設定"したのかは中々見えづらかったりするためです。そして、その聞いた結果と自分のロールプレイの結果で答え(?)合わせします。

結局、課題発見、課題解決の精度は"場数"に依存するのですが、自分の時間だけで場数を増やすのは限界があるので、他の優れた人の時間と経験を使って場数を増やす、これが一番の近道かなーと思います。

というわけで、課題発見のアプローチでした。その他、プロダクトマネージャーとしてのノウハウ、Tipsは、気が向いたらまた書いてみようと思います。


この記事が気に入ったらサポートをしてみませんか?