# 新規事業の仮説検証｜Webサービス開発前の進め方 - 公開日: 2026-10-03 - 監修: 代表取締役 兼 StockSun創業メンバー 板橋 晟星 - URL: https://www.geek-bridge.com/public/column/new-business-hypothesis-validation 新規事業のWebサービスは、開発前に「誰のどの課題を解くか」「使うか」「払うか」「運用できるか」を小さく検証するのが基本です。インタビュー、LP、画面試作、手作業の有償実験を順に行い、数値基準を満たしてから開発へ進むと、無駄な機能投資を抑えられます。 ## 新規事業の仮説検証とは 新規事業における仮説検証とは、事業計画に含まれる不確実な前提を分解し、顧客の発言や行動、数値によって確かめる活動です。開発そのものを完成させることではなく、「次の投資をしてよいか」を判断できる証拠を集めることが目的です。 Webサービスの構想段階では、次のような前提がまだ確定していません。 - 想定している顧客が本当にその課題を抱えているか - 課題は、顧客が時間や費用を使ってでも解決したいほど強いか - 提案するWebサービスで課題を解決できるか - 顧客が継続して利用し、料金を支払うか - 自社の営業、サポート、法務、運用体制で提供できるか - 外部サービスとの連携やデータ処理を技術的に実現できるか これらが曖昧なまま機能一覧を作ると、開発会社は依頼された機能を見積もれても、事業が成立するかまでは保証できません。仕様どおりに納品されても利用者が増えない、営業に必要な機能が不足する、運用負荷が高く利益が残らない、といった問題が起こります。 発注のご相談を受ける開発会社の立場から見ると、「まず全機能の見積もりが欲しい」という依頼は少なくありません。しかし、検証前の段階では機能の増減が大きいため、詳細な見積もりを作っても前提がすぐ変わります。最初に決めるべきなのは完成形ではなく、最も不確実で、外れた場合に事業計画が成立しなくなる仮説です。 ### PoC・プロトタイプ・MVPとの違い 仮説検証には複数の手段があり、確かめたい内容によって使い分けます。 | 手段 | 主に確かめること | 成果物の例 | 注意点 | |---|---|---|---| | 顧客インタビュー | 課題の有無、既存の解決方法 | 記録、課題一覧、顧客像 | 「欲しいですか」と聞くだけでは需要を判断できない | | LPテスト | 訴求への反応、問い合わせ需要 | LP、申込フォーム、計測結果 | 広告条件や流入元も記録する | | プロトタイプ | 操作の理解、利用場面 | 画面試作、テスト記録 | 実際に動くシステムとは限らない | | 手作業のパイロット | 提供価値、支払意思、運用負荷 | 有償実験、業務記録 | 裏側を人が処理してもよい | | PoC | 技術や業務上の実現可能性 | 検証用プログラム、評価結果 | 市場需要の検証とは分けて考える | | MVP | 実利用に必要な最小限の製品 | 限定公開版のサービス | 検証目的に不要な機能を増やさない | PoC（Proof of Concept＝技術や業務上の実現可能性を確かめる試験）に成功しても、顧客が料金を支払うとは限りません。一方、MVP（Minimum Viable Product＝価値検証に必要な最小限の製品）を作らなくても、手作業によるサービス提供で支払意思を確かめられる場合があります。 「何かを作ること」を先に決めず、検証したい仮説に対して最も安く、短く、信頼できる方法を選ぶことが重要です。 ## 開発前に検証する4つの仮説 開発前には、顧客課題、解決策、事業性、実現可能性の4領域を確認します。すべてを同時に調べるのではなく、外れたときの影響が大きい仮説から順番に検証します。 ### 1. 顧客課題の仮説 最初に、「誰が」「どの場面で」「どの程度困っているか」を確認します。顧客が課題を自分の言葉で説明でき、すでに何らかの回避策を取っているなら、課題が存在する可能性は高まります。 インタビューでは、将来の希望より過去の事実を聞きます。 - 最後にその問題が起きたのはいつか - 現在はどのような手順で対処しているか - 何人が関わり、どの程度の時間や費用が発生しているか - 既存の製品や外注を使わない理由は何か - 解決しなかった場合、どのような損失や不便があるか - 導入を判断する人、利用する人、予算を持つ人は誰か 「このサービスがあれば使いますか」という質問は、回答者が好意的に答えやすいため、根拠としては弱くなります。説明する前に現状を聞き、課題が回答者から自然に出てくるかを確認します。 ### 2. 解決策と利用行動の仮説 課題が存在しても、提案する方法が受け入れられるとは限りません。画面だけのプロトタイプや、担当者が裏側を手作業で処理する試験サービスを使い、顧客が目的を達成できるかを確かめます。 確認する項目は次のとおりです。 - サービスの説明を受けなくても用途を理解できるか - 初回利用までに必要な入力や準備が多すぎないか - 顧客が想定した順序で操作するか - 利用後に、従来より時間や負担が減ったか - 一度試すだけでなく、再び利用する理由があるか - 導入時にデータ登録、社内説明、教育が必要か 画面の好みだけを聞くのではなく、具体的なタスクを依頼して行動を観察します。操作に迷った箇所、説明が必要だった箇所、途中で離脱した理由が、開発範囲を決める材料になります。 ### 3. 事業性と支払意思の仮説 登録者数や「興味があります」という回答だけでは、事業性を判断できません。料金提示後の反応、商談化、試験導入、継続利用など、負担を伴う行動を確認します。 BtoBサービスであれば、次のような証拠を段階的に集めます。 1. 担当者が次回の商談に応じる 2. 上司や決裁者を紹介する 3. セキュリティや契約条件の確認へ進む 4. 導入時期と予算枠を提示する 5. 有償パイロットを契約する 導入意向書は前向きな証拠にはなりますが、契約や支払いと同じではありません。BtoCサービスでも、無料登録、利用開始、一定期間後の再利用、有料転換を分けて計測します。 KPI（Key Performance Indicator＝判断に使う重要な数値指標）は、一般的な平均値だけで決めず、自社の収支から逆算します。例えば、許容できる顧客獲得費は「1顧客から見込む粗利益×集客へ配分できる割合」で考えられます。広告費を増やせば登録が増えても、獲得費が粗利益を上回るなら、その条件では事業を拡大できません。 ### 4. 技術・運用上の実現可能性 顧客ニーズが確認できたら、提供を阻む技術・運用上のリスクを検証します。高度な技術を使う部分だけでなく、外部サービスの制約や社内業務も対象です。 - 必要なデータを合法かつ継続的に取得できるか - 外部APIの仕様、利用料金、回数制限に問題がないか - 想定する処理速度や精度を達成できるか - 個人情報や機密情報を適切に管理できるか - 障害時に手作業で代替できるか - 問い合わせや審査を何人で処理するか - 売上が増えたときに運用コストが過度に増えないか 技術的に可能でも、人による確認が大量に必要なら利益が残らない場合があります。開発費だけでなく、営業、審査、カスタマーサポート、返金処理などを含む提供原価を試算します。 ## 仮説検証の進め方5ステップ 仮説検証は、判断基準を先に決め、顧客の事実、行動、支払いの順に証拠を強くしていきます。結果を見てから成功条件を変えないことが重要です。 ### ステップ1. 事業仮説と投資判断を1枚に整理する 最初に、長い事業計画書ではなく、判断に必要な前提を1枚にまとめます。少なくとも以下を記載します。 - 対象顧客と利用者 - 顧客が置かれる具体的な場面 - 現在の解決方法と不満 - 提供する価値 - 課金する相手と料金案 - 顧客へ到達する営業・集客経路 - 最も不確実な前提 - 今回の検証範囲 - 継続、修正、中止を判断する基準 - 検証期間と上限予算 複数の顧客層を同時に扱うと、誰の反応だったのか分からなくなります。最初は業種、企業規模、役職、利用場面などで対象を狭めます。 ### ステップ2. 顧客インタビューで課題を確かめる 対象顧客を募集し、1人ずつ話を聞きます。最初は顧客層ごとに5〜10人程度を目安にし、同じ課題や既存の回避策が繰り返し出るかを確認します。ただし、人数を達成すること自体が目的ではありません。 社内の既存顧客へ聞く場合は、自社との関係が良いために肯定的な回答へ偏る可能性があります。見込み顧客、失注顧客、既存手段を使っている人など、異なる立場も含めます。 結果は、都合のよい発言だけを抜き出さず、以下の形式で記録します。 - 発言と観察した事実 - 現在の代替手段 - 課題が発生する頻度 - 時間、費用、売上への影響 - 意思決定者と導入障壁 - 当初の仮説と異なった点 ### ステップ3. LPや営業活動で需要を測る 課題が確認できたら、LP（ランディングページ＝サービスの説明と申込導線をまとめたページ）や提案資料を用意し、問い合わせ、資料請求、商談予約などの行動を測ります。 広告を使う場合は、広告文、流入元、対象者、表示回数、クリック数、申込数、費用を同じ期間で記録します。CVR（Conversion Rate＝訪問者のうち申込に至った割合）だけでなく、申込後に対象顧客だった割合や商談化率も確認します。 反応が弱いときは、直ちにサービス全体を否定するのではなく、次のどこに原因があるかを分けます。 - そもそも対象顧客へ届いていない - 課題の表現が顧客の認識と合っていない - 解決策や利用後の価値が伝わっていない - 料金や申込条件が受け入れられていない - 問い合わせ後の営業対応に問題がある ただし、結果が出るまで訴求や対象者を無制限に変えると、何を検証したか分からなくなります。変更内容と理由を残し、条件ごとに評価します。 ### ステップ4. プロトタイプと有償パイロットを行う 次に、主要な利用場面を確認できる画面試作を作ります。プロトタイプは見た目を完成させるためではなく、顧客が価値へ到達する一連の流れを確かめるものです。 実際のシステムがなくても、申込受付、データ処理、結果の返却を担当者が手作業で行える場合があります。この方式なら、開発に数カ月をかける前に、顧客が結果へ満足するか、どの作業が運用上の負担になるかを確認できます。 可能であれば、少額でも料金を設定します。無料の試験では、利用の優先順位が下がり、実際の導入条件も見えにくいためです。無料にする場合も、データ提供、担当者の参加、利用後の面談など、顧客側に一定の協力を求めます。 ### ステップ5. 結果を評価し、開発へ引き渡す 検証終了時は、継続、修正、保留、中止のいずれかを判断します。「面白い反応があった」という感想ではなく、事前に決めた基準と実績を並べます。 | 評価領域 | 判断材料の例 | 次の対応 | |---|---|---| | 顧客課題 | 課題の頻度、既存手段、損失 | 対象顧客や課題を絞る | | 需要 | 問い合わせ、商談、申込 | 訴求や集客経路を見直す | | 支払意思 | 有償試験、料金提示後の反応 | 価格・契約単位を調整する | | 利用価値 | タスク完了、再利用、所要時間 | 利用フローを修正する | | 実現可能性 | 技術結果、運用工数、原価 | 自動化範囲や方式を決める | 開発へ進む場合は、検証で分かった顧客像、利用場面、必要機能、対象外、判断指標を整理します。ここから要件定義（＝作るものを具体的に決める工程）へ移ります。事業上の目的を開発条件へ落とし込む方法は、[要求定義の進め方｜要件定義との違いと外注準備](https://www.geek-bridge.com/column/business-requirements-definition-guide)も参考にしてください。 ## 費用・期間と外注先の選び方 開発前の仮説検証は、1〜3カ月、50万〜300万円程度が一般的な目安です。ただし、社内でインタビューを実施する場合は数万円から始められ、外部システム連携や特殊な技術検証を含む場合は300万〜800万円以上になることもあります。 以下は、外注する場合の大まかな目安です。すべてを実施する必要はなく、最も重要な仮説に合う方法を選びます。 | 検証内容 | 費用の目安 | 期間の目安 | 費用が変わる要因 | |---|---:|---:|---| | 仮説整理・調査設計 | 20万〜80万円 | 1〜3週間 | 会議回数、調査範囲、成果物 | | 顧客インタビュー | 20万〜100万円 | 2〜6週間 | 対象者の募集難度、人数、謝礼 | | LP・申込計測 | 30万〜150万円 | 2〜6週間 | デザイン、広告運用、計測環境 | | 画面プロトタイプ | 30万〜150万円 | 2〜6週間 | 画面数、操作範囲、テスト回数 | | 手作業のパイロット | 50万〜300万円 | 1〜3カ月 | 参加社数、運用支援、データ処理 | | 技術PoC | 100万〜500万円以上 | 1〜3カ月以上 | 外部連携、データ、精度・性能条件 | 広告費、対象者への謝礼、外部ツール利用料、データ購入費などが別途必要になる場合があります。また、BtoBサービスは顧客企業の決裁や契約に時間がかかるため、検証期間が3〜6カ月程度になることもあります。 実際のシステム開発へ進むと、検証費とは別に設計・開発・テスト・保守の予算が必要です。開発方式ごとの費用は、[Webサービス開発の費用相場｜外注の進め方](https://www.geek-bridge.com/column/web-service-development-cost-guide)で詳しく解説しています。 ### 外注前に準備するチェックリスト 外注先へ相談する前に、次の項目を整理すると提案と見積もりを比較しやすくなります。すべてが決まっていなくても、未確定であることを明示すれば問題ありません。 - [ ] 事業の目的と、今回判断したいこと - [ ] 想定顧客、利用者、決裁者 - [ ] 顧客が現在使っている代替手段 - [ ] すでに行った調査と、その結果 - [ ] 最も不確実だと考える仮説 - [ ] 検証期間と上限予算 - [ ] 継続・修正・中止の判断基準 - [ ] 顧客候補へ接触できるか - [ ] 利用できるデータや既存システム - [ ] 個人情報、契約、業界規制上の制約 - [ ] 検証後に想定する開発時期 - [ ] 成果物、データ、各種アカウントの帰属 発注者側で顧客候補を集められない場合は、対象者の募集も見積もりに含めます。専門職や企業の決裁者など、条件が限定されるほど募集費と期間が増えやすくなります。 ### 見積もりで確認する項目 仮説検証の見積もりは、制作物の価格だけでなく、何を判断できるようになるかを確認します。 | 見積もり項目 | 確認するポイント | |---|---| | 調査設計 | 検証する仮説、対象顧客、成功・中止基準 | | 対象者募集 | 人数、条件、募集方法、謝礼の扱い | | インタビュー | 質問設計、実施者、記録、分析方法 | | LP・広告 | 制作範囲、広告費、計測設定、アカウント名義 | | プロトタイプ | 画面数、操作できる範囲、編集データの納品 | | パイロット | 手作業の範囲、問い合わせ対応、参加者支援 | | 技術PoC | 検証環境、使用データ、達成基準、利用料 | | 報告 | 生データ、分析資料、意思決定会議の有無 | | 追加作業 | 条件変更時の単価、承認手順、上限金額 | 広告やアクセス解析のアカウントは、原則として発注者名義で管理します。委託終了後も過去のデータを確認でき、次の施策へ引き継げる状態にしておくためです。インタビュー記録やプロトタイプの編集データについても、納品形式と利用権を契約前に確認します。 ### 外注先を選ぶポイント 仮説検証の支援先は、きれいな資料や画面を作れることだけでなく、事業上のリスクを分解できるかで選びます。 - 顧客課題、市場需要、技術検証を区別して説明できる - 開発ありきではなく、手作業や既存ツールによる検証も提案する - 成功条件だけでなく、中止条件を合意できる - 顧客の発言と実際の行動を分けて評価する - 検証後の開発費・運用費まで考慮する - 調査データ、デザイン、アカウントを引き渡せる - 個人情報や機密情報の管理方法を説明できる - 不利な結果もそのまま報告する体制がある 反対に、顧客への確認前から大規模な開発を勧める、検証指標が「制作物の完成」だけになっている、前提条件を明記せず固定価格を提示する場合は注意が必要です。 GeekBridgeでは、Webサービスの構想整理から仮説検証、要件定義、開発まで、事業段階に合わせたご相談を受けています。検証方法や外注範囲を整理したい場合は、[開発のご相談はこちら](https://www.geek-bridge.com/#contact)からお問い合わせください。 ## まとめ - 新規事業の仮説検証は、開発の完成ではなく、次の投資判断に必要な証拠を集める活動です - 開発前に、顧客課題、解決策、事業性、技術・運用上の実現可能性を分けて確認します - インタビューでは将来の希望より、過去の行動、既存手段、時間・費用の負担を聞きます - 無料登録だけで需要を判断せず、商談、有償パイロット、再利用など負担を伴う行動を測ります - プロトタイプや手作業のサービス提供を使えば、本格開発前に価値と運用負荷を検証できます - 一般的な目安は1〜3カ月、50万〜300万円程度ですが、技術PoCや外部連携の有無で変動します - 成功・修正・中止の基準は検証前に決め、結果を見てから都合よく変更しないことが重要です - 外注先は制作力だけでなく、事業リスクの分解、検証設計、データの引き渡しまで見て選びます ## よくある質問 ### 開発前の仮説検証には、どのくらいの予算が必要ですか？ 一般的な目安は50万〜300万円程度ですが、社内で顧客インタビューを行えば、より小さく始められます。技術検証や外部システム連携が必要な場合は、300万〜800万円以上になることもあります。実際のシステム開発費は別に考えます。 ### 顧客インタビューは何人に行えば十分ですか？ 一律の正解はありませんが、最初は顧客層ごとに5〜10人程度へ聞き、同じ課題や反応が繰り返されるかを確認します。新しい発見が減ってきたら、LPや有償実験など行動を伴う検証へ進みます。 ### 無料登録が集まれば需要を検証できたといえますか？ 無料登録だけでは、実際に利用し続けるか、料金を支払うかまでは判断できません。有償パイロット、予約金、具体的な見積もりへの合意など、対象顧客に応じて支払意思に近い行動を確認することが重要です。 ### 新規事業の仮説検証は外注できますか？ 調査設計、インタビュー、LP制作、プロトタイプ制作、技術検証などは外注できます。ただし、顧客から得た情報を事業判断に変える役割まで委託先へ丸投げせず、事業責任者がインタビューや評価会議に参加することが大切です。