新規事業のロードマップの作り方：仮説検証と開発計画をつなぐ

新規事業のロードマップは、「いつ何を作るか」を並べた開発計画ではなく、「何が確かめられたら、次に何に投資するか」を時間軸に描いた計画です。検証の段階を横軸の区切りに置き、各段階で確かめる仮説、そのために必要な開発・営業・体制の動き、次の段階へ進む条件を一枚にまとめる。これが、仮説検証と開発計画をつなぐロードマップの基本形です。

新規事業の計画が既存事業と同じ形式の年間計画になってしまうと、検証の結果に関係なく開発が進み、予定した機能をすべて作り終えた後に「誰も使わない」と分かる、という事態が起こります。逆に、検証のことしか書かれていない計画では、開発チームや営業チームが準備のしようがありません。ロードマップの役割は、この両者を同じ紙の上でつなぎ、関係者が「今どの段階にいて、次に何が起きるか」を共有できるようにすることです。

この記事は、新規事業の責任者や事業開発担当者、プロダクトマネージャーに向けて、検証と開発をつなぐロードマップの構成要素、作り方の手順、関係者ごとの見せ方、更新の仕方、よくある失敗とチェックリストを解説します。

新規事業のロードマップが既存事業の計画と違う理由

既存事業の計画は、売上や生産量などの目標を置き、それを達成するための施策を時期ごとに配置する形で作られます。前提となる顧客や市場がある程度分かっているため、計画通りに進めることが重視されます。

新規事業では、前提そのものが分かっていません。顧客は本当に困っているのか、提案する解決策で課題が解けるのか、お金を払ってもらえるのか、継続して使われるのか。これらが検証されるまでは、どの機能を作るべきか、どれだけの営業体制が必要かも決められません。

この違いを関係者が理解していないと、ロードマップの更新が「計画の失敗」として扱われ、検証の結果を反映した方向転換がしにくくなります。ロードマップを作る最初の段階で、「これは検証の結果に応じて更新する前提の計画である」ことを関係者と合意しておくことが重要です。

ロードマップを構成する要素

検証と開発をつなぐロードマップには、少なくとも次の要素を含めます。

横軸：検証の段階と時期の目安

横軸には、検証の段階を置きます。例えば次のような区切りです。

• 課題確認：想定顧客が、想定した課題を本当に持っているか
• 解決策の検証：提案する解決策で、その課題が解けるか
• MVPでの検証：最小限の製品を実際に使ってもらい、価値が届くか
• 有料での検証：お金を払ってでも使い続けたいか
• 拡大準備：獲得と提供を繰り返せる仕組みが作れるか

段階ごとに、時期の目安を添えます。ただし、時期は「この時期までにこの段階を終える」という約束ではなく、「この時期を目安に判断する」という区切りとして扱います。

縦軸：レーン（活動の種類）

縦軸には、活動の種類ごとのレーンを置きます。

• 検証レーン：その段階で確かめる仮説と、検証の方法、次へ進む条件
• プロダクトレーン：その段階の検証に必要な開発（画面イメージ、試作品、MVP、機能追加）
• 営業・マーケティングレーン：顧客との接点づくり、試験導入の提案、販売の準備
• 運用・体制レーン：問い合わせ対応、契約や請求の仕組み、人員の配置
• 判断レーン：段階の区切りで誰が何を決めるか、必要な予算

段階の区切りに置く「判断の条件」

ロードマップでもっとも重要なのは、段階と段階の間に置く判断の条件です。「MVPでの検証」から「有料での検証」に進む条件として、「試験利用した顧客のうち一定数が、毎週の業務で継続して使っている」のように、何が確認できたら次に進むかを書きます。条件を満たさなかった場合の選択肢（同じ段階をやり直す、対象顧客を変える、止める）も合わせて書いておきます。

一枚にまとめたときの形

構成要素を一枚にまとめると、例えば次のような表になります。実際には段階ごとに列を設け、レーンごとに行を設けて書き込みます。

この形にすると、例えば「MVPでの検証」の列を縦に読めば、その段階で開発・営業・運用がそれぞれ何をしていればよいかが一目で分かります。横に読めば、開発チームにとっての作業の順番や、営業チームが顧客に提案を始められる時期が見えてきます。判断の行は、経営層との打ち合わせの議題としてそのまま使えます。

ロードマップの作り方の手順

ここからは、ロードマップを実際に作る手順を示します。最初から細かく作り込む必要はなく、直近の段階を詳しく、先の段階は粗く書くのが基本です。

1. 事業の最終的な姿を短く書く：誰の、どんな課題を、どう解決し、どう収益を得る事業にしたいのかを数行で書きます。これがロードマップの到達点になります。
2. 不確かな前提を洗い出す：事業が成り立つために正しくなければならない前提を書き出し、「どれだけ不確かか」「間違っていたときの影響はどれだけ大きいか」で並べます。
3. 前提を検証の段階に割り当てる：不確かで影響の大きい前提から順に、早い段階で検証するように配置します。
4. 段階ごとの判断の条件を書く：各段階の終わりに、次へ進むための条件を書きます。
5. 各段階に必要な開発を最小限で書く：その段階の検証に必要な最小限の開発だけを書きます。検証に必要のない機能は、後の段階に回します。
6. 営業・運用・体制の動きを書く：開発と並行して必要な、顧客との接点づくりや、契約・請求・問い合わせ対応の準備を書きます。
7. 予算と人の配分を段階ごとに書く：段階ごとにかかる費用と人の目安を書き、どの段階の区切りで次の予算を判断するかを明示します。
8. 関係者と読み合わせる：開発・営業・経営層と一緒にロードマップを読み、抜けや無理がないかを確認します。

開発の部分をより詳しいスケジュールに落とす方法は、MVP開発のスケジュールの立て方で解説しています。ロードマップは段階と判断を、スケジュールは各段階の中の作業を表す、という役割分担で使い分けます。

直近は詳しく、先は粗く

ロードマップのすべての段階を同じ粒度で書こうとすると、先の段階ほど根拠のない計画になり、更新の手間も増えます。直近の段階は週単位で何をするかまで書き、その次の段階は月単位の主な動き、それより先は「何を検証する段階か」と判断の条件だけ、という書き分けが現実的です。

関係者ごとのロードマップの見せ方

同じロードマップでも、見る人によって知りたいことが異なります。元となるロードマップは一つにしつつ、関係者ごとに見せる部分や粒度を変えます。

特に開発チームに対しては、「作らないこと」を明記することが重要です。ロードマップに書かれていない機能について、関係者から個別に依頼が来ることはよくあります。後の段階に回した機能をロードマップ上に「検討中」として置いておくと、依頼が来たときに「どの段階の判断を経て着手するか」を説明できます。

経営層への報告の形については、経営層への新規事業の進捗報告で、検証の進み具合と次の判断事項を中心にした報告の型を紹介しています。ロードマップはその報告の土台になります。

ロードマップの更新と運用

ロードマップは、一度作ったら終わりではありません。検証の結果が出るたびに、仮説、判断の条件、開発の内容を見直します。

更新のタイミング

• 段階の区切りでの判断の後：次の段階に進む、同じ段階をやり直す、方向を変える、止める、のいずれを決めたかを反映します。
• 重要な事実が分かったとき：顧客の課題が想定と違っていた、想定した価格では合わないと分かった、といった場合は、段階の途中でも更新します。
• 定期的な見直し：月に一度程度、ロードマップ全体を関係者と確認し、時期の目安や体制の計画を見直します。

更新の記録を残す

ロードマップを更新するときは、何を、なぜ変えたのかを記録に残します。記録がないと、後から振り返ったときに方向転換の理由が分からず、同じ議論を繰り返すことになります。変更の記録は、ロードマップの末尾に日付と変更内容、理由を箇条書きで追記していく形でも十分です。

開発が検証を追い越さないようにする

運用の中でよく起きるのが、開発の速度が検証の速度を追い越すことです。開発チームの手が空くと、検証の結果を待たずに次の機能に取りかかってしまい、結果として使われない機能が積み上がります。開発の手が空いた場合は、計測の仕組みの整備、既存部分の品質改善、運用作業の自動化など、どの検証結果になっても無駄にならない作業を優先するように、ロードマップに「待ちの間の作業」を書いておくとよいでしょう。MVPから本格的な開発へ移るときの判断の考え方は、MVPから本開発へ移るときで詳しく扱っています。

具体的な場面の例：BtoB向け業務サービスのロードマップ

架空の例として、中小規模の介護事業所向けに、シフト作成を支援するサービスを立ち上げようとしているチームを考えます。

チームは事業の到達点を「介護事業所の管理者が、毎月のシフト作成にかける時間を大きく減らし、職員の希望を反映しやすくするサービスを、月額課金で提供する」と書きました。不確かな前提を洗い出したところ、「管理者はシフト作成に多くの時間を使っていると感じている」「職員の希望を集める手段が電話や紙に頼っている」「管理者は月額の費用を払ってでも改善したいと考えている」「シフトの自動作成の結果を、管理者が信頼して使う」の4つが挙がりました。

ロードマップでは、最初の段階で前の2つを、管理者へのインタビューと既存の勤務表の観察で確かめることにしました。次の段階では、職員の希望を集める部分だけを試作品にして、数か所の事業所で試してもらいます。シフトの自動作成は技術的に難しく開発の負担も大きいため、この段階では作らず、チームのメンバーが手作業で作成案を作って管理者に渡す形で、「作成案を信頼して使うか」を確かめることにしました。

判断の条件として、試作品の段階からMVPの段階に進むには「試した事業所の管理者の多くが、翌月も継続して使いたいと申し出ること」を置きました。また、有料での検証に進む条件として「手作業で作った作成案を、管理者が大きく手直しせずに使うこと」を置き、これが満たされない場合は自動作成の機能を作る前に、作成のルールの理解を深める段階をやり直すことにしています。

このロードマップを経営層に見せたところ、「自動作成の機能がいつできるのか」という質問が出ました。チームは「手作業での作成案が使われると確認できた段階で着手する。その判断の時期の目安はこの月」と、判断の条件と時期の目安で答えています。機能の完成時期を約束するのではなく、判断の時期を約束する、というのがロードマップの使い方です。

その後、手作業での作成案を試した事業所のうち、管理者が手直しせずに使った例は想定より少なく、職員同士の相性や、急な欠勤への備え方など、事業所ごとの暗黙のルールが多いことが分かりました。チームはロードマップを更新し、自動作成に進む前に「作成のルールを管理者に入力してもらう仕組み」を検証する段階を加え、その変更の理由を記録に残しています。

よくある失敗と避け方、作成時のチェックリスト

よくある失敗

• 機能の一覧と納期を並べただけになる：検証の段階と判断の条件がないと、ロードマップは単なる開発計画になります。横軸を段階にし、判断の条件を必ず書きます。
• すべての段階を細かく書き込む：先の段階まで細かく書くと、根拠のない約束が増え、更新もされなくなります。直近を詳しく、先は粗く書きます。
• 時期の目安が約束として扱われる：時期の目安を過ぎたことが「遅れ」として扱われると、判断の条件を緩めて次に進む誘因が生まれます。時期は判断の目安であることを関係者と合意します。
• 営業や運用のレーンがない：開発だけを計画すると、MVPができても顧客に提案する準備や、問い合わせに対応する体制がなく、検証が始められません。
• 更新の理由が残らない：方向転換の理由が記録されていないと、関係者の理解が追いつかず、不信感を生みます。

作成時のチェックリスト

• 事業の到達点が数行で書かれている
• 不確かな前提が洗い出され、検証の順番が決まっている
• 横軸が検証の段階で区切られている
• 段階ごとに判断の条件と、満たさなかった場合の選択肢が書かれている
• 各段階の開発が、その段階の検証に必要な最小限になっている
• 営業・運用・体制のレーンがある
• 段階ごとの予算と人の配分、次の予算を判断する時期が書かれている
• 後回しにした機能が「検討中」として明記されている
• 関係者ごとの見せ方を用意している
• 更新の記録を残す場所がある

よくある質問

Q. ロードマップはどのツールで作ればよいですか？

特定のツールである必要はありません。表計算ソフト、スライド、ホワイトボードツール、プロジェクト管理ツールのどれでも作れます。大切なのは、関係者が同じものを見られることと、更新しやすいことです。最初は表計算ソフトやスライドで一枚にまとめ、開発の詳細はプロジェクト管理ツールで管理する、という分け方がよく使われます。

Q. ロードマップと事業計画書の違いは何ですか？

事業計画書は、事業の全体像、市場、収益の見通し、必要な投資などをまとめ、事業に取り組むかどうかを判断するための資料です。ロードマップは、その事業を検証しながら進めるための実行計画です。事業計画書の前提のうち、どれをいつ検証するかを示したものがロードマップ、と考えると関係が分かりやすくなります。投資判断の考え方はシステム開発を伴う新規事業の投資判断も参考にしてください。

Q. 検証の段階は何段階に分けるのがよいですか？

決まった数はありません。事業の性質によって、課題確認と解決策の検証を一つにまとめたり、有料での検証を価格の検証と継続利用の検証に分けたりします。段階が多すぎると判断の回数が増えて負担になり、少なすぎると一回の段階が長くなって方向転換が遅れます。各段階の長さが数週間から数か月に収まるように区切るのが目安です。

Q. 経営層から確定した完成時期を求められたらどうすればよいですか？

完成時期の代わりに、判断の時期と、その時点で確かめられていることを約束する形を提案します。「この時期に、この条件を満たしているかを判断する。満たしていれば次の段階でこの機能に着手し、その完成の目安はこの時期」と、条件付きの見通しを示すと、経営層も判断の材料を得られます。

Otsumuに相談できること

ロードマップは、事業の到達点と不確かな前提を整理でき、開発と営業の両方の動きを見通せる責任者がいれば、自社で十分に作れます。この記事の構成要素と手順に沿って、まずは直近の段階だけでも書き出し、関係者と読み合わせてみてください。

一方で、何を検証すべきかの優先順位がつけられない、開発会社から提示された計画が機能の一覧になっていて検証との関係が見えない、MVPを作る段階に来ているが開発の体制がない、という状況では、仮説の整理と開発の計画を同時に扱える外部の支援が役に立ちます。

Otsumuは新規事業開発コンサルティングで、事業の前提の整理から、検証の段階と判断の条件の設計、ロードマップの作成と更新までを伴走します。MVPの段階では、構想から開発・運用・改善までを一気通貫で担い、AIを活用した少人数・短期間の開発で新規事業の爆速MVPシステム開発を進めることができます。検証用のMVPを短期間で形にしたい場合は、PoC / MVP Sprint（300万円〜・税別、6週間を目安に設計）という区切りでの進め方もあります。

今のロードマップの見直しからでも構いません。30分の無料相談で、事業の段階と悩んでいる点をお聞かせください。

この記事について

Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。

執筆：Otsumu株式会社 ／ 編集日 2026.10.01