新規事業の事業性検証、
何をどの順番で確かめるか

「アイデアは出た。でも、次に何をすればいい？」——新規事業を担当するBizDev担当者が最初にぶつかる壁のひとつが、事業性検証のプロセスをどう設計するかです。多くのチームが「全部同時に考えて行き詰まる」という状況に陥りますが、これは検証の順番を間違えているケースがほとんどです。

この記事では、新規事業の事業性検証を「3層構造」に整理し、何をどの順番で確かめるべきかを実務的に解説します。正しいシーケンスで進めることで、無駄な開発コストを避け、意思決定のスピードを上げることができます。

1. 事業性検証の全体フレーム（3層構造）

事業性検証には、確認すべき3つの問いがあります。そしてこれらは、必ず①→②→③の順番で検証する必要があります。

• ① 課題の実在性：そのペインは本当に存在するか
• ② 解決策の妥当性：自分たちのアプローチで解決できるか
• ③ 収益化の成立性：事業として持続可能か

多くのチームが失敗するのは、③（収益モデル）や②（プロダクト設計）から入って、後になって①（そもそも課題がない）という根本的な問題に気づくからです。土台となる「課題の実在性」が確認できていないまま、上位レイヤーに投資しても、そのリソースはすべて無駄になります。

2. 第一段階：課題の実在性を確かめる

最初に検証すべきは「そのペインは本当に存在するか」です。ここで重要なのは、「解決したいと思っているか」と「お金を払う用意があるか」を峻別することです。多くの人が「あったら便利」と答えても、実際にお金を払うかどうかは全く別の話です。

顧客インタビューの設計

課題の実在性を確かめるには、顧客インタビューが最も有効な手段です。ただし、インタビューの設計を間違えると、聞きたいことを聞く「確証バイアス」に陥ります。以下の原則を守ることが重要です。

• ソリューションを語らない：「こういうサービスを作ろうと思っているのですがどうですか？」はNG。課題の実態を聞く
• 過去の行動を聞く：「〜したいですか？」ではなく「〜をどうやって解決しましたか？」と聞く
• 費用と時間を確認する：「その課題を解決するために今いくら払っていますか？どのくらいの時間をかけていますか？」

最低でも10〜15件のインタビューをこなし、「課題の言語化」「現在の解決策とその不満」「その課題にかけているコスト」の3点を整理しましょう。

3. 第二段階：解決策の妥当性（プロトタイプ検証）

課題の実在性が確認できたら、次は「自分たちのアプローチで解決できるか」を検証します。ここで多くのチームがやりがちな失敗が「作りすぎ」です。MVP（Minimum Viable Product）の本質は「最小限の機能で最大限の学びを得る」ことであり、完成度の高いプロダクトを作ることではありません。

何を検証するために何を作るか

MVP設計で最初に問うべきは「何の仮説を検証したいか」です。その仮説を検証するために必要な最低限の機能だけを実装します。

「ウィザード・オズ型」と呼ばれるMVPは特に有効です。ユーザーにはシステムで自動化されているように見せながら、実際には裏でオペレーターが手動で対応する形式です。システム開発コストをかけずに「ユーザーが価値を感じるか」を検証できます。

4. 第三段階：収益化の成立性（Unit Economicsチェック）

解決策の妥当性が確認できたら、最後に「事業として持続可能か」を確認します。ここで最も重要な指標がUnit Economics、つまり1顧客あたりの経済性です。

LTV / CAC比率の目安

Unit Economicsの基本は、顧客生涯価値（LTV）と顧客獲得コスト（CAC）の比率です。一般的な目安として、SaaSビジネスではLTV:CAC = 3:1以上が持続可能なビジネスの基準とされています。

検証初期の段階では、これらの数値が正確に出なくても構いません。重要なのは「方向性」です。インタビューで得た「支払い意欲のある金額」と「獲得にかかりそうなコスト」から、ビジネスとして成立するかの試算ができるかどうかを確認してください。