MVP開発の進め方を解説する記事の多くは、「小さく作って検証する」で終わっています。方向性としては正しいのですが、実務では「小さくとはどこまでか」「検証とは何を見ることか」が決まらず止まります。

本記事では、7つのステップを各工程の成果物（何ができていれば次に進めるか）とセットで示します。曖昧なまま次に進んだ工程が、後でどう跳ね返るかまで扱います。

MVPの定義や費用構造など全体像は「MVP開発完全ガイド」をご覧ください。

7ステップの全体像はどうなっているか？

各ステップの成果物は何か？

手順を工程名だけで共有すると、各工程が「終わったこと」にされてしまいます。防ぐには、工程ごとに何ができていれば次に進んでよいかを成果物として定義することです。以下の表は、そのまま進捗管理の判定基準として使えます。目安期間も併記していますが、これは絶対値ではなく工程間のバランスを示すものとして見てください。

全体で5〜9週間が目安です。これを超える場合、STEP3のスコープ削減が不十分か、STEP1の仮説が曖昧です。

STEP1〜2：仮説と指標を決める

STEP1：仮説はどう書くのか？

次の型で1文に落とします。

【誰が】／【どんな状況で】／【何に困っていて】／【どうなれば】／【対価を払う・使い続ける】

悪い例：「営業がもっと効率的に働けるアプリ」
良い例：「訪問営業の担当者が、商談直後の車内で、報告書作成に平均25分かけていて、音声入力で5分に短縮できれば、毎日使い続ける」

後者は測定できます。前者は測定できません。測定できない仮説から作られたMVPは、結果が出ても解釈できません。

STEP2：検証指標と撤退基準はどう決めるのか？

7ステップの中で最も飛ばされ、最も高くつく工程です。次の3点を書いてください。

撤退基準がないプロジェクトは止まりません。結果が芳しくなくても「機能が足りないから」「周知が足りないから」と理由が足され、投資が続きます。MVPの価値は早く成功することではなく、早く失敗を確定させることにあります。

STEP2で押さえるべき「測ってはいけない指標」

意見ではなく行動を測ります。

人は「使いたい」と答え、使いません。社内DXなら「2週間後も自発的に使われているか」が最も実用的です。

STEP3〜4：スコープを削り、動くものを作る

STEP3：何を削るのか？

判断基準は1問です。「この機能がなければ、仮説を検証できないか？」。YESなら入れる、NOなら落とす。

実務では次が高確率で「NO」になります。

• 管理者向けの設定画面——初期は手作業で運用すればよい
• 権限のきめ細かな制御——限定ユーザーで検証するなら不要
• 外部システムとの自動連携——CSVの手動取り込みで足りる
• デザインの作り込み——機能が動くことが先
• エッジケースの網羅——頻度の低い例外は手運用でカバー

成果物は「作るもの一覧」ではなく「作らないもの一覧」です。後者を書き出しておくと、STEP4以降で「やっぱりこれも」と言われたときに立ち返れます。

STEP4：どう作るのか？

2週間以内に、実際に触れる画面を用意します。この段階の目的は完成ではなく「認識のズレを表面化させること」です。画面を見た瞬間に「そうじゃない」が出るのは成功であって失敗ではありません。

作り方の選択肢は3系統あります。

3行目を選択肢に入れられるかが、経験の差が出るところです。「AIが自動で見積書を作る」仮説なら、初期はフォームで受けて担当者が手で作って返す。これでAI実装ゼロのまま体験価値を検証できます。

STEP4でやってはいけないこと

品質を落とすことです。MVPの「Minimum」は機能の範囲であって品質ではありません。バグだらけのものを出すと、ネガティブな反応が「仮説が違う」のか「実装が悪い」のかを区別できず、学習装置として機能しなくなります。

STEP5〜6：実データと実ユーザーで検証する

STEP5：なぜダミーデータでは不十分なのか？

実データを入れた瞬間に、想定外の表記ゆれ・欠損・例外パターンが噴出するためです。ここで出た問題こそが本番化の要件であり、ダミーデータでの検証はこの発見を先送りにするだけです。

とくに日本語環境では、ダミーの英文で組んだレイアウトが実際の日本語を入れた途端に崩れます。文字数と改行位置が変わるためです。

STEP6：実地検証はどう設計するのか？

実地検証は「使ってもらって感想を聞く」だけでは成立しません。誰に、どれくらいの期間、何を測りながら使ってもらうかを設計しておかないと、得られるのは印象論だけになります。以下の4点は、いずれも省略されがちですが、省略すると結果の解釈ができなくなる項目です。

1. 対象者を5〜15名に限定する——多すぎると個別の声が拾えない
2. 2〜4週間の期間を区切る——初週は物珍しさで使うため、2週目以降が本番
3. 使われ方をログで見る——申告ではなく実際の利用データ
4. 使わなかった人に理由を聞く——使った人の意見より情報量が多い

4番目が最も価値があります。離脱した理由には、仮説の欠陥が直接現れます。使い続けた人へのインタビューは、たいてい「便利です」で終わります。

STEP6で必ず行う安全確認

実ユーザーに出す以上、MVPでもセキュリティ要件は緩みません。とくにデータベースのアクセス制御（行レベルセキュリティ）の設定漏れは、設定していなくてもアプリが正常に動くため通常のテストでは発見できません。別アカウントでログインして他人のデータが見えないことを実地で確認してください。手順は公開前チェックリストに、観点はOWASP Top 10やIPA「安全なウェブサイトの作り方」にまとまっています。個人データを扱う場合は個人情報保護委員会のガイドラインも確認が必要です。

STEP7：どう判断するのか？

選択肢は3つある

検証結果を受けての判断は、あらかじめ選択肢を定義しておくと迷いません。とくに重要なのは、「継続」と「撤退」の間に「転換」を置くことです。この選択肢がないと、基準未達の結果に対して無理に継続の理由を探すか、学びごと捨てて撤退するかの両極端になります。

「転換」は敗北ではありません。検証の過程で当初と違う課題が見つかるのは、MVPが正しく機能した証拠です。むしろ最初の仮説がそのまま当たるほうが稀です。

撤退したときに何を残すか？

撤退したプロジェクトを「失敗」として片付けると、組織に何も残りません。残すべきは次の3点です。

• 検証で分かった事実（何が仮説と違ったか）
• 使われなかった理由（次の企画の前提になる）
• 作った資産（コード、データ構造、画面）

とくに3点目は、現在の主要ツールが実コードを生成しGitHubと同期できるため、他の企画で再利用できる形で残せます。この点は従来のPoCと大きく違うところです。

誰が担当し、どんな体制で回すのか？

最小構成は3つの役割

MVPは少人数で回すほど速くなりますが、役割を兼任させてよいものと、絶対に分けるべきものがあります。以下は最小構成として機能する3役割です。人数を減らすことよりも、誰が何を決めるかを曖昧にしないことのほうが速度に効きます。

意思決定者を1人に固定できるかが、最大の分岐点です。合議で決める体制にすると、関係部署の要望が全部入り、STEP3で削ったはずのスコープが復活します。大企業のMVPが失敗する典型パターンがこれです。

情報システム部門はいつ巻き込むのか？

STEP2の段階です。公開直前ではありません。確認しておくべきは4点——SSOの要否、データ保存先のリージョン、学習利用の可否、監査ログの必要性。ここを先に聞いて工程に組み込めば、STEP6の直前で差し戻される事態を防げます。

情シスの役割は「承認者」ではなく「安全に作れる環境を整える人」と定義するのが実務的です。承認者に置くと審査待ちが新たなボトルネックになり、MVPの利点である速度が失われます。IPAのDX推進に関する取り組みやIPA「DX動向2024」でも、推進体制の設計が課題として繰り返し挙げられています。

外部パートナーはどう使うのか？

MVPフェーズは要件が動く前提のため、成果物の完成を約束する請負契約は適しません。準委任での伴走が実務的です。IPAの「情報システム・モデル取引・契約書」でも、工程の性質に応じた契約形態の使い分けが示されています。スコープが確定したSTEP7以降の本番構築で請負に切り替える二段構えにすると、双方のリスクが最小になります。

各ステップでの典型的な失敗は何か？

7ステップそれぞれで、実際に起きやすい失敗を整理します。眺めると分かるとおり、失敗の多くはその工程では気づかず、後工程で顕在化するという共通点を持っています。だからこそ、各工程の完了条件を先に決めておく意味があります。

期間とリソースはどう配分するのか？

工数配分の目安です（開発工数のばらつきについてはIPA「ソフトウェア開発分析データ集2022」も参考になります）。多くのプロジェクトはSTEP4に偏重しています。

構築が安く速くなったぶん、浮いたリソースは企画と検証に回すべきです。ツールの進化で変わったのは実装コストであって、判断の質ではありません。作る速度が上がっただけで検証設計が雑なままなら、間違った方向に速く進むだけになります。

社内DXの場合、進め方はどう変わるのか？

新規事業のMVPとは勘所が異なります。

社内DXではユーザーを確保しやすい代わりに、行動変容が難しいという非対称があります。指示されれば1回は使いますが、面倒なら翌週にはExcelに戻ります。だからこそSTEP2の指標を「導入したか」ではなく「旧手段が廃止できたか」に置いてください。IPA「DX白書」や経済産業省「DXレポート」が指摘するとおり、阻害要因は技術より組織側にあります（総務省「情報通信白書」でも同様の傾向が示されています）。

また、企画者が現場ではないケースが多いのも社内DXの特徴です。STEP1の段階で現場の1人を当事者として巻き込めているかが、成否をほぼ決めます。

株式会社100は、世界上位1%・日本唯一のHubSpot認定エリートパートナーとして100社以上のCRM導入・活用を支援し、Lovableの日本公式パートナーとしてMVPの企画・構築・検証設計をご支援しています。

よくある質問（FAQ）

Q1. MVP開発は何から始めればよいですか？

仮説を1文に落とすことからです。「誰が・どんな状況で・何に困り・どうなれば・どうするか」を書けるまで、作り始めないでください。測定できない仮説から作られたMVPは、結果が出ても解釈できません。

Q2. 全体でどれくらいの期間がかかりますか？

7ステップ合計で5〜9週間が目安です。超える場合はスコープ削減が不十分か、仮説が曖昧です。構築工程（STEP4）は1〜2週間に収めてください。

Q3. 最も重要なステップはどれですか？

STEP2（検証指標と撤退基準の決定）です。所要1日にもかかわらず最も飛ばされ、飛ばした場合の代償が最も大きい工程です。ここがないと結果を解釈できず、プロジェクトが止まらなくなります。

Q4. 撤退基準はどう書けばよいですか？

数値と判定日をセットで書きます。例：「4週間後、週1回以上使っている人が3名以下なら中止。◯月◯日の定例会で判定」。判定日を決めないと「もう少し様子を見る」が繰り返されます。

Q5. どこまで機能を削ればよいですか？

基準は1問です。「この機能がなければ仮説を検証できないか？」。管理画面、細かな権限制御、外部システムの自動連携、デザインの作り込み、エッジケースの網羅は、多くの場合削れます。

Q6. アプリを作らずにMVPを検証できますか？

できます。画面イメージだけ用意して裏側は人が手作業で処理する方法（コンシェルジュ型）なら、実装ゼロで体験価値を検証できます。価値を確認してから自動化に投資するのが正しい順序です。

Q7. ダミーデータで検証してはいけないのはなぜですか？

実データを入れた瞬間に表記ゆれ・欠損・例外パターンが噴出し、それこそが本番化の要件だからです。ダミーデータでの検証は、この発見を先送りにするだけです。

Q8. 実地検証は何人に使ってもらえばよいですか？

5〜15名が目安です。多すぎると個別の声が拾えません。期間は2〜4週間。初週は物珍しさで使うため、2週目以降が本当の評価です。

Q9. ユーザーへのヒアリングで気をつけることは？

使わなかった人に理由を聞いてください。離脱理由には仮説の欠陥が直接現れます。使い続けた人へのインタビューは、たいてい「便利です」で終わり情報量が少なくなります。

Q10. 基準を満たせなかったら失敗ですか？

いいえ。選択肢は継続・転換・撤退の3つで、「転換」は敗北ではありません。検証の過程で当初と違う課題が見つかるのは、MVPが正しく機能した証拠です。最初の仮説がそのまま当たるほうが稀です。

Q11. 工数はどう配分すべきですか？

企画・設計30%、構築30%、検証・判断40%が推奨です。多くのプロジェクトは構築に80%を割いています。構築が安く速くなったぶん、浮いたリソースは企画と検証に回してください。

Q12. 社内DXの場合、何が違いますか？

ユーザーは確保しやすい一方、行動変容が難しいという非対称があります。成功指標を「導入したか」ではなく「旧手段（Excel等）を廃止できたか」に置いてください。またSTEP1の段階で現場の1人を当事者として巻き込むことが決定的に重要です。