経済圏の選択が検証の順番を決める
新規事業で「何を最初に検証すべきか」を決めるとき、市場の競争状態によって答えがまったく変わる。レッドオーシャンに乗り込むなら課金検証が先。ブルーオーシャンを狙うならまず価値を作って人を集めるのが先。この順番を間違えると、どれだけ良いプロダクトを作っても事業として成立しない。
根本にあるのは「最終的にどの経済圏に繋ぐのか」という問いである。既存の競争が激しい経済圏に繋ぐと決めた時点で、その経済圏のルール（ユーザー獲得コストとLTVのバランス）に縛られる。課金検証を後回しにしていい理由がなくなる。逆に、まだ誰も定義していない経済圏を作ろうとしているなら、課金の形は後から設計すればいい。先にやるべきは「この価値に人が集まるか」の検証である。
ある新規事業の事例から見えたこと
あるC向けアプリの振り返りで、この区別が具体的に浮かび上がった。競合がひしめくレッドオーシャンに参入したにもかかわらず、「アプリの体験が良ければ課金は後からでいい」というボトムアップ的な判断で課金実装を後回しにし続けた。結果としてLTV検証ができないまま開発が進み、グロース条件が不明なまま時間と予算を使ってしまった。
この判断ミスの背景には、いくつかの構造的な問題があった。
まず、効果的な探索には全方位的探索から仮説検証型探索への段階的移行が不可欠であるにもあるように、探索の初期段階ではどこに焦点を当てるかの判断が決定的に重要になる。このプロジェクトでは、AIを活用した体験の「技術的な不確実性を減らす」方向に焦点が寄りすぎた。AIで従来の体験をどこまで再現できるかという問いに集中するあまり、そもそもその体験に対して人が金を払うかという根本的な問いが後ろに回った。
次に、KSF（主要成功要因）の特定が遅れた。その領域に初めて取り組むチームが、先行プレイヤーから学ぶ基本を怠った。ドメイン専門家から早期に重要な中間指標を学んでいれば、「何を検証すべきか」の優先順位はもっと早く見えていたはずである。プロダクト開発の成功は顧客ジョブの理解と仮説検証にかかっているが示すように、顧客が本当に解決したいジョブを理解しないまま技術検証に走ることは、検証の順序そのものを間違えることになる。
レッドオーシャンの戦い方
既存プレイヤーがいる市場で戦うなら、コンセプトを尖らせることが前提になる。差別化できないレッドオーシャン参入は消耗戦にしかならない。そのうえで、尖らせたコンセプトに対して「払ってでも使いたい」という反応があるかを早期に確認する必要がある。
先述の振り返りで出た具体的な教訓は、プロトタイピング段階での課金検証である。アプリケーションとして完成させる前に、「単発で課金してでも使いたいと思うユーザーがいるか」を検証できたはずだった。売れるようにしてから作るの原則がここでも当てはまる。プロダクトの完成度を上げてから課金を考えるのではなく、課金意向を確認してからプロダクトを作り込むべきだった。
また、予算規模とゴールの整合も重要だった。多額の予算が投下されていない状況でビッグサクセスを狙うのは、予算規模と合っていない。スモールサクセスを確実に取り、そこからスケールする道筋を描く方が、限られたリソースの中では合理的である。事業成功のための持続可能なビジネスモデルと製品・サービスが示す通り、持続可能なモデルの構築は初期段階から意識すべきものである。
ブルーオーシャンの戦い方
一方、まだ誰もやっていない領域であれば、話が変わる。比較対象となる経済圏がないので、課金モデルの正解も存在しない。この段階で課金検証を急ぐのは、イノベーションのジレンマは既存企業の持続的成長を阻害する構造的問題であるで指摘されるような、既存の評価軸で新しいものを測ろうとする罠に近い。
ブルーオーシャンで先にやるべきは、価値とは、人が行動を変えるほどの”意味”や”効果”であるにあるように、人の行動を変えるほどの価値を作ることである。価値が成立すれば人が集まり、人が集まればマネタイズの選択肢が生まれる。
判断の分岐点
結局のところ、最初の問いは「自分たちが接続しようとしている経済圏はどこか」に集約される。
- 既存の経済圏に接続する場合（レッドオーシャン）: その経済圏のルール（獲得コスト、LTV、リテンション等）に縛られる。ルールに適合するかの検証（＝課金検証）を最優先にする。コンセプトの差別化がなければ参入しない
- 新しい経済圏を作る場合（ブルーオーシャン）: ルール自体が未定義。まず価値を証明し、人を集め、その後にルール（課金モデル）を設計する。イノベーションの普及と採用において、アーリーアダプターは重要な役割を果たすことを踏まえ、初期ユーザーの獲得と価値の実感を優先する
この判断を初期段階で明確にしておかないと、レッドオーシャンにいるのにブルーオーシャン的な進め方をしてしまい、検証すべきことを検証しないまま時間を使うことになる。想像や理想は仮説の原料であり、結論ではなく出発点として扱うという原則に立ち返り、自分たちがどちらの市場にいるのかを冷静に見極めることが、初期検証の設計を根本から左右する。
フライホイールの罠
補足として、フライホイール（ループ構造）の検証にも同じ構造がある。あるプロジェクトでは「データが蓄まればレコメンド精度が上がり、満足度が上がり、さらにデータが蓄まる」というフライホイールに着目しすぎた結果、「そもそもユーザーが最初に触りたいと思うか」という手前の問いが見えなくなった。データが十分にない初期フェーズでフライホイールを回そうとするのは無理がある。まずはフライホイールの入り口（初期獲得とアクティベーション）が成立するかの検証が先である。