複数のプロダクトをマネジメントする際の組織設計について
企業や事業体で持つ何らかのプロダクトの成長を考えた時、その成長を最大化するために組織をどう設計するか、これは常に悩ましくもあり、深いテーマです。一義的な解はなく、様々な要素に依存して、最適解は変わってきます。
このポストでは、複数のプロダクトをマネジメントする立場において、チーム全体の組織をどう設計するかについて、私が意識している視点を書いてみたいと思います。(会社全体の組織設計については、私自身があれこれ書くに値するようなナレッジは持ち合わせていないので、どなたかにお任せします)
なお、この内容は以前にポストした、プロフェッショナルチームのマネジメントについて、と関連しています。
上の記事では、階層的な構造の否定と、フラットな構造でのコミュニティ型のマネジメントの肯定とその方法論についての内容です。以下は、この内容に基づいたものであること、ご留意くださいませ。
複数のプロダクトをマネジメントすることの難しさ
もし企業や事業体の中で、1つのプロダクトしか存在しない状況であれば、前項の記事で記載したようなコミュニティ型のマネジメントは比較的容易に実行することができます。
しかしながら、ある程度まで成長した事業体では、複数のプロダクトを同時に運営していることが多いかと思います。そうすると、1つのコミュニティに複数人のプロダクトマネージャーと、複数のプロダクトが存在している状態になります。
1つでも不確実性が高いプロダクトのマネジメントにおいて、それが複数あると、それだけで不確実さは飛躍的に高まります。また、プロダクト間のリソースのかけ方、どちらを優先するか、など、最適化にあたっての変数も倍々で増えていきます。
そのような複雑な状況においても、コミュニティ型のマネジメントが成立するのか？というと、Yesだと考えています。プロダクトが増えても、理想的にはフラットなコミュニティ型マネジメントは可能だと思います。ただし、すごく難しいです。何故かというと、Yesのためには、多くの但し書きが存在するからです。
1. 全てのプロダクトマネージャーに強烈なオーナーシップと、適切なプロダクトマネジメントをする力量がある
2. 全てのプロダクトマネージャーが、会社・事業全体の状況を常に深く理解している
3. 各プロダクトマネジャー間に、深いTrust&Respectがある
4. その関係に基づいて、各プロダクト間のリソース配分まで最適に行える状態になっている (強烈なオーナーシップを持ちながらも、時には、全体最適の客観的な判断ができる状態)
このような条件が全て揃えば、1つのコミュニティとしてマネジメントすることは可能だと思います。しかし、現実的には、全ての条件が揃うことはとても稀だと思います。それでも、マネージャー自身の能力で欠けている部分を補えるのであれば成立しますが、それもチームが大きくなればなるほど、個人の能力で補うのは現実的でなくなっていきます。
では、完全ではない状態において、なるべくコミュニティ型のマネジメントを行うためには、何が必要か。それがまさに組織だと考えています。
組織の役割
組織の役割を説明する上で大切な考え方は、フラットなチームが良いのではなく、フラットで成立するチームはとても強いチームである、ということだと思っています。
前項で説明した条件が揃うチームはとても強いチームであり、フラットな構造が成り立ち得ます。しかし、いつも成り立つかというとそうでもなく、むしろ稀です。そのような"理想的でない状態"の穴を、組織を作ることで補完します。
下の図において、左は理想的にフラットなチームです。この状態が成り立つのであればそれで良いのですが、難しい場合は、右の図のように一部に組織(=赤い線での区切り)を作り、現実的にマネジメント可能な状態に整えます。
組織の作り方を考える上で、考えるステップは3つです。
1. チームのスキルと関係性が、どの程度まで成熟しているかを見極める
2. 成熟度に対して、自分のキャパシティを持って、コミュニティ型のマネジメントができるギリギリの範囲を見極める
3. オーバーキャパシティになるポイントをカバーするために、"組織"という枠組みを作る
文字にすると簡単ですが、実際にはとても難しいです。成熟度は日々成長するので、ある程度の先を見越さないと、不必要に組織を作ることになります。一方で、過大評価をしてしまうと、全体をマネジメントする人のキャパシティをオーバーしてしまい、チーム全体の機能不全を起こします。
定量的に最適なポイントを表現するのは中々難しいですが、結果として、組織を作ることで自分のキャパシティ内に収まればOK、という感覚です。(曖昧ですみません)
これは、別の言い方をすれば、自分のマネジメント能力が上がるか、もしくはチームのコンディションが良くなれば、チームから"組織"という枠組みを取り除き、フラットにしていくことができる、ということです。
この因果関係がクリアになれば、組織の役割とそれを考える視点はシンプルです。
1. マネジメントの難易度と負荷を下げるために、最低限の組織を作る
2. 組織を作ることで生まれる弊害を理解し、最小化する
この考え方が整理できれば、半分ぐらいは解決しています。では、残り半分、どのあたりから、"組織"をつくるべきか、具体的に書いていきます。
プロダクト毎に組織を作る
プロダクト毎に組織を作る、というのは、プロダクトA、プロダクトBという塊で組織を作ることです。それぞれの組織の中には、プロダクトの運営に必要なメンバー、つまり、プロダクトマネージャー、企画者、開発者などの人たちが同じ組織に属している状態です。
この形はプロダクト単位の組織のため、プロダクトに対するオーナーシップが保たれやすいです。また、プロダクト毎の組織なので、全体をリードする立場としては、とてもマネジメントしやすいです。ただし、一方で、プロダクト間の横連携は、簡単に激減します。そのため、プロダクトの掛け算で新しい価値が生まれる可能性が減ります。
もし、各プロダクトの独立性が高いのであれば、そもそも問題ありませんが、もし横連携する価値があるプロダクトであれば、組織を超えて横連携ができる仕組みを作っておく必要があります。
仕組み、というのは単に人をアサインするということではありません。まずはじめに、組織の枠組みをジャンプできる能力のある人を見つけることが大事です。
ちなみに、組織の枠組みを越えるのは、それ自体が高い能力なので、適切でない人をアサインしてもうまくいきません。各プロダクト組織ごとに、枠組みをジャンプできる人がアサインできればベストですが、十分にいなければ、横連携の優先度を付けます。そして、優先度が低いものは横連携を諦めます。間違っても、全てのプロダクトで、"形だけの横連携役"を決めないことです。(形だけ決めてもワークしないので)
そして、その上で、横連携を考えるために必要な情報を、ものすごく意識的に、その人たちにも共有します。必要があれば、雑談的な共有会を設けるのも良いと思います。枠組みを越える力がある人は、カジュアルな会話から、すべきことを見出す力も高いことが多いです。ですので、形にとらわれない会話の方が、本来の目的に沿ったアウトプットが出やすいです。
一言で言うと、組織間でバーチャルな繋がりを作るイメージですね。これが適用できるかどうかは、横連携が必要そうな各プロダクト組織事に、枠組みを越える人を入れられるかが全てです。それさえクリアできれば、うまくいくことが多いです。
一方、横連携が必要そうだが、枠組みを超えられる人があまりいない場合は、次のパターンを検討します。
役割毎に組織を作る
役割毎に組織を作る、というのは、企画、開発、QA、という塊で組織を作ることです。この形が良いところは、プロダクト間の情報連携が、組織の塊の中でされるため、横連携が自然に行いやすいことです。
また、同じ役割の人たちが同じ組織にいるため、役割事の専門性が高めやすいことです。様々なプロダクトに属している人たちの中で、同じ役割の人が同じ組織に属するため、知識・知見が流通しやすいです。
ただし、プロダクト単位で見ると、各組織に人が分散するため、オーナーシップを保ち続けるのはとても難しいです。しかも、仕組みを持ってオーナーシップを高めることも難しいです。したがって、プロダクトのオーナーシップが保たれるかは、プロダクトマネージャーの強烈な熱量に完全に依存します。
プロダクトマネージャーの超強力な推進力があれば、プロダクトの成長と、プロダクト間の横連携とメンバーのスキルアップを同時に見込める、それがこの形です。
プロダクト毎、役割毎、2つのパターンを紹介しましたが、それぞれメリット、デメリットがあります。そして、現実的には、ハイブリッドでいくことが多いと思います。ハイブリッドとは何か、次にご紹介します。
プロダクト毎の組織を基本とし、一部を役割毎の組織にする
基本的にはプロダクト毎に組織を作り、横連携の効果が高い部分のみ、役割事の組織を作るという方法です。よくあるケースとしては、マーケティングやCS、QAなど、横連携することの効果が高い役割は、その塊で組織を作るケースがあります。
ただし、この場合においても、役割毎に作られた組織は、プロダクト組織との間に壁ができやすく、オーナーシップが下がりがちです。これを解決する銀の弾丸はありません。たまに、役割毎の組織のオーナーシップが上がらないことを嘆くリーダーがいますが、それは構造上、仕方のないことです。
それが故に、リーダー自身がその負の側面を正しく理解することが何よりも重要です。そして、常に意識的に、役割事の組織にプロダクト組織の情報を共有するなど、リーダー自身がアクションを起こし続ける必要があります。
ハイブリッドにしても、組織の存在自体がもたらす負の側面は消えないので、常に意識し、解決していく必要があります。そして、その負の側面は、組織と組織の間に生じます。では、その負の側面を最小化するためにどうするか、次にご紹介します。
なるべく大きな塊で組織を作る
考え方はとてもシンプルです。組織を細切れにせず、なるべく大きな塊で組織を作ることです。どれぐらい大きな塊にできるかは、マネジメントの能力とチームの成熟度に依存するため、正解はありません。あえて言うならば、ギリギリ、マネジメントできる最大限の大きさが最適です。
安易に組織を細かくしたり、階層を作ったりすることは可能な限り避けるべきです。特にプロダクト毎の組織を作っているような場合は、組織を分割すると、マネージするプロダクトの単位も分割せざるを得なくなります。
むしろ、その前に、自身のマネジメント能力を上げる方法はないか、チームの成熟度をあげて、もっと組織の塊を大きくできないかを考えるべきだと思います。
それを考え抜いた結果、どうしても組織を分けたり、階層を作った方が、どう考えてもうまくスムーズにマネジメントできるようであれば、仕方なく組織の塊を小さくします。
ちなみに、組織の塊を大きくすると、人材育成の観点でサポートが行き届かないのではないのか、という意見があるかもしれません。確かにジュニアなメンバーが多いとそうかもしれません。しかし、プロフェッショナルが集まるチームであれば、人材育成の最大のポイントは、期待であり役割です。そのような環境のおいては、組織の塊が大きくても問題にはなりません。
最後に
プロダクトマネジメントにおける組織設計について、気を付けるべき視点と、組織として塊を作る際のアプローチについて書いてみました。色々と書きましたが、もちろん、常に理想と現実にはギャップがあります。
特に急激に成長している事業の場合は、チームが拡大するスピードも凄まじく早く、チームとしての成熟度を高くキープすることがとても難しいです。したがって、チームの塊をある程度小さくせざるを得ないことが多々あります。
しかし、フラットなチームであり続けることが最も理想であることを理解し、現実とのギャップを正確に捉え続け、少しでも理想に近づけるために自分自身とチームの成熟度をアップデートし続けること、それがもっとも重要だと思います。
そして、その時々の状態に応じて、組織をアップデートをし続けること、アップデートし続けることが、チームに混乱をもたらすのではなく、進化をもたらす、そんなチームになれば、理想だなと思います。
以上、複数のプロダクトをマネジメントする際の組織設計について、私が意識していることを書いてみました。少しでも参考なれば良いなと思います。
この記事が気に入ったらサポートをしてみませんか？