第7章 02：競合はより良い製品を必要としない——あなたのビジネスの下にあるキルスイッチだけでいい#
競合はより良いマーケティングも、より良い価格設定も、より良いチームも必要としない。あなたのビジネスが立っている土台を所有し、それを引き抜くだけでいい。
これはほとんどの創業者が見えない致命的な一撃だ。彼らは類似製品を売る競合を研究し、起こらないかもしれない正面対決に備えて時間を費やす。一方、本当の脅威は静かに足元に座っている——ビジネス全体が依存するプラットフォーム、API、流通チャネル、データソース。その土台が動いたとき、建物は傾くのではない——崩壊する。
足元の地面を失う3つの方法#
このパターンは業界と時代を超えて繰り返され、3つの異なるプレイブックに従う。
接続を切断する。 他者のAPIの上にプロダクトを構築した。彼らのシステムからデータを取得するか、彼らのプラットフォームを通じて配信している。ある日、条件が変わる——レート制限、価格、承認要件——あるいはアクセスが完全に取り消される。プロダクトは理論上まだ動く。だが処理するデータがなく、到達するユーザーがなく、流れるパイプラインがない。蛇口は閉まった。干上がった。
これは仮定の話ではない。Twitterの2023年API価格変更は、一夜にして数百の分析ツールとボットツールを殺した。App Storeのアルゴリズム更新は、1サイクルで販売者のオーガニック可視性を蒸発させた。プラットフォームは彼らを狙ったわけではない。自社の利益のために最適化しただけで、彼らの利益は方程式に入っていなかった。
機能を複製する。 プラットフォームの機能を拡張する成功したツールを構築した。プラットフォームがあなたのトラクションに気づき、同じ機能をネイティブに構築する。より良く作る必要はない——作るだけでいい。彼らのバージョンは統合済みで、無料で、デフォルト。あなたのは外部で、有料で、オプション。ユーザーは競合が優れているから切り替えるのではない。代替品が毎日使っている製品の中にすでにあるから、切り替えコストがゼロになるのだ。
これが「プラットフォーム吸収」パターンだ。プラットフォームは百花を咲かせ、どれが蜂を引き寄せるか観察し、あなたの隣に自社版を植える——ただし彼らの花は自動的に日光と水を得る。あなたはコンセプトの証明を作った。彼らは最終製品を作った。
ルールを変える。 ビジネスを成立させている規制、基準、市場規範の下で運営している。より大きなプレイヤー——しばしばロビイング力や市場影響力を持つ——がそのルールを自社モデルに有利で、あなたに不利な方向に変えるよう働きかける。収益の30%を食う新しいコンプライアンス要件。彼らのアーキテクチャにちょうど合致する新しい業界標準。あなたが通過する必要がある場所にちょうど障壁を作る新しい規制。
ルール変更は最も防御が難しい。合法に見えるからだ。契約違反はない。規約違反もない。ゲームが変わっただけ——ゲームの設計に最も影響力を持つプレイヤーに有利な方向に。
依存関係監査#
脅威が構造的なら、対応も構造的でなければならない。依存関係が致命的になる前に、体系的に特定、評価、緩和する方法が必要だ。
ステップ1：すべての外部依存関係をリストアップ。 事業全体を歩く——プロダクト、流通、データ、インフラ、決済、コンプライアンス——サードパーティに依存するすべてのポイントをリストアップする。徹底的に。明白なもの（クラウドホスティング、決済プロセッサ）と明白でないもの（プロダクトが構築されているオープンソースライブラリ、顧客が要求する業界認証）を含める。
ステップ2：置換コストを評価。 各依存関係について、置き換えに必要な時間、費用、労力を見積もる。簡単なものもある：決済プロセッサの切り替えは数日。事実上不可能なものもある：2年分のカスタムインフラを構築したクラウドプラットフォームからの移行は6ヶ月かかり、年間収益を超えるコストになり得る。
ステップ3：致命的な依存関係をマーク。 依存関係が致命的なのは：置換コストが高い（30日以上または資金ランウェイの20%以上）かつ実行可能な代替が存在しない場合。これらがキルスイッチだ。他の誰かがそれを握っている。
ステップ4：発動確率を評価。 すべての致命的依存関係が同等に危険なわけではない。クラウドプロバイダーがあなたをシャットダウンする——支払いをしていれば可能性は低い。プラットフォームが競合製品を立ち上げるためにAPIアクセスを取り消す——これには文書化された先例がある。発動確率が中〜高の致命的依存関係に緩和の焦点を当てる。
致命的依存関係を減らす4つの戦略#
キルスイッチを特定したら、4つの選択肢がある。どれも無料ではない。どれも死ぬよりは安い。
自前で構築する。 外部依存を内部能力で置き換える。最も高価で、最も安全。特定のデータソースに依存しているなら、自社でデータ収集メカニズムを構築できるか？流通プラットフォームに依存しているなら、顧客への直接チャネルを構築できるか？コストは高いが、結果は構造的独立だ。
罠：すべて自分で構築しようとすること。できない。目標はゼロ依存ではない——ゼロ致命的依存だ。自分を殺しうるものだけ自前で構築する。
ソースを多様化する。 1つのプラットフォーム、1つのサプライヤー、1つのチャネルではなく、複数に分散させる。1つが切られても、他が生き延びさせてくれる。依存関係管理のポートフォリオアプローチ。
キーメトリクスは集中度。重要な入力（トラフィック、収益、データ、流通）の50%以上が単一ソースから来ているなら、集中している。単一ソースから30%以下が合理的なターゲットだ。
迂回する。 ビジネスモデルを再設計し、依存関係を完全に排除する。プロバイダーを替えるのではなく、ステップ自体を除去する。脆弱なステップが不要になるようモデルを変えられるか？ディストリビューターを通さず直接行けるか？同じインフラを必要としない別の技術を使えるか？
最もクリエイティブな選択肢であり、しばしば最も強力だ。第一原理からアーキテクチャを再考することを強いる。
同盟を組む。 構築、多様化、迂回のいずれもできない場合、同じ依存関係を共有する他の企業と連合を組む。集団交渉力は個人に勝る。プラットフォームプロバイダーは、エコシステムの15%を占めるグループを切断する可能性は、0.1%の単独プレイヤーを切断するより低い。
同盟は脆弱で遅い。だが支配的プラットフォームに対しては、唯一の実行可能な選択肢であることがある。
依存思考の落とし穴#
契約の偽りの安心感。 3年契約は更新時の値上げ、価値を侵食する機能廃止、プロバイダーの品質低下からは守ってくれない。契約は法的文書であり、戦略的保証ではない。
漸進主義の罠。 依存関係は徐々に成長する。1つのAPI統合。次に2つ目。次にプラットフォーム固有の機能に依存するカスタム機能。各ステップは小さく見える。累積効果は深い依存——壁に入り込む蔦のように、植えるのは簡単で、除去はほぼ不可能だ。
依存を心配すべきタイミングはアーキテクチャの決定をするとき、危機になってからではない。単一の外部エンティティへの依存を増やすすべての決定がトリガーすべきだ：「これが消えたらどうなる？」
「彼らも我々を必要としている」という妄想。 創業者は関係が相互的だと主張して依存を合理化する——「我々はプラットフォームにトラフィックを送っているから、切り離すはずがない。」ほぼ常に間違っている。プラットフォームと単一アプリの間の非対称性は巨大だ。彼らは丸め誤差を失う。あなたはすべてを失う。構造的に非対称な関係で対称性を仮定するな。
30日テスト#
夜も眠れなくなるべき演習がこれだ。
依存関係リストを取り出す。それぞれについて1つの質問に答える：この依存関係が明日消えたら——完全に、予告なしに——ビジネスは何日間運営を続けられるか？
正直に。「回避策を見つけるまでの日数」ではない——「ビジネスが機能停止するまでの日数」だ。収益なし、プロダクトなし、サービスなし。
30日未満の依存関係は構造的脆弱性だ。7日未満は緊急事態。ゼロ日——ビジネスが即座に停止——は時限爆弾だ。
時限爆弾はいくつあるか？
この演習を初めてやるほとんどの創業者は、予想以上に多いことを発見する。それが目的だ。この演習は安心させるためではない。正確にするためだ。
すべての依存関係を排除することはできない。あらゆるビジネスは電力、インターネット、法制度に依存している。だが致命的かつ制御可能なもの——誰かがシャットダウンできるスイッチを持ち、露出を減らす現実的な選択肢があるもの——を特定することはできる。
生き残る創業者は依存関係がない人ではない。依存関係がどこにあるか正確に知り、それぞれがどれほど危険か知り、そのうちの1つが——もしではなく、いつ——横道に逸れたときに何をするか知っている人だ。
自分の床を知れ。誰がそれを作ったか知れ。そして彼らが板を引き抜き始めたときの計画を持て。