MVP開発のスケジュールは、「必要な機能を積み上げて期間を出す」のではなく、「検証を始めたい日から逆算し、その期間に収まる範囲に機能を絞る」考え方で立てるのが基本です。結論から言えば、公開日と体制を先に固定し、要件確定、設計、開発、テスト、公開準備の各工程に時間を割り振ったうえで、収まらない機能は後の段階に回します。そして、遅れの多くは開発そのものではなく、判断待ち、外部との調整、テストと修正の見積もり不足から生まれるため、そこにあらかじめ余裕を置いておくことが遅延を防ぐ鍵になります。
MVPの期間は、作るものの規模や体制によって大きく変わるため、「何か月かかるか」に一律の答えはありません。ただ、期間が延びるほど、市場や顧客の状況が変わり、検証のタイミングを逃すリスクが高まります。MVPのスケジュールで大切なのは、短くすることそのものではなく、検証に必要なものを、必要な時期に確実に出せる計画を立てることです。
この記事は、新規事業のMVPを開発しようとしている事業責任者・新規事業担当者に向けたものです。各工程の考え方と時間の割り振り方、スケジュールの立て方の手順、遅れを防ぐ工夫、よくある失敗とチェックリストを整理します。
MVPのスケジュールが通常の開発と異なる点
一般的なシステム開発では、要件をすべて固めてから設計と開発に進み、計画どおりに作り切ることが目標になります。期間は、作るものの量から見積もるのが普通です。
MVPの場合、考え方の順番が逆になります。MVPの目的は、仮説を早く確かめることです。検証を始めたい時期には、事業上の理由があることが多くあります。顧客の予算の時期、展示会や営業の機会、社内の判断の期限、あるいは単に「早く確かめないと次の判断ができない」という理由です。そのため、MVPでは期間を先に決め、その期間に収まる範囲を作る、という順番で計画します。
また、MVPは作りながら分かることが多く、途中で優先順位が入れ替わることが前提です。スケジュールも、最初に立てた計画を守り抜くものではなく、毎週の状況を見ながら範囲を調整していくものだと考えます。
システム開発全般の期間がどう決まるかについては、システム開発の期間はどう決まるかで工程ごとの考え方を整理しています。
MVP開発の工程と、それぞれの考え方
MVP開発の工程は、おおむね次の5つに分けられます。それぞれの工程で何をするのか、どこで時間がかかりやすいのかを見ていきます。
| 工程 | 主な作業 | 時間がかかりやすい原因 | 短くする工夫 |
|---|---|---|---|
| 要件確定 | 検証したい仮説、機能の範囲、画面の流れを決める | 社内の合意、範囲の議論が長引く | 判断する人を一人に決め、期限を切る |
| 設計 | 画面の構成、データの構造、技術の選定 | 選択肢の比較に時間を使いすぎる | 実績のある技術と既製の部品を使う |
| 開発 | 機能を作る、外部サービスと連携する | 想定外の技術的な問題、判断待ち | 週ごとに動くものを確認し、問題を早く見つける |
| テスト・修正 | 動作の確認、不具合の修正、受け入れの確認 | 見つかった不具合の修正に時間がかかる | 開発の途中から確認を始め、最後に溜めない |
| 公開準備 | 本番環境の準備、規約や表示、運用の体制 | 外部の審査や社内の手続き | 外部の手続きは開発と並行して早めに進める |
要件確定
要件確定は、MVPのスケジュールの中で最も伸び縮みしやすい工程です。検証したい仮説、MVPに入れる機能、主要な画面の流れを決めます。ここで大切なのは、すべてを細かく決めきろうとしないことです。MVPでは、作りながら分かることを前提に、最初は「何を検証するか」と「主要な流れ」だけを決め、細部は開発の中で詰めていきます。
機能の範囲の決め方はMVPの機能の絞り方で、仕様をどこまで書くかについてはMVP開発の仕様書はどこまで書くかで詳しく扱っています。
設計
設計では、画面の構成、データの構造、使う技術を決めます。MVPでは、実績のある技術と、既製の部品や外部サービスを積極的に使うことで、設計の時間を短くできます。新しい技術を試したくなることもありますが、MVPの段階では、開発の担当者が慣れている技術を選ぶほうが、予期しない問題を避けられます。
開発
開発の工程では、機能を作り、外部のサービスと連携させます。この工程で遅れが生じる原因として多いのは、技術的な問題よりも、判断待ちと、外部サービスとの連携の想定外の手間です。週ごとに動くものを確認する場を設けておけば、問題を早く見つけ、範囲を調整する判断ができます。
テスト・修正
テストと修正の工程は、見積もりで最も軽く見られがちな部分です。テストで見つかった不具合を直し、直した部分をもう一度確認するのには、思った以上に時間がかかります。開発の最後にまとめてテストするのではなく、開発の途中から機能ごとに確認を進め、最後の工程に負担を溜めないようにします。どこまでテストするかの線引きはMVPの品質基準を参考にしてください。
公開準備
公開準備では、本番環境の用意、利用規約やプライバシーポリシーの整備、問い合わせ窓口や障害時の連絡体制の準備を行います。アプリストアの審査や、決済サービスの審査、社内のセキュリティ審査など、自社だけで期間を決められない手続きが含まれることがあります。これらは開発と並行して、できるだけ早く始めます。
スケジュールの立て方の手順
MVPのスケジュールは、次の手順で立てます。
- 検証を始めたい日を決める：事業上の理由から、いつまでに利用者に使ってもらいたいかを決める。理由も一緒に書いておく
- 体制を確認する：誰がどのくらいの時間を割けるか、外部の協力者はいつから参加できるかを確認する
- 外部の手続きを洗い出す：審査、契約、社内の承認など、自社で期間を決められない手続きと、その所要の目安を調べる
- 工程ごとに時間を割り振る：検証を始めたい日から逆算して、公開準備、テスト・修正、開発、設計、要件確定の順に時間を割り振る
- 機能の候補に手間の見積もりをつける：開発の担当者に、機能ごとのおおよその手間を見積もってもらう
- 期間に収まる範囲を決める：優先順位の高い機能から順に、開発の期間に収まるところまでをMVPの範囲とする。収まらない機能は次の段階に回す
- 余裕を置く：工程ごとに、判断待ちや想定外の問題のための余裕を置く。特にテスト・修正と公開準備には十分な余裕を持たせる
- 区切りを決める：数週間ごとに、何が出来上がっているべきかの区切りを決め、進み具合を確かめられるようにする
- 関係者と合意する：スケジュールと範囲、収まらなかった機能の扱いを、関係者と合意して文書にする
この手順のポイントは、4と6です。期間を先に決め、その期間に収まる範囲に機能を絞ることで、「作りたい機能をすべて作ると公開が遅れる」という状況を避けられます。作業の分け方を整理する方法としては、WBSと呼ばれる作業分解の手法も使えます。ただし、MVPではあまり細かく分けすぎず、週単位で確認できる粒度に留めるのが実用的です。
遅れを防ぐための工夫
MVPのスケジュールが遅れる原因は、多くの場合、事前に予想できるものです。次の工夫を取り入れておくと、遅れを大きく減らせます。
判断待ちを溜めない
開発の担当者からの質問に、発注側や責任者がすぐに答えられないと、開発は止まります。判断が必要な事項を一覧で管理し、誰がいつまでに答えるかを決めておきます。週次の打ち合わせでは、判断待ちの事項を必ず確認します。
範囲の追加には入れ替えで対応する
開発の途中で新しい機能を追加したくなったら、何かを外すか後ろに回すことをセットで決めます。追加だけを重ねると、期間内に終わらない作業が少しずつ積み上がり、最後の数週間で問題が表に出ます。
外部の手続きを早めに始める
審査や社内の承認など、自社で期間を決められない手続きは、開発の完了を待たずに並行して進めます。必要な書類や条件を早めに確認し、公開の直前に手続きが終わらないという事態を避けます。
毎週、動くものを確認する
週ごとに動くものを確認する場を設けると、問題を早く見つけられます。資料や報告だけで進み具合を判断すると、実際には動かない、思っていたものと違う、ということに最後まで気づかないことがあります。
遅れを早く共有できる雰囲気をつくる
遅れの報告をためらう雰囲気があると、問題が表に出るのが遅くなります。遅れやリスクは早く出すほど対処の選択肢が多い、という姿勢を責任者が示すことが大切です。
スケジュールの判断基準
遅れの兆候が見えたときに、どう判断するかの基準も決めておきます。
| 状況 | 判断の選択肢 | 判断の目安 |
|---|---|---|
| 機能の一部が期間内に終わらない見込み | その機能を次の段階に回す | 検証に必須でなければ、まずこれを選ぶ |
| 検証に必須の機能が遅れている | 公開日を動かす、または手作業で代替する | 手作業で代わりができるなら代替を検討 |
| テストで重大な不具合が多く見つかる | 公開日を動かす | 利用者の信頼やデータに関わる不具合は公開前に直す |
| 外部の審査が間に合わない | 審査が不要な形で先に公開する、公開日を動かす | 審査の対象を外した形で検証できるか検討 |
| 体制に欠員が出た | 範囲を減らす、外部の協力を追加する | 追加の人員は立ち上がりに時間がかかる点を考慮 |
公開後の数週間もスケジュールに含める
MVPのスケジュールを公開日で終わらせてしまうのも、よくある見落としです。公開した直後は、想定していなかった使われ方による不具合、利用者からの問い合わせ、計測の不備の修正など、細かな対応が集中します。この期間に開発の担当者が別の仕事に移ってしまうと、対応が遅れ、せっかくの検証の初期に利用者の体験を損ないます。
そこで、公開後の数週間も、MVPのスケジュールの一部として計画しておきます。具体的には、次のような内容を入れておきます。
- 公開後しばらくは、開発の担当者が不具合の修正にすぐ対応できる体制を保つ
- 利用者の行動の記録と問い合わせを毎日確認し、優先して直すものを決める
- 公開から一定期間後に、検証の途中経過を振り返る日をあらかじめ決めておく
- 振り返りの結果を受けて、次の段階で作る機能の候補を整理する
公開後の期間を計画に入れておくと、関係者も「公開して終わり」ではなく「公開してからが検証の本番」という意識を共有しやすくなります。公開後の改善の優先順位の付け方は、検証で得た記録と利用者の声をもとに決めていきます。
具体的な場面の例
架空の例で考えてみます。ある会社が、地域の不動産会社向けに、内見の予約と顧客への連絡を一元管理するWebサービスのMVPを作ることにしました。検証のために協力してくれる不動産会社は、繁忙期が始まる前に使い始めたいと考えていました。そこで、繁忙期の少し前を検証の開始日と決めました。
最初に機能の候補を洗い出すと、内見の予約、物件の情報管理、顧客への自動連絡、スタッフの予定管理、集計の画面、外部の物件情報サイトとの連携など、多くの機能が挙がりました。開発の担当者に手間を見積もってもらうと、すべてを作ると検証の開始日に間に合わないことが分かりました。
そこで、次のように範囲を決めました。
- 内見の予約と、予約の一覧：MVPで作る（検証の中心）
- 顧客への連絡：予約確定時の連絡だけを自動にし、それ以外は手作業で行う
- 物件の情報管理：最小限の項目だけを登録できるようにする
- スタッフの予定管理：既存のカレンダーツールで代用する
- 集計の画面：作らず、データを書き出して手作業で集計する
- 外部の物件情報サイトとの連携：次の段階に回す
また、メール送信のサービスの設定や、協力会社との契約の手続きは、開発の初期から並行して進めました。テストは機能ごとに開発の途中から始め、最後の数週間は修正と公開準備に充てました。
開発の途中で、協力会社から「内見の前日に顧客へ確認の連絡を送りたい」という要望が出ました。検証に有用と判断したため追加することにし、その代わりに、物件の写真を複数登録できる機能を次の段階に回しました。こうした入れ替えを繰り返しながら、予定どおりの時期に検証を始めることができました。
公開後の数週間は、開発の担当者がそのまま不具合の対応に当たる計画にしていたため、協力会社から寄せられた細かな使いにくさの指摘にも、すぐに対応できました。繁忙期の始まりという、検証にとって最も重要な時期を逃さずに利用の記録を集められたことが、次の段階の判断の大きな材料になりました。
よくある失敗と避け方
作りたい機能から期間を積み上げる：機能を積み上げて期間を出すと、検証の開始が遅れがちです。期間を先に決め、収まる範囲に機能を絞ります。
テストと修正の時間を軽く見る：テストと修正には思った以上に時間がかかります。開発の途中から確認を始め、最後の工程には十分な余裕を置きます。
外部の手続きを後回しにする：審査や承認の手続きが公開の直前に間に合わない、というのはよくある失敗です。開発と並行して早めに進めます。
判断する人が決まっていない：判断が遅れるたびに開発が止まります。判断する人を一人に決め、判断待ちの事項を一覧で管理します。
余裕をまったく置かない：すべての工程を最短で見積もると、少しの問題でスケジュールが崩れます。判断待ちや想定外の問題のための余裕を、あらかじめ計画に入れておきます。
計画を一度立てたら見直さない：MVPは作りながら分かることが多いため、計画も週ごとに見直します。見直しのたびに、範囲と公開日のどちらを調整するかを判断します。
スケジュールを立てるときのチェックリスト
- 検証を始めたい日と、その理由が決まっている
- 社内と外部の担当者が、いつからどのくらいの時間を割けるかを確認した
- 審査、契約、社内の承認など、外部の手続きとその所要の目安を洗い出した
- 工程ごとに時間を割り振り、テスト・修正と公開準備に十分な余裕を置いた
- 機能ごとに手間の見積もりがあり、期間に収まる範囲を決めた
- 収まらなかった機能の扱い（次の段階に回す、手作業で代替する）を決めた
- 数週間ごとの区切りと、その時点で出来上がっているべきものを決めた
- 判断する人と、判断待ちの事項を管理する方法を決めた
- 週ごとに動くものを確認する場を設けた
- スケジュールと範囲を、関係者と合意して文書にした
公開前の最終確認にはMVPリリース前チェックリストもご活用ください。
よくある質問
Q. MVPの開発期間はどのくらいが適切ですか？
作るものの規模、体制、外部の手続きの有無によって大きく変わるため、一律の答えはありません。大切なのは、検証を始めたい時期から逆算して期間を決め、その期間に収まる範囲に絞ることです。期間が長くなりそうな場合は、範囲を減らす、手作業で代替する、段階に分けて公開する、といった方法を検討します。
Q. スケジュールの余裕はどのくらい置けばよいですか？
体制の経験、技術の新しさ、外部の手続きの多さによって変わります。初めて組む体制や、慣れない技術を使う場合、外部の審査が絡む場合は、多めに置いておくのが安全です。余裕は工程ごとに分散させるより、テスト・修正と公開準備の前にまとめて置くほうが使いやすいことがあります。
Q. 公開日が動かせない場合はどうすればよいですか？
範囲を調整して対応します。検証に必須の機能を優先し、それ以外は次の段階に回すか、手作業で代替します。公開日が動かせないことが最初から分かっている場合は、早い段階で範囲を小さめに決めておき、余裕ができたら機能を足す計画にすると安全です。
Q. 要件が固まらないまま開発を始めても大丈夫ですか？
MVPでは、すべての要件が固まるのを待たずに開発を始めることが一般的です。ただし、検証したい仮説と主要な画面の流れは、開発を始める前に決めておく必要があります。細部は開発の中で、動くものを見ながら詰めていきます。
Otsumuに相談できること
検証を始めたい時期がはっきりしていて、社内に範囲の判断ができる責任者と、手間を見積もれる開発者がいるなら、この記事の手順とチェックリストに沿って、自社でMVPのスケジュールを立てて運用できます。期間を先に決めて範囲を絞る考え方と、週ごとの見直しを続けることが、遅れを防ぐ一番の方法です。
一方で、機能の手間の見積もりができる人が社内にいない、検証の時期は決まっているが何を削ればよいか判断できない、過去の開発で遅れが続いて計画の立て方を見直したい、といった場合は、事業の判断と開発の見積もりの両方を見られる相手と計画を立てたほうが、現実的なスケジュールになります。
Otsumuは自らも事業を手がける立場から、目的から逆算して作る機能を絞り、AIを活用した少人数・短期間の開発で、構想から公開、公開後の改善まで一気通貫で支援しています。新規事業の爆速MVPシステム開発では、検証の開始時期から逆算した範囲の設計と、毎週動くものを見ながらの調整を基本にしています。PoC / MVP Sprint（300万円〜・税別、6週間を目安に設計）のように、期間を先に決めて検証を進める形もあります。
スケジュールの見立てだけ確認したい段階でも構いません。まずは30分の無料相談で、いまの状況をお聞かせください。
この記事について
Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。
執筆：Otsumu株式会社 ／ 編集日 2026.10.01