MVP開発の期間は、対象範囲と品質条件しだいで約1週間から約3ヶ月まで変わります。これは一般論の幅ではなく、Wildcardが実際に構築・検証したMVPの実績値です。
「標準期間」を探すより、自社の案件がどのタイプに近いかを見る方が、計画の精度は上がります。本記事では、実績の週次内訳、期間を左右する要因、短縮の方法を整理します。MVP開発全体の進め方はMVP開発とはを参照してください。
この記事のポイント
- 実績は、ノーコード型で約1週間、アプリ公開型で約1ヶ月、実ユーザー検証まで約3ヶ月
- 期間を決めるのは技術力だけでなく、対象範囲・連携・品質・規制・検証運用の5要因
- 短縮の王道は、機能を薄くすることではなく対象範囲を絞ること
- 「開発が終わる日」と「検証が終わる日」は別。判定日まで含めて計画する
タイプ別の実績期間
Wildcardが実際に構築したMVPの期間です。
| MVPのタイプ | 実施内容 | 実績期間 |
|---|---|---|
| ノーコード型 | GPTsを用いた小規模MVPの構築・初期リリース | 約1週間 |
| 技術検証型 | 検証スプリントで4機能を技術検証し、本番実装まで | 約2週間 |
| アプリ公開型 | ヘルスケアアプリをApp Storeへ初期リリース | 約1ヶ月 |
| 実ユーザー検証型 | オープンβ・クローズドβ公開、ユーザーインタビュー、機能追加 | 約3ヶ月 |
いずれも10X BUILD・10X EXPLOREの活用事例として公開しています。
週次の内訳 — 実例から
期間の数字だけでは計画に使えません。実例の週次内訳を示します。
約1週間 — ノーコード型(GPTs)
GPTsを用いた小規模MVPを、コードを書かずに約1週間で初期リリースした例です。LP(ランディングページ)を合わせて用意し、「誰にどう届くか」の反応を確かめる状態まで持ち込みました。ノーコード型は構築が速い分、計測・連携・品質の上限が早く来るため、次の段階(本開発)の判断材料を得ることに目的を絞ります。
約2週間 — 技術検証型(放送局)
LLMによる映像メタデータ自動生成プロジェクトの例です。
- Week 1: 検証スプリント(10時間×4本) — 動画解釈・音声活用など4つの新機能を技術検証。各スプリントで核心課題を一つに絞り、スピード最優先の検証コードで仮説を確認
- Week 2: 本番実装スプリント(40時間) — 検証結果をもとにプロダクション実装。テストを組み込み、デプロイ可能な状態へ
検証コードと本番コードを意図的に分けることで、2週間で「検証済みかつ運用に耐える」実装に到達しています。スプリント設計の詳細は2週間で技術検証から本番実装へ、PoCとMVPの接続についてはMVPとPoCの順番を参照してください。
約1ヶ月〜3ヶ月 — アプリ公開型・実ユーザー検証型(ヘルスケア)
Apple Watch連動のヘルスケアアプリの例です。
- W1-4: 初期リリース — 事業仮説の検証に必要な最小限の機能に絞り、1ヶ月でApp Storeへ公開。テストユーザーを確保し、初期の利用文脈と反応を取得
- W4-8: ユーザー理解の深化 — ユーザーインタビュー・アンケートによる定性調査。オープンβを通じて課題・期待・利用背景を深掘り
- W8-12: 仮説検証の拡張 — LLMチャット機能を追加し、新たな事業仮説をテスト。クローズドβで限定ユーザーに提供し、反応を比較
「1ヶ月で公開」はゴールではなく、3ヶ月の検証計画の最初のマイルストーンです。この事例の機能の絞り方と公開範囲の設計は1ヶ月でMVPをApp Store公開した進め方で詳しく公開しています。
期間を左右する5つの要因
同じ「MVP」でも、次の条件で期間は大きく変わります。
| 要因 | 短くしやすい条件 | 長くなりやすい条件 |
|---|---|---|
| 対象範囲 | 一人の利用者、一つの業務 | 複数部門、多数の権限・例外 |
| 外部連携 | 手入力、単一サービス | 基幹システム、複数API、データ移行 |
| 品質条件 | 招待制、限定データ | 24時間運用、高可用性、大量アクセス |
| 規制・安全 | 一般情報、低リスク | 個人情報、金融・医療、監査要件 |
| 検証運用 | 利用者へ直接連絡できる | 募集・営業・契約調整が必要 |
見落とされやすいのは検証運用です。開発が1ヶ月で終わっても、テストユーザーの募集や社内の利用許可に2ヶ月かかれば、学びを得るまでの期間は3ヶ月です。
期間を短縮する4つの方法
- 対象範囲を絞る — 最も効果が大きい。機能を薄く広げるのではなく、ユーザー・業務・データを一点に絞る。絞り方は最小スコープ×最大完成度で解説
- ノーコード・既存ツールで始める — 仮説がシンプルなら、GPTsなどで1週間の検証が可能。本開発の前段として使う
- AIをフル活用した開発体制 — 設計・実装・テストをAIで圧縮する。同じ体制でも開発速度が数倍変わる。変化の背景はAIでMVP開発の何が変わったかを参照
- 判断を待たせない — 仕様の確認や判定を週次でまとめて行うと、その待ち時間が期間に直結する。即答できる意思決定者を置く
逆に、品質を落として短縮するのは避けます。対象範囲内の完成度を下げると、「使いにくいから使われない」のか「価値がないから使われない」のか判別できず、検証自体が失敗します。
「開発期間」と「検証期間」を分けて計画する
MVPの計画で最も多いミスは、リリース日をゴールに置くことです。実際に必要なのは次の合計です。
- 要件定義(仮説・判断基準・対象範囲の合意): 数日〜1週間
- 構築: 上記のタイプ別期間
- 検証運用(利用・計測・インタビュー): 業務が一巡する期間(週次業務なら数週間、月次業務なら1〜2ヶ月)
- 判定(継続・変更・撤退の決定): 判定日を事前に固定
検証期間は業務の周期で決まるため、開発を速くしても短縮できません。判定日から逆算して全体を設計します。
よくある質問
MVP開発の平均期間はどれくらいですか
意味のある平均はありません。実績ベースでは、ノーコード型が約1週間、業務ツール・アプリ公開型が約1ヶ月、実ユーザー検証まで含めると約3ヶ月です。自社の案件が上の5要因のどちら側に寄るかで見積もります。
最短でどれくらいで作れますか
仮説がシンプルで、ノーコードで体験を再現できるなら約1週間で初期リリースまで可能です。ただし短さ自体に価値はなく、「その期間で判断材料が取れるか」で決めます。
開発期間を半分にしたい場合、何を削るべきですか
機能の完成度ではなく、対象範囲(ユーザー・業務・データ・連携)を削ります。範囲が半分になれば、開発・テスト・運用準備が連動して縮みます。完成度を削ると検証結果が解釈できなくなります。
