マルチプロダクト戦略とコンパウンド戦略の違い、そして共通基盤をどこまで持つべきか
B2B SaaS事業がPMF(プロダクトマーケットフィット)を達成し、次なる成長を模索するフェーズにおいて、多くの経営者やプロダクトリーダーは「単一プロダクトの限界」に直面します。顧客の深い課題に向き合うほど、解決すべき業務ドメインは隣接領域へと広がり、自ずと第2、第3のプロダクトの検討が始まるからです。しかし、ここで安易に製品を増やすだけでは、将来的に開発の鈍化やデータの分断を招く「マルチプロダクトの罠」に陥りかねません。本稿では、近年注目を集めるコンパウンド戦略との違いを整理し、持続的な成長を支えるための共通基盤の境界線をどこに引くべきか、その意思決定の極意を論じます。
マルチプロダクト戦略とコンパウンド戦略の違い
マルチプロダクト戦略とは：数の拡大と市場拡張
マルチプロダクト戦略とは、複数の異なる製品を一つの法人が展開していく戦略を指し、いくつかの実現方法があります。ひとつは、事業の成長過程で顧客の別のニーズを発見し、既存のソリューションだけでは解決できない領域に対してセカンドプロダクト、サードプロダクトを自ら生み出していくパターンです。もうひとつは、買収や事業提携によってポートフォリオを埋めていくパターンです。
この戦略を採る理由も一様ではありません。市場拡張、既存顧客に対するLTVの最大化、特定事業への依存を避けるためのリスク分散、営業チャネルの活用、あるいは将来的な事業価値の向上など、目的は多岐にわたります。つまり、マルチプロダクト戦略とはまず「複数プロダクトを持つこと」に重心のある概念であり、プロダクト同士がどの程度連携しているかどうかは必須条件ではありません。
極端に言えば、同じ会社が複数のSaaSを持っていても、それぞれが異なる顧客層、異なる業務ドメイン、異なるブランドで展開されているなら、それは十分にマルチプロダクト戦略といえます。そこでは「複数あること」自体が本質であり、「どれだけ統合されているか」は二次的なテーマになり得ます。
コンパウンド戦略とは：データの複利とプロダクト間の相互作用
これに対してコンパウンド戦略は、単に複数プロダクトを持つことではなく、それらが相互に価値を増幅し合うことを前提に設計された戦略です。最初から複合的なソリューションを提供する前提で、ビジネスモデルやソフトウェアのアーキテクチャ、データ構造、販売導線まで含めて設計されます。
そのため、コンパウンド戦略における各プロダクトは、隣接するビジネスドメインを対象にしていたり、顧客属性が近かったりすることが多くなります。共通の顧客基盤、共通のデータモデル、共通の業務文脈があることで、単体プロダクトの足し算ではなく、組み合わせによる複利的な成長が可能になるからです。ここで重要なのは、プロダクト横断でデータが蓄積され、プロダクト間の連携によって導入効果やスイッチングコストが高まることです。
したがって、コンパウンド戦略はマルチプロダクト戦略の一種として理解することもできますが、両者は同義ではありません。マルチプロダクト戦略の中には、各製品がかなり独立して存在しているものもあります。一方でコンパウンド戦略は、独立性よりも相互作用を重視します。言い換えれば、マルチプロダクト戦略が「数」の概念に近いのに対し、コンパウンド戦略は「関係性」と「設計思想」の概念です。
どこに向けて価値を提供するのか
ソフトウェアにおけるマルチプロダクト戦略を考える際に難しいのは、どこまでを共通基盤として持ち、どこからを個別最適に任せるかという線引きです。ここで重要なのは、技術的に共通化できるかどうかではなく、顧客価値の観点から見て共通であるべきかどうかです。
たとえばPlatform Engineeringの発想で考えれば、インフラ管理、CI/CDパイプライン、監視、セキュリティ基盤、開発者向けテンプレートなどは、プロダクトの市場や業務ドメインが異なっていても比較的共通化しやすい領域です。これらは顧客から直接見える差別化要素ではなく、ソフトウェアを継続的に届ける事業者としての基盤能力だからです。内部の生産性や品質を高めるために共通化する価値は大きいでしょう。
しかし、B2B SaaSにおいて重要なSaaSコントロールプレーンについては、もう少し慎重な検討が必要です。SaaSコントロールプレーンとは、テナント管理、認証認可、料金プラン設定、契約、課金、監査ログなど、運用上共通して必要になりやすい機能群を指します。表面的にはどのプロダクトにも共通して見えるため、まとめて共通基盤化したくなります。
参照：「SaaSコントロールプレーンとは？コントロールプレーンの役割と重要性」 https://saasus.io/blog/saas-control-plane-importance
ところが実際には、認証認可ひとつ取っても、B2B SaaSにおいてはテナント情報と強く結びついています。そして「テナントをどう定義するか」はビジネスドメインによって異なります。企業単位なのか、部門単位なのか、拠点単位なのか、あるいはサプライチェーン全体を跨ぐのか。その違いは単なる実装の差ではなく、製品の価値そのものに関わる設計上の前提です。
このため、安易に共通基盤化を進めると、本来は各プロダクトごとに持つべきビジネス上の自由度を奪い、設計レベルの制約を強く生み出してしまうことがあります。共通化によって短期的な効率は得られても、長期的には市場適応力を落とし、アジリティを損なうリスクがあるのです。
ブランドは統一された方が望ましいのか
ここで関連してくるのが、ブランド統一の問題です。複数のプロダクトがあるなら、ブランドもひとつにまとめた方がよいのか。あるいは別ブランドで持つべきなのか。これもまた、一律に決められる話ではありません。
ブランドは単なるロゴや名称ではなく、「誰にどのような価値を届けるのか」という約束そのものです。顧客課題、購買プロセス、導入主体、運用責任者、競合環境が大きく異なるのであれば、ブランドを無理に統一することで、かえって価値提案がぼやけることがあります。逆に、顧客が同じで、複数製品を連続的に評価・導入する文脈が強いなら、ブランド統一は信頼や拡張性の訴求に役立ちます。
つまり、ブランドを統一するかどうかも、内部都合ではなく顧客の認知構造から考えるべきです。同じ会社が提供していることが顧客価値になるのか、それとも見えない裏側で統合されていれば十分なのか。その見極めが必要です。例えば、ブランドを顧客に意識させることで新規事業の仮説検証においては、ブランドの持つイメージ自体がノイズになってしまうリスクも存在します。課題そのものの解決に至るプロダクトかという観点よりも、ブランドの持つイメージが先行してしまい、認知の歪みが生じて仮説検証の精度が著しく下がるのです。その場合、スタートダッシュこそブランドの力を借りて実現できる可能性はありますが、課題解決に至っていない場合は失速してしまうでしょう。
ホテルブランドのメタファー
この点を考えるうえで、マルチプロダクト戦略はホテルブランドの構造に少し似ています。同じ系列が運営するホテルであっても、ラグジュアリー、ビジネス、長期滞在、リゾートなど、ブランドごとに価値観も対象顧客も異なります。系列全体としては会員基盤やオペレーション、人材プール、購買、システム基盤を一部共有しているかもしれませんが、顧客から見える体験は必ずしも統一されていません。
むしろ重要なのは、どこを統合し、どこをブランドごとに独自化するかが丁寧に設計されていることです。系列横断のIDが便利に働くケースもあれば、それぞれのブランドが独立した世界観を持つことで価値を発揮するケースもあります。これはソフトウェアでも同じで、認証や課金が統合されていることが必須の体験なのか、それとも内部の効率化にとどめるべきなのかを見極める必要があります。
共通基盤にするとき・しないときのメリット、デメリット、リスク
共通基盤にするメリットは明確です。重複開発を減らせること、運用やセキュリティ水準を揃えやすいこと、横断データを活用しやすいこと、組織としての学習を積み上げやすいこと。特に顧客接点やデータモデルが近い場合には、クロスセルやアップセルの導線まで含めて大きな効果を生みます。
一方でデメリットもあります。共通基盤は、一度作ると多くのプロダクトに影響を及ぼすため、変更コストが高くなりがちです。また、その中で最も複雑な要件に引っ張られて、全体が過剰に重たくなることもあります。本来は軽く始められたはずの新規プロダクトが、既存基盤への適合を求められることで立ち上がりを遅らせることもあります。
リスクとして特に大きいのは、「共通化そのものが目的化すること」です。共通であることは手段であって、目的ではありません。顧客価値を高めるため、あるいは事業の俊敏性を高めるために共通化するのであって、統一感があるから、管理しやすいから、という理由だけで進めると失敗しやすい。逆に、共通化しない場合にも、各プロダクトがバラバラに似た機能を持ち、後から統合コストが膨らむリスクがあります。
おわりに
マルチプロダクト戦略において重要なのは、複数の製品を持つこと自体ではなく、それぞれのプロダクトがどの顧客にどの価値を届けるのかを明確にし、そのうえでどこを共通化し、どこを分けるかを意思をもって設計することです。
コンパウンド戦略は、その中でも特に、プロダクト間の関係性とデータの複利を重視する考え方です。しかし、すべてのマルチプロダクト企業が最初からコンパウンドである必要はありません。むしろ重要なのは、自社が目指す価値提供の形に対して、ブランド、アーキテクチャ、コントロールプレーンの境界が整合しているかどうかです。
共通基盤にすべきか否かという問いに万能な正解はありません。ただひとつ言えるのは、技術からではなく、顧客価値と事業戦略から逆算して決めるべきだということです。その視点があって初めて、マルチプロダクト戦略は単なる製品数の拡大ではなく、持続的な事業の厚みへと変わっていきます。
Spread the word:
