プラットフォームエコシステム戦略の大企業失敗構造——なぜ自社プラットフォームは機能しないのか

「プラットフォーム化」という夢と現実

2010年代後半、コンサルティングファームのレポートが「GAFAに学べ」を連発し、日本の大企業経営会議では「プラットフォームビジネスへの転換」が戦略キーワードになった。AmazonのAWSとマーケットプレイス、AppleのApp Store、GoogleのAndroidエコシステム——バリューチェーン型ビジネスからプラットフォーム型ビジネスへの転換が、次の10年の成長を決めるという論調が支配的だった。

この流れの中で、製造業・小売業・金融業・物流業など、さまざまな業種の大企業が「自社プラットフォーム」の構築に着手した。結果はどうだったか。多くのケースで、数百億円の投資と数年の時間を費やした末に、プラットフォームの利用者は期待の10分の1以下にとどまり、事業縮小または撤退に至った。

なぜこのような結果になるのか。プラットフォームビジネスの本質と、大企業の既存事業構造の間にある根本的な不適合を解析する。

プラットフォームビジネスの本質——「場」の設計と「鶏と卵」問題

プラットフォームビジネスとバリューチェーンビジネスの決定的な違いは、価値の生産者と消費者の関係性にある。

バリューチェーン型（例：製造業）では、企業が原材料を調達し、製品を生産し、流通させ、顧客に届ける。価値は企業が直接生産し、顧客に一方向に流れる。

プラットフォーム型（例：Amazon Marketplace）では、企業は「場（プラットフォーム）」を提供し、売り手と買い手が直接取引する。企業は価値の生産者ではなく、価値交換を可能にする「媒介者」だ。価値はプラットフォーム上の参加者が相互に生み出す。

この構造の違いから、プラットフォームビジネスには特有の「鶏と卵」問題が生じる。売り手（サプライサイド）は買い手（デマンドサイド）がいないと参加しない。買い手はサプライサイドの豊富さがないと価値を感じない。どちらも最初は少ないため、初期の臨界量（Critical Mass）に達するまでのコストは膨大だ。

Amazonはこの問題を自社在庫販売（バリューチェーン型）でデマンドサイドを確保し、徐々にマーケットプレイス（プラットフォーム型）に移行することで解決した。Googleは検索（無料サービス）でユーザーを集め、広告（プラットフォーム）で収益化した。いずれも、プラットフォーム構築の「前段階」となる事業を持っていた。

大企業の「プラットフォーム化」が失敗する5つの構造要因

要因1：既存バリューチェーンとの利益相反

大企業がプラットフォームを構築しようとすると、多くの場合、既存の取引先・パートナー・流通業者との利益相反が発生する。

例えば、製造業A社が自社製品のECプラットフォームを立ち上げると、既存の小売パートナーのビジネスを侵食する。パートナーとの関係を維持しながらプラットフォームを成長させることは困難で、どちらかを選ばなければならない。既存事業の利益を守ろうとすれば、プラットフォームへの投資が中途半端になる。

イノベーターのジレンマとカーブアウトが示す構造と同じだ。既存事業を守るインセンティブが、新規事業の可能性を制約する。

要因2：ネットワーク効果の経路依存性

ネットワーク効果（参加者が増えるほど価値が増す）は、プラットフォームビジネスの核心だ。しかしネットワーク効果は「先行者優位」を強く生む。既に多くの参加者を持つプラットフォームが存在する領域で、新規プラットフォームが参入しても、利用者を獲得することは極めて困難だ。

Amazonが支配するECマーケットプレイス領域に参入すること、LINEが支配するメッセージングに参入すること——これらには「なぜ既存プラットフォームではなくここを使うのか」という強力な差別化理由が必要だ。ほとんどの大企業が構築した自社プラットフォームは、この差別化理由を明確にできなかった。

要因3：ガバナンス設計の失敗

プラットフォームは「誰が誰とどのような条件で取引できるか」のルール設計（ガバナンス）が生命線だ。Apple App Storeは手数料30%・審査基準・セキュリティポリシーを厳格に管理することで、プラットフォームの品質を維持した。

大企業が構築するプラットフォームでは、このガバナンス設計が甘いケースが多い。「参加者に自由に使ってもらう」という方針で立ち上げると、低品質なコンテンツ・サービスが流入し、プラットフォームの価値自体が下がる。逆に厳格すぎると参加者が集まらない。このバランスは、プラットフォーム事業固有の運営ノウハウなしには設計できない。

要因4：データ戦略の後付け問題

プラットフォームの戦略的優位性は、蓄積されるデータにある。Googleは検索データから広告精度を高め、Amazonは購買データから商品レコメンドと在庫管理を最適化した。

多くの大企業は「プラットフォームを作れば、そこからデータが得られる」という後付け思考でプラットフォームを立ち上げる。しかしデータの価値は、ある閾値を超えた量と質がなければ生まれない。参加者が少ないプラットフォームから得られるデータは、意思決定に使えるほどの洞察を生まない。データ活用は、参加者規模が確保されてから初めて価値を持つ——これは「鶏と卵」問題の別バージョンだ。

要因5：組織の「プラットフォーム運営能力」の欠如

プラットフォームビジネスの運営は、製品を製造・販売するバリューチェーン型ビジネスとは全く異なるケイパビリティを必要とする。

コミュニティマネジメント、プラットフォームポリシーの執行、詐欺・悪用対策、参加者間の紛争解決——これらは製造業や小売業の組織が事前に持っているスキルではない。外部採用またはM&Aで調達しようとしても、組織文化・意思決定プロセス・KPI設計がバリューチェーン型のままでは、調達したケイパビリティが機能しない。

成功したプラットフォームへの転換——何が違ったのか

失敗ばかりを論じるのでは不十分だ。大企業がプラットフォームへの転換に一定の成功を収めたケースも存在する。

SAPのケース： SAPはERPソフトウェアのバリューチェーン型企業から、SAP App Centerというパートナーエコシステムを構築した。成功の鍵は、既存顧客基盤（デマンドサイド）が最初から存在したことと、「ERPの拡張機能を提供したいISV（独立系ソフトウェアベンダー）」というサプライサイドとの利害が一致したことだ。鶏と卵の問題を、既存事業のアセットで解決した。

Salesforceのケース： Salesforce AppExchangeは、CRM市場でのシェアを利用してデマンドサイドを確保し、SFAの拡張機能を提供したいISVをサプライサイドとして組織化した。同様の構造だ。

共通するパターンは、既存事業が持つ「デマンドサイドの資産」を出発点とし、そのデマンドを満たすサプライサイドを設計したことだ。プラットフォームを「ゼロから作る」のではなく、既存の顧客基盤をプラットフォームに転換した。

大企業がプラットフォーム戦略を検討するための問い

プラットフォームビジネスへの転換を検討する際、最初に問うべき3つの問いがある。

問い1：我々は既に誰かに「場」として使われているか？ 既存の顧客・パートナーが、自社のプラットフォームを介して相互に価値交換している状態が既に存在するか。存在しないなら、ゼロからプラットフォームを作ることになり、成功確率は著しく低い。

問い2：構築するプラットフォームは、既存取引先の代替か補完か？ 代替になるなら、既存取引先との関係を犠牲にする覚悟が必要だ。補完になるなら、既存取引先がプラットフォームの参加者として協力する構造を作れる。

問い3：プラットフォームを運営する組織能力をどう調達するか？ 外部採用、M&A、JV設立——どの手段でプラットフォーム運営能力を獲得するか、そしてその能力が既存組織の文化に飲み込まれない設計をどう作るか。

オープンイノベーションの幻想が示すように、「つながれば価値が生まれる」という幻想がプラットフォーム戦略にも潜んでいる。プラットフォームは「場を作れば人が集まる」のではなく、「人が集まりたい理由を設計して、初めて場になる」のだ。この順序を逆にした戦略は、どれほど予算を積んでも機能しない。

---

本稿で言及したケース・概念の主要参考：Parker, Van Alstyne, Choudary「Platform Revolution」2016年、SAP App Center公式資料、Salesforce AppExchange公式資料。