新規事業の進め方──課題を見つけた後の3つの判断基準

顧客の課題が見つかった。でも「課題がある」と「事業になる」は別の問いです。この記事では、課題検証（CPF）の後に企画職が直面する3つの判断──CPF結果の読み方と分岐、事業性ゲートの通し方、ソリューション検証（PSF）の進め方──を、実務経験をもとに整理します。

顧客にインタビューして、課題（ニーズ・ペイン）が見つかった。
「毎週5時間かけて手作業でやっています」「今の方法には不満があって、他のツールを探しています」。行動を聞いたら、課題の証拠が出てきた。よし、ではこの課題を解決するサービスを作ろう。

......ここで、次の落とし穴が待っています。

課題が本物でも、技術的に実現できなければ絵に描いた餅です。市場が小さすぎれば事業として成立しません。そしてもう1つ、そもそも課題が想定通りではなかったケースもあります。

CPF（Customer Problem Fit = 課題検証）とは、「この課題は本物か？」を顧客インタビューで検証するプロセスです。意見ではなく行動を聞くことで、お世辞や曖昧な仮定に惑わされず、課題の実在を確かめます。

なお、CPFに入る前の段階──「あったらいいね（ニーズ）」と「実際にコストをかけて対処している（ペイン）」を見分けること──については、こちらの記事で整理しています。

新規事業が失敗する本当の理由──ニーズとペインの混同が生む4つの罠

CPFの実践方法（インタビュー設計から判定基準まで）については、こちらを参照してください。

課題があっても事業にならない──新規事業で検証すべき3つの仮説

まず前提を整理します。

新規事業の初期段階では、検証すべき仮説は1つではありません。ペインの仮説、ソリューションの仮説、事業性の仮説。この3つがセットです。

• ペインの仮説: 顧客は〇〇で困っている（CPFで検証済み）

• ソリューションの仮説: この方法で解決できる

• 事業性の仮説: 事業として成立する（作れる、売れる、儲かる）

CPFで検証したのは、ペイン側だけです。残り2つはこれから検証する必要があります。そして、ペインの検証結果によって、次のアクションが分岐します。

課題検証（CPF）の結果で分岐する──3つのケースと次のアクション

CPFの結果は大きく3つのケースに分かれます。

ケース1: 想定通りのペインが確認できた

最も順調なケースです。仮説通りのペインが実在し、顧客が実際に対処行動を取っていて、コストも定量化できた。

では、CPFが「達成できた」とはどう判断するのか。前の記事で紹介した鶴岡友也氏（BLUEPRINT Holdings CTO）の課題重要度レベルでいえば、レベル3以上（別の解決策にコストをかけて対処している、またはより良い解決策を探している）が複数の顧客から確認できた状態です。加えて、Rob Fitzpatrickが『The Mom Test』（2013年）で提唱するコミットメントの概念──「テストユーザーになっていただけますか？」「同じ課題を持つ方をご紹介いただけますか？」──に対して行動で応えてくれるなら、ペインが本物である強いシグナルになります。

この条件が揃えば、次のステップ（事業性チェック → ソリューション検証）に進みます。

ケース2: 想定と違うペインが見つかった

これが実は一番多いケースかもしれません。

想定していたペインがなかった。あるいは、想定していたペインはあったが、行動を聞いていくと実はそのペインの手前や周辺に、もっと根深い課題があることがわかった。いずれにしても、当初の仮説セットでは捉えきれない構造が見えてきます。

こうなったら、仮説セットを組み替えます。新しいペインを軸に、ソリューションの仮説も事業性の仮説も立て直し、CPFを再走します。事業の方向転換をピボットと呼びますが、この段階での組み替えは仮説レベルの軽いピボットです。遠回りに見えますが、ずれた仮説のまま進むよりはるかに早い判断です。

以前、ある事業領域のインタビューで経験があります。予算の制約から60名にアンケート、6名に深掘りインタビューという設計で進めました。仮説として想定していた課題は確かに存在していました。ところが行動を聞いていくと、同じ業界・同じ課題でも、事業者の立地条件や意思決定に関わるステークホルダーの構造が地域によって全く異なることがわかりました。当初は「業界共通の課題」を前提にしていましたが、実際にはセグメントを分けて仮説を立て直す必要があった。行動を聞いていなければ、この構造の違いには気づけなかったと思います。

ケース3: ペインはなかった、でもソリューションはある

ペインが確認できなかった。でも手元には技術やソリューションのアイデアがあります。この場合、ソリューション起点で、当てはまりそうな別の業界やペインを探しにいくという選択肢があります。

新規事業のアプローチは大きく2つに分かれます。マーケットイン（顧客の課題を起点にソリューションを考える）と、プロダクトアウト（技術やソリューションを起点に、それが解決できる課題を探す）です。CPFは本来マーケットインのプロセスですが、ペインが見つからなかった場合は、プロダクトアウトに切り替えるという判断もあります。

有名な例がSlackです。Slack Technologies（当時のTiny Speck）は、もともとオンラインゲーム「Glitch」を開発していました。ゲーム自体は2012年にサービスを終了しましたが、開発チームが社内コミュニケーション用に作っていたツールが、他のチームでも使えるのではないかと気づいた。ゲームのペインではなく、「チーム内コミュニケーションの分断」という別のペインにソリューションを当て直したわけです。プロダクトアウトで事業そのものを転換した、大きなピボットの代表例です。

外部のサイトですが、Slackを含むピボットの成功事例や実施時の注意点については、東大IPCのコラムが参考になります。

ピボットとは？ 成功事例や注意点を解説（東大IPC）
https://www.utokyo-ipc.co.jp/column/pivot/

ただし、注意が必要です。「このソリューションには価値があるはずだ」という確証バイアスが働きやすいのもこのケースです。ソリューションへの愛着が、冷静な判断を曇らせることがあります。プロダクトアウトで別のペインを探す場合でも、見つけたペインに対してはCPFの原則（「否定しにいく」）を適用すべきです。

事業性を確かめる──ソリューションを作る前の3つの観点

どのケースであれ（ケース2・3の場合は新しい仮説セットを立て直した後に）、次に確認すべきは事業性です。

新規事業のプロセスには、次のフェーズに進む前に「進む/やめる」を判断するチェックポイントがあります。これをゲートと呼びます。シリーズ第1回で紹介したステージゲート法でいえば、ステージ2（課題検証）とステージ3（ソリューション検証）の間にあるゲートです。技術的に作れないもの、市場が小さすぎるもの、法的にアウトなものは、ソリューション検証をしても意味がありません。ここで明らかにNGなら、早めに止めるか方向転換します。

企画職の立場で言えば、このゲートは「プロトタイプを作る前に、上に持っていけるかどうかを自分で判断する」プロセスでもあります。作ってから「やっぱり事業にならない」と上に報告するのと、作る前に「この3点を確認したところ、次に進む条件を満たしています」と言えるのでは、その後の展開がまるで違います。

技術的に実現できるか

コアとなる技術が存在するか。自社で開発可能か、外部パートナーが必要か。タイムラインは現実的か。

ここでは「完璧に作れるか」ではなく、「原理的に不可能ではないか」を確認します。詳細な技術検証はこの段階では不要です。

企画職として大事なのは、関連する技術や論点を自分で整理した上で研究開発部門に相談することです。「これって技術的にできますか？」と丸投げすると、相手は何を判断すればいいかわかりません。「こういう技術を使って、こういうことをやりたい。技術的な障壁として考えられるのはこのあたりだと思うが、見落としている観点はあるか」と聞けば、具体的な回答が返ってきます。

市場は成立するか

顧客になりうる企業（または個人）はどれぐらい存在するか。その顧客はお金を払う能力があるか。想定する価格帯で損益分岐に達する顧客数は現実的か。

この段階では「桁として合うか」を見ます。顧客が全国で100社しかいなくて、損益分岐が20社だとしたら、市場シェア20%が必要です。それは現実的でしょうか。こうした概算で「明らかに無理」かどうかを判断します。

確認すべき観点は市場規模だけではありません。顧客に提供する価格と顧客が実際に払える価格がマッチしうるか。営業やデリバリーにどれだけコストがかかるか。単価が低い商材なのに訪問営業が必要な構造になっていないか。こうした「売り方」の現実性も、この段階で概算しておくべきです。

例えば、ある技術を使った社内業務の改善サービスを検討したことがあります。この段階で概算してみると、同じ領域には既に安価な既存サービスが複数あり、自社が提供する場合の価格帯と既存サービスの価格差を正当化できる差別化要素が見当たりませんでした。技術的にも数年前なら新しかったかもしれませんが、今さら優位性がない。外販しようにもターゲットとなる顧客像が描けず、自社サービスに組み込もうにも既存の安価なサービスに勝てる見込みがない。この時点で「桁として合わない」と判断できる状態でした。

なお、実際に審査に持っていく段階ではTAM（Total Addressable Market = 獲得可能な最大市場規模）、SAM（Serviceable Addressable Market = 実際にアプローチ可能な市場）、SOM（Serviceable Obtainable Market = 現実的に獲得できる市場）を算出することが求められるケースが多いです。ただし、この段階はあくまで「ざっくりチェック」です。TAMを精緻に算出する必要はなく、「明らかに筋が悪い」を弾ければ十分です。

法的・規制面のリスクはないか

許認可が必要か。業界固有の規制があるか。個人情報保護やデータ取り扱いの制約はあるか。

法的にアウトなものは、どれだけペインがあっても事業にはなりません。ここも「明らかにNG」を弾くためのチェックです。

技術と同じで、企画職として関連する法規や論点を自分で整理した上で法務部門に相談することが重要です。「法的に問題ないですか？」と丸投げすると、法務部の責任範囲ではないので優先度を上げてもらえません。「まぁ問題ないでしょう」で通過してしまうか、後回しにされるか、「もっと詳しく聞かせて」とまとまらなくなります。

ここが怖いのは、曖昧なまま企画を進めてしまうケースです。「法務に相談済み」のつもりで話を精緻化し、最終審査に持っていったところで「法律的にアウトです」と止められることがあります。最終審査の段階になると法務部も正式な判断を求められるため、概要レベルの雑談とは本気度が違います。ゲートの段階で、論点を明確にして正式に確認を取っておくことが、後の手戻りを防ぎます。

ゲートで止める勇気

ここが一番難しいところです。

先ほど市場チェックの例で触れた社内業務改善サービスの話には、続きがあります。概算の段階で筋が悪いことは見えていました。しかし、社内で期待の高い技術テーマだったこともあり、まず実証実験を進めることになりました。企画に異動したばかりのメンバー1名と研究開発2名のチームで、上司と私が適宜サポートする体制です。

実際にデータを取り始めると、技術的な制約にすぐ直面しました。複数の変数で相関分析を行いましたが、結果は予想通りいまいちでした。

実証実験の結果を報告すると、次に求められるのは「このノウハウをどう事業化するか」です。でも、市場チェックの段階で見えていた問題──既存サービスとの差別化不在、顧客像の不在──は何も変わっていません。プロトタイプが動いたことで「技術的にはできた」という実績だけが残り、「では誰にいくらで売るのか」は白紙のままでした。

でも止められなかった。社内で期待されている技術テーマだったこと、「新メンバーの教育にはなるだろう」という名目が付いてしまったこと。事業性よりも社内事情が優先され、実証ありきで進んだわけです。

そしてここからが本当に大変でした。「やめるべきだ」と判断するための材料を揃え、関係者を納得させるプロセスに、プロトタイプを作る以上の労力がかかりました。事業性のざっくりチェックを最初にやっていれば、この遠回りは避けられたはずです。

また、従業員体験を向上させるサービスのように、「あったら嬉しい」けれど企業が予算を割いてまで導入するかは別問題、という領域もあります。「ペインがある」と「お金を払う」の間には、想像以上の距離があります。

事業性ゲートは、プロトタイプを作る前に通すべきです。作ってしまうと、止める判断（撤退判断）のほうが作る判断より重くなります。

なお、「止められない」問題は事業性の見落としだけが原因ではありません。チーム内でパーパス（目的意識）が揃っていない場合にも、同じ構造が生まれます。事業性とは別の角度──組織の情熱のズレという観点からこの問題を掘り下げた記事はこちらです。

なぜ大企業の新規事業は失敗するのか──組織パーパスと個人の情熱がズレる構造問題
https://note.com/aobane_tsumugu/n/nc513cebef8de

ソリューション検証（PSF）の進め方──「面白いですね」で終わらせない

事業性のゲートを通過したら、いよいよソリューション検証に入ります。**PSF（Problem Solution Fit）**──「このソリューションで、顧客のペインは解決されるか」を確かめる段階です。CPFが「課題は本物か？」を検証するプロセスだったのに対し、PSFは「この解決策でその課題は解決できるか？」を検証するプロセスです。

「作り込まない」が鉄則

PSFの目的は、製品を完成させることではありません。仮説を検証することです。

Eric Riesのリーンスタートアップ（『The Lean Startup』2011年）が提唱したMVP（Minimum Viable Product = 実用最小限の製品）の考え方と同じです。**構築→計測→学習（Build-Measure-Learn）**のサイクルを最速で回すために、プロトタイプ、モックアップ、ペーパープロトタイプなど、形は何でも構いません。顧客が「これで自分のペインが解決されるかどうか」を判断できる最低限のものを用意します。作り込むほど、前のセクションで触れた「止められない」問題が起きます。

MVPと聞くと「ちゃんと動くプロトタイプ」を想像するかもしれませんが、もっと粗くて構いません。ユーザーにはシステムとして動く画面を使ってもらいつつ、裏側では人が手作業でデータを処理し、結果を手動で貼り付けて返す──そんな形もあります。検証したいのはソリューションの価値であって、システムの完成度ではありません。

さらに、Claude CodeなどのAIツールの登場で、MVPの作成はかなりやりやすくなりました。ちょっとした動く画面であれば、2〜3日で最低限動くMVPを作ることができます。かつてはプロトタイプ1つにもエンジニアのリソース確保が必要でしたが、企画職でも自力で最低限のMVPを用意できる時代になりました。「作り込まない」の原則が、技術的にもこれまで以上に実践しやすくなっています。

CPFのインタビューとの違い

CPFでは「意見を聞くな、行動を聞け」が原則でした。PSFでは少し変わります。ソリューションを見せた上で、行動の変化を見ます。

• 「これがあったら使いますか？」は依然として弱い質問です。de Corte et al.（2021年, Health Economics誌）の研究では、人が「やります」と述べた意図と実際の行動の間に30-40%の乖離が確認されています

• 「これがあったら、今やっている〇〇（対処行動）をやめますか？」は強い質問です

• Rob Fitzpatrickが『The Mom Test』で提唱するコミットメント（時間・評判・お金を差し出す意思）を求めるのも有効です。「テストユーザーになっていただけますか？」と聞いて、行動で応えてくれるかどうかを見ます

ポイントは、CPFで確認した対処行動を基準にすることです。「今の手作業をやめてこのツールに切り替えるか」。これなら行動ベースの検証になります。

PSF達成の判断基準

PSFが達成できたと判断するには、以下の条件が揃っているかを確認します。

• 顧客がプロトタイプを見て、自分のペインとの接続を言語化できる

• 既存の対処行動から切り替える意思がある（コミットメント）

• 「こういう場面で使いたい」と具体的な利用シーンが出てくる

• 複数の顧客から同様の反応が得られる

逆に、「面白いですね」「便利そうですね」だけで終わる場合は、PSFに達していません。CPFで学んだ教訓を思い出してください。Rob Fitzpatrickが分類する「お世辞」や「曖昧な仮定」は、PSFの段階でも紛れ込みます。

まとめ

この記事のポイント:

• ペインの仮説、ソリューションの仮説、事業性の仮説は三位一体の「仮説セット」である。CPFで検証したのはペイン側だけ

• CPFの結果は3つのケースに分岐する。想定通りなら次へ、想定と違うペインが出たらピボット（仮説立て直し）、ペインがなければソリューション起点で別の課題を探す

• ソリューション検証の前に、事業性のゲートを通す。技術的実現性、市場規模、法的リスクの3つを概算で確認する

• 技術や法務への相談は、論点を整理してから持っていく。丸投げすると曖昧な回答しか返ってこない

• 事業性ゲートを後回しにすると、作った後に止められなくなる。撤退の材料づくりに作る以上の労力がかかる

• PSFでは「作り込まない」が鉄則。CPFで確認した対処行動を基準に「切り替えるか」を検証する

• 「面白いですね」はPSF達成の証拠にならない。行動の変化とコミットメントを見る

「新規事業の初期検証」シリーズ:

このシリーズでは、新規事業の初期検証のフレームワークを3つの記事で整理してきました。

1. 問題の構造: なぜ「あったらいいね」を集めてしまうのか → 新規事業が失敗する本当の理由──ニーズとペインの混同が生む4つの罠

2. CPFの実践: ペインを見抜くインタビューの設計 → 顧客インタビューのやり方──新規事業で「嘘」を見抜きペインを見つける3つの質問

3. CPF後のアクション: 結果の分岐から事業判断まで → この記事

ペインの検証からソリューション検証、事業性の判断まで。ここを通過した後に待っている「顧客がいるのに儲からない」という損益分岐の壁については、こちらの記事で整理しています。

参考文献

この記事を書くにあたって参考にした書籍・記事です。

書籍:

• Rob Fitzpatrick『The Mom Test』（2013年）。コミットメントの概念、悪いデータの分類

• Steve Blank『The Four Steps to the Epiphany』（2003年）。顧客開発モデル、ピボットの考え方

• Eric Ries『The Lean Startup』（2011年）。MVP（Minimum Viable Product）、Build-Measure-Learnサイクル

記事・スライド:

• 鶴岡友也（BLUEPRINT Holdings CTO）「ユーザーヒアリング5つのポイント」（note, 2022年）。課題の重要度レベル

• 馬田隆明（東京大学FoundXディレクター）「ビジネスの仮説検証と実験の考え方」。仮説の誤りを検証するアプローチ

• 東大IPC（東京大学協創プラットフォーム開発）「ピボットとは？ 成功事例や注意点を解説」。Slack・Instagram等の事例、ピボットピラミッド

論文:

• de Corte, W., et al.（Health Economics, 2021年）。述べた意図と実際の行動の間に30-40%の乖離を実証

ヘッダー画像の原画

オルガンリハーサル

ヘンリー・ルロール
フランス, 1885

AI全盛の時代、あえて古典絵画を推していきます。
古典絵画×AIでバナー画像作成しています。
この絵を選んだ理由は、
「リハーサル」というモチーフが記事のテーマと重なるからです。
演奏家が個人で練習を積んだ後、実際のホールに立ってリハーサルをする──そこではホールの空気感を確かめ、音楽監督や指揮者と音楽をすり合わせます。
新規事業にも同じ段階があります。
課題を見つけた高揚感のまま「作ろう」に飛びたくなるけれど、その前にホールの空気を確かめ、音楽監督と音楽とすり合わせるように、市場との適合性を確かめ、技術や法務などとすり合わせる時間が要る。
地味だけれど、ここを省くと本番は成り立ちません

原典：メトロポリタン美術館
https://www.metmuseum.org/art/collection/search/436880