新規事業の開発ロードマップの描き方｜プロトタイプ後の1年

新規事業で開発ロードマップを描くとき、プロトタイプが動いた後の1年が空白になっているケースは少なくありません。この記事では、新規事業のシステム開発ロードマップを、事業の仮説と判断の節目から組み立てる方法を整理します。四半期ごとの区切り方、機能の並べ方、計画の見直し方まで、順に確認していきます。

新規事業の開発ロードマップが、通常の開発計画と違う点

ロードマップと聞くと、機能の一覧と日程を並べた表を思い浮かべる方が多いと思います。既存業務のシステムであれば、それで足りる場面もあります。やるべきことが決まっていて、あとは順番と期間を置いていけばよいからです。

新規事業ではこの前提が成り立ちません。市場が反応するかどうかが、まだ分かっていないからです。作る機能の一覧は、あくまで「いまの仮説」にすぎません。だから新規事業の開発ロードマップは、機能の予定表ではなく、仮説を確かめる順番と、その結果で次を決める節目の地図として描くほうが実態に合います。

通常の開発計画と比べると、違いは次の3点に整理できます。

• 計画の単位が「機能」ではなく「確かめたいこと」になる
• 各段階の終わりに「進む・直す・やめる」を決める節目がある
• 先の期間ほど、あえて粗く描く

3つ目は意外に思われるかもしれません。先の予定まで細かく決めると、確かめた結果が出たときに計画を直しにくくなります。近い期間は具体的に、遠い期間は方向だけ、という濃淡をつけておくほうが、現実の動きに合わせやすくなります。

プロトタイプの前と後で、ロードマップの役割が変わる

プロトタイプを作る前の計画は、「何を見せれば判断できるか」を決めるためのものです。一方、プロトタイプが動いた後の計画は、「実物を見たうえで、事業としてどう育てるか」を決めるためのものになります。

プロトタイプとMVPなど言葉の整理は、プロトタイプとモックアップ・MVPの違い｜新規事業の使い分けにまとめています。この記事では、動く実物ができたところを出発点にして、その後の1年を見通す方法に絞って進めます。

ロードマップを描く前に決めておく3つのこと

日程や機能を並べ始める前に、土台として決めておきたいことが3つあります。ここが曖昧なままだと、どれだけ丁寧に表を作っても、途中で判断がぶれやすくなります。

1. 事業の仮説を一文で言える状態にする

「誰の、どんな困りごとを、どの方法で解決し、どこから対価を得るのか」を一文で書けるかを確認します。長い企画書がある場合でも、この一文が書けないと、ロードマップの各段階で何を確かめるのかが決まりません。

仮説が複数ある場合は、事業の成否にいちばん影響するものから順に並べます。たとえば「利用者は本当に使い続けるか」と「画面の細かな使い勝手」では、前者のほうが先に確かめるべき仮説です。

2. 判断の指標と、判断する人を決める

各段階の終わりに「進むか、直すか、やめるか」を決めるには、何を見て決めるかの指標が要ります。指標は、プロトタイプやMVPを動かす前に決めておくほうが、結果を都合よく解釈する事態を避けられます。考え方はMVP検証の指標を先に決める方法｜判断基準の作り方で詳しく扱っています。

あわせて、その判断を誰が下すのかも決めます。経営陣が決めるのか、事業責任者に委ねるのか。発注側の判断役については、発注側のプロトタイプオーナーとはではなく、正確には発注側のプロダクトオーナーとは｜役割と判断のしかたが参考になります。

3. やめる条件も先に置いておく

ロードマップというと前進の計画ばかりに目が向きますが、止まる条件を先に置いておくことも、計画の一部です。「この指標がこの水準に届かなければ、次の投資はしない」と、あらかじめ合意しておきます。

撤退の基準を先に決めると、事業を諦めるための仕組みに見えるかもしれません。実際には、判断の根拠がはっきりしているため、続けると決めたときにも社内で説明しやすくなります。進め方の詳細は新規事業の撤退判断｜プロトタイプで「やめる」と決める基準にあります。

プロトタイプの後の1年を4つの段階に分ける

ここからが本題です。プロトタイプが動いた後の約1年を、4つの段階に分けて考えてみます。期間はあくまで目安で、事業の性質によって前後します。大切なのは期間そのものよりも、各段階で何を確かめ、何を決めるかです。

段階	目安の期間	確かめること	終わりの判断
1. 評価と合意	1〜2ヶ月	実物を見て、事業の形が描けるか	次に作る範囲を決めるか
2. 限定公開	2〜4ヶ月	少数の利用者が実際に使うか	公開範囲を広げるか
3. 拡大と改善	3〜5ヶ月	使い続けられ、広げる価値があるか	本格運用に進むか
4. 本格運用	残りの期間	運用の負荷と収益の見通し	次の投資をどうするか

第1段階：プロトタイプの評価と合意

最初の段階では、動くプロトタイプを関係者で触りながら、事業の形を確認します。企画書だけでは伝わりにくかった「何ができるのか」が、実物があると共有しやすくなります。経営陣と現場で見ている目的は同じでも、判断材料と速度が違うことで話が噛み合わない場面があります。実物を前にした話し合いは、そのズレを埋めるのに役立ちます。背景は新規事業で経営陣と現場がすれ違う原因は進め方のズレで整理しています。

この段階の成果物は、次の3つです。

• プロトタイプを触って出た「これでよい点」と「違う点」の一覧
• 次の段階で作る範囲の合意
• 第2段階で見る指標と、進む・直す・やめるの基準

プロトタイプで見えた違和感は、早い段階であるほど直しやすいものです。ここで出た指摘を、第2段階の作る範囲に反映します。

第2段階：小さく公開して使われ方を見る

次は、限られた利用者に実際に使ってもらう段階です。社内の関係者や、協力してもらえる数社の顧客など、公開範囲を絞って始めます。いわゆるクローズドβの考え方です。公開範囲の決め方や進め方は、新規事業のクローズドβ｜進め方と公開範囲の決め方で扱っています。

この段階で気をつけたいのは、機能を増やしすぎないことです。確かめたいのは「使われるか、使い続けられるか」であって、機能の多さではありません。ユーザーに見せるときの質問の組み立て方は、プロトタイプのユーザーテスト｜新規事業での確かめ方と質問が参考になります。

また、この時期に個人情報や決済など、後から直しにくい部分の設計が問われることがあります。扱うデータの範囲は早めに確認しておきます。新規事業の個人情報とシステム設計｜設計前に確認する点と新規事業のデータ設計｜最初に決めたい5つの持ち方に、確認の観点をまとめています。

第3段階：使われ方に合わせて広げ、直す

限定公開で得られた使われ方をもとに、機能の追加や画面の改善を進める段階です。利用者の動きを見ていると、想定していなかった使い方や、想定していた機能が使われないといった事実が見えてきます。

ここでの原則は、事業の仮説に近い順に作ることです。要望が多い順に並べるのではなく、仮説の検証に効くかどうかで優先度を決めます。この考え方は次の章で詳しく扱います。

また、利用者が増えると、運用の負荷も表に出てきます。問い合わせへの対応、データの管理、権限の整理といった、事業を回すための裏側の機能です。管理画面は後回しにされがちですが、運用の手間を左右します。どこまで最初に作るかは、新規事業の管理画面開発｜最初に作る範囲の見極め方で整理しています。

第4段階：本格運用と次の投資判断

最後の段階は、運用に入り、収益や運用負荷の見通しを立て、次の投資をどうするかを判断する時期です。ここでは、プロトタイプやMVPをそのまま使い続けるか、作り直すかも論点になります。

「MVPは作り直しになるのか」という疑問は、よく挙がります。引き継げる部分と見直す部分は、事業の性質や作り方で変わります。判断の観点はMVPから本開発は作り直し？引き継げる部分と見直す点にまとめています。この論点は第4段階で急に出てくるのではなく、第1段階の作り方から意識しておくほうが、後で慌てずに済みます。

機能の並べ方：仮説に近い順、後から直しにくい順

ロードマップの中でいちばん悩みやすいのが、機能の並べ方です。やりたいことは多く、予算と時間には限りがあります。判断の軸を2つ持っておくと整理しやすくなります。

軸1：事業の仮説にどれだけ近いか

最初に作るのは、事業の成否を左右する仮説を確かめる機能です。たとえばマッチングサービスなら、「出会ってもらう流れ」が成り立つかが最初の論点です。評価の細かな表示や並べ替えの工夫は、その後でも間に合います。

絞り込みの基準は、MVP開発の機能の絞り方｜最初に作るものと後回しの基準に詳しくあります。分野ごとの最初の範囲は、SaaS新規事業の開発｜最初に作る範囲の決め方やマッチングサービス開発の進め方｜最初に決める5つのことも参考になります。

軸2：後から直しにくいかどうか

もう1つの軸は、「後から変えるのが大変なもの」を早めに考えておくことです。データの持ち方、利用者の認証、決済の仕組みなどは、後から変えると影響が広く及びます。逆に、画面の見た目や文言は、比較的あとからでも直せます。

この2軸で整理すると、次のような優先度になります。

• 仮説に近く、後から直しにくい：最初に設計し、早く確かめる
• 仮説に近く、後から直しやすい：最初は簡易な形で作る
• 仮説から遠く、後から直しにくい：必要になる前に方針だけ決めておく
• 仮説から遠く、後から直しやすい：後回しにする

認証や決済のように外部サービスを使える領域では、自作するか使うかの判断も要ります。新規事業の決済システム開発｜外部サービスと自作の分け方が判断の参考になります。

計画の見直し方：変えてよいものと、守るもの

新規事業のロードマップは、描いた時点から変わるのが前提です。ただし、変え方に決まりがないと、場当たり的な追加が積み重なり、いつの間にか目的から離れてしまいます。

見直しの節目を決めておく

見直しは、各段階の終わりに行います。途中で思いついた要望は、その場で作業に加えるのではなく、いったん一覧に入れて、節目で優先度を付け直します。段階の途中で割り込みが続くと、確かめたかったことの結果がぼやけるためです。

追加要望の扱い方は、システム開発の仕様変更への対応｜追加要望の扱い方で整理しています。

変えてよいものと守るものを分ける

見直しの際は、次のように分けて考えると整理しやすくなります。

• 変えてよいもの：機能の順番、画面の形、公開の範囲、段階の期間
• 守るもの：解決したい困りごと、確かめる仮説、やめる条件

目的や仮説そのものを変える場合は、見直しではなく「事業の方向転換」にあたります。この場合は、ロードマップを手直しするより、事業の仮説から描き直すほうが筋が通ります。

進捗は実物で確認する

計画どおりに進んでいるかは、報告書だけでは分かりにくいことがあります。定例会で実際に動く画面を見る習慣があると、認識のズレを早く見つけられます。見どころはシステム開発の進捗確認のしかた｜定例会とデモの見どころに整理しています。実物を見ながらすり合わせる利点は、システム開発の認識のズレを防ぐ、実物を見ながらのすり合わせでも扱っています。

ロードマップを社内で共有し、合意を得る

ロードマップは、描いて終わりではなく、社内の関係者に共有し、納得してもらうことで初めて機能します。特に、決裁者と現場で見ている材料が違うと、計画への温度感がずれやすくなります。

決裁者に伝えるときの工夫

決裁者に必要なのは、「いくらかかるか」の前に「何を確かめ、どの時点で何を判断するか」の見通しです。段階ごとの節目と、各節目で見る指標を示すと、一度にすべてを決める必要がないことが伝わります。

企画書だけで決裁を得る難しさは、新規事業の決裁を企画書だけで取るのが難しい理由で説明しています。稟議でプロトタイプを使う方法は、稟議を通すシステム開発｜プロトタイプの使い方が参考になります。

段階的な投資判断として見せる

ロードマップは、1年分の投資を最初に決めるための表ではなく、段階ごとに投資を判断していくための表として見せるのが有効です。小さく作って確かめる進め方は、新規事業の開発は小さく作って確かめる投資判断の進め方にあります。

社内にエンジニアがいない場合

社内に開発の担当者がいない場合でも、ロードマップは描けます。技術的な判断を社外の開発パートナーと分担し、事業側は仮説と判断に集中する形です。進め方の注意点は、新規事業でエンジニアいない会社の進め方｜システム開発で整理しています。内製と外注の判断軸は、内製と外注どちらがいい？新規事業システムの判断軸も参考になります。

まとめ

新規事業の開発ロードマップは、機能の予定表ではなく、仮説を確かめる順番と、各節目の判断を並べた地図として描くのが実態に合います。この記事のポイントを整理します。

• 描く前に、事業の仮説、判断の指標と判断者、やめる条件の3つを決めておく
• プロトタイプの後の1年は、評価と合意、限定公開、拡大と改善、本格運用の4段階で見通す
• 機能は、事業の仮説に近いか、後から直しにくいかの2軸で並べる
• 見直しは各段階の節目で行い、変えてよいものと守るものを分けておく
• 決裁者には、段階ごとに投資を判断できる形で示す

先の期間ほど粗く、近い期間ほど具体的に描くことで、確かめた結果を次の計画に反映しやすくなります。新規事業に取り組む私たちにとって、ロードマップは完成させるものというより、確かめながら更新していくものだと言えます。

JustFitは、構想をもとに約1ヶ月で動くプロトタイプを先に開発し、実物を見てから契約するかを判断できる受託開発サービスです。納品後も、システムの維持や不具合の修正に加えて、毎月ひとつの機能追加まで対応する伴走型の技術支援を行っています。プロトタイプの先の進め方を一緒に考えたい場合は、JustFitのサービス紹介もご覧ください。