MVP開発の進め方を解説する記事の多くは、「小さく作って検証する」で終わっています。方向性としては正しいのですが、実務では「小さくとはどこまでか」「検証とは何を見ることか」が決まらず止まります。
本記事では、7つのステップを各工程の成果物（何ができていれば次に進めるか）とセットで示します。曖昧なまま次に進んだ工程が、後でどう跳ね返るかまで扱います。
MVPの定義や費用構造など全体像は「MVP開発完全ガイド」をご覧ください。
手順を工程名だけで共有すると、各工程が「終わったこと」にされてしまいます。防ぐには、工程ごとに何ができていれば次に進んでよいかを成果物として定義することです。以下の表は、そのまま進捗管理の判定基準として使えます。目安期間も併記していますが、これは絶対値ではなく工程間のバランスを示すものとして見てください。
| STEP | やること | 完了の条件（成果物） | 目安期間 |
|---|---|---|---|
| 1 | 仮説を1文にする | 誰が・どんな状況で・何に困り・どうなれば・どうするか が書けている | 1〜3日 |
| 2 | 検証指標と撤退基準を決める | 数値と判定日が書かれている | 1日 |
| 3 | スコープを削る | 「作らないもの」の一覧がある | 1〜2日 |
| 4 | 動くものを作る | 実際に触れる画面がある | 1〜2週間 |
| 5 | 実データで検証する | 本物のデータで動作を確認済み | 2〜3日 |
| 6 | 限定ユーザーで実地検証 | 指標の実測値が取れている | 2〜4週間 |
| 7 | 判断する | 継続・転換・撤退のいずれかが決定 | 1日 |
全体で5〜9週間が目安です。これを超える場合、STEP3のスコープ削減が不十分か、STEP1の仮説が曖昧です。
次の型で1文に落とします。
【誰が】／【どんな状況で】／【何に困っていて】／【どうなれば】／【対価を払う・使い続ける】
悪い例：「営業がもっと効率的に働けるアプリ」
良い例：「訪問営業の担当者が、商談直後の車内で、報告書作成に平均25分かけていて、音声入力で5分に短縮できれば、毎日使い続ける」
後者は測定できます。前者は測定できません。測定できない仮説から作られたMVPは、結果が出ても解釈できません。
7ステップの中で最も飛ばされ、最も高くつく工程です。次の3点を書いてください。
| 決めること | 書き方の例 |
|---|---|
| 成功の定義 | 「4週間後、対象10名のうち7名以上が週3回以上使っている」 |
| 撤退の定義 | 「4週間後、週1回以上使っている人が3名以下なら中止」 |
| 判定日 | 「◯月◯日の定例会で判定する」 |
撤退基準がないプロジェクトは止まりません。結果が芳しくなくても「機能が足りないから」「周知が足りないから」と理由が足され、投資が続きます。MVPの価値は早く成功することではなく、早く失敗を確定させることにあります。
意見ではなく行動を測ります。
| 信頼度 | 指標 |
|---|---|
| 高 | 継続利用率（2週目・4週目も使っているか）、対価の支払い・予算確保 |
| 中 | 初回利用率、タスク完了率 |
| 低 | アンケートの「使いたい」、社内評判、経営層の反応 |
人は「使いたい」と答え、使いません。社内DXなら「2週間後も自発的に使われているか」が最も実用的です。
判断基準は1問です。「この機能がなければ、仮説を検証できないか？」。YESなら入れる、NOなら落とす。
実務では次が高確率で「NO」になります。
成果物は「作るもの一覧」ではなく「作らないもの一覧」です。後者を書き出しておくと、STEP4以降で「やっぱりこれも」と言われたときに立ち返れます。
2週間以内に、実際に触れる画面を用意します。この段階の目的は完成ではなく「認識のズレを表面化させること」です。画面を見た瞬間に「そうじゃない」が出るのは成功であって失敗ではありません。
作り方の選択肢は3系統あります。
| 手段 | 向くケース |
|---|---|
| AI生成型ツール（Lovable、Bolt、v0） | 動くアプリで検証したい。コードを後で引き継ぎたい |
| 既製ツールの組み合わせ（Notion、Airtable、kintone） | 業務フローを検証したい。既存ライセンスがある |
| 画面イメージのみ（Figma）＋手作業運用 | 体験価値を検証したい。実装前に判断したい |
3行目を選択肢に入れられるかが、経験の差が出るところです。「AIが自動で見積書を作る」仮説なら、初期はフォームで受けて担当者が手で作って返す。これでAI実装ゼロのまま体験価値を検証できます。
品質を落とすことです。MVPの「Minimum」は機能の範囲であって品質ではありません。バグだらけのものを出すと、ネガティブな反応が「仮説が違う」のか「実装が悪い」のかを区別できず、学習装置として機能しなくなります。
実データを入れた瞬間に、想定外の表記ゆれ・欠損・例外パターンが噴出するためです。ここで出た問題こそが本番化の要件であり、ダミーデータでの検証はこの発見を先送りにするだけです。
とくに日本語環境では、ダミーの英文で組んだレイアウトが実際の日本語を入れた途端に崩れます。文字数と改行位置が変わるためです。
実地検証は「使ってもらって感想を聞く」だけでは成立しません。誰に、どれくらいの期間、何を測りながら使ってもらうかを設計しておかないと、得られるのは印象論だけになります。以下の4点は、いずれも省略されがちですが、省略すると結果の解釈ができなくなる項目です。
4番目が最も価値があります。離脱した理由には、仮説の欠陥が直接現れます。使い続けた人へのインタビューは、たいてい「便利です」で終わります。
実ユーザーに出す以上、MVPでもセキュリティ要件は緩みません。とくにデータベースのアクセス制御（行レベルセキュリティ）の設定漏れは、設定していなくてもアプリが正常に動くため通常のテストでは発見できません。別アカウントでログインして他人のデータが見えないことを実地で確認してください。手順は公開前チェックリストに、観点はOWASP Top 10やIPA「安全なウェブサイトの作り方」にまとまっています。個人データを扱う場合は個人情報保護委員会のガイドラインも確認が必要です。
検証結果を受けての判断は、あらかじめ選択肢を定義しておくと迷いません。とくに重要なのは、「継続」と「撤退」の間に「転換」を置くことです。この選択肢がないと、基準未達の結果に対して無理に継続の理由を探すか、学びごと捨てて撤退するかの両極端になります。
| 判断 | 条件 | 次にやること |
|---|---|---|
| 継続 | STEP2で決めた成功基準を満たした | 本番化の設計へ（データ構造・運用体制・統制） |
| 転換 | 基準は未達だが、別の課題が見つかった | 仮説を書き直してSTEP1に戻る |
| 撤退 | 撤退基準に該当した | 止める。学んだことを記録して共有する |
「転換」は敗北ではありません。検証の過程で当初と違う課題が見つかるのは、MVPが正しく機能した証拠です。むしろ最初の仮説がそのまま当たるほうが稀です。
撤退したプロジェクトを「失敗」として片付けると、組織に何も残りません。残すべきは次の3点です。
とくに3点目は、現在の主要ツールが実コードを生成しGitHubと同期できるため、他の企画で再利用できる形で残せます。この点は従来のPoCと大きく違うところです。
MVPは少人数で回すほど速くなりますが、役割を兼任させてよいものと、絶対に分けるべきものがあります。以下は最小構成として機能する3役割です。人数を減らすことよりも、誰が何を決めるかを曖昧にしないことのほうが速度に効きます。
| 役割 | 担うこと | 兼任の可否 |
|---|---|---|
| 意思決定者 | スコープの最終決定、STEP7の判断 | 1人に固定（兼任不可） |
| 現場代表 | 業務要件の提供、実地検証の窓口 | 不可（現場の人であることが要件） |
| 作り手 | STEP4の構築 | 意思決定者との兼任は可 |
意思決定者を1人に固定できるかが、最大の分岐点です。合議で決める体制にすると、関係部署の要望が全部入り、STEP3で削ったはずのスコープが復活します。大企業のMVPが失敗する典型パターンがこれです。
STEP2の段階です。公開直前ではありません。確認しておくべきは4点——SSOの要否、データ保存先のリージョン、学習利用の可否、監査ログの必要性。ここを先に聞いて工程に組み込めば、STEP6の直前で差し戻される事態を防げます。
情シスの役割は「承認者」ではなく「安全に作れる環境を整える人」と定義するのが実務的です。承認者に置くと審査待ちが新たなボトルネックになり、MVPの利点である速度が失われます。IPAのDX推進に関する取り組みやIPA「DX動向2024」でも、推進体制の設計が課題として繰り返し挙げられています。
MVPフェーズは要件が動く前提のため、成果物の完成を約束する請負契約は適しません。準委任での伴走が実務的です。IPAの「情報システム・モデル取引・契約書」でも、工程の性質に応じた契約形態の使い分けが示されています。スコープが確定したSTEP7以降の本番構築で請負に切り替える二段構えにすると、双方のリスクが最小になります。
7ステップそれぞれで、実際に起きやすい失敗を整理します。眺めると分かるとおり、失敗の多くはその工程では気づかず、後工程で顕在化するという共通点を持っています。だからこそ、各工程の完了条件を先に決めておく意味があります。
| STEP | 典型的な失敗 | 結果 |
|---|---|---|
| 1 | 仮説が「〜を効率化する」で止まる | 何を作ればよいか決まらない |
| 2 | 指標と撤退基準を決めずに進む | 結果が出ても解釈できず、止まらなくなる |
| 3 | 「あとで自動化すればいい部分」を最初から自動化 | 工数が数倍に膨らむ |
| 4 | 品質を落として出す | 仮説の是非と実装品質が切り分けられない |
| 5 | ダミーデータで検証を終える | 本番投入後に想定外のデータで壊れる |
| 6 | 使った人だけに感想を聞く | 「便利です」しか集まらない |
| 7 | 判定日を決めずに「もう少し様子を見る」 | 撤退できず投資が続く |
工数配分の目安です（開発工数のばらつきについてはIPA「ソフトウェア開発分析データ集2022」も参考になります）。多くのプロジェクトはSTEP4に偏重しています。
| 工程 | ありがちな配分 | 推奨配分 |
|---|---|---|
| STEP1〜3（企画・設計） | 10% | 30% |
| STEP4〜5（構築） | 80% | 30% |
| STEP6〜7（検証・判断） | 10% | 40% |
構築が安く速くなったぶん、浮いたリソースは企画と検証に回すべきです。ツールの進化で変わったのは実装コストであって、判断の質ではありません。作る速度が上がっただけで検証設計が雑なままなら、間違った方向に速く進むだけになります。
新規事業のMVPとは勘所が異なります。
| 観点 | 新規事業 | 社内DX |
|---|---|---|
| 検証すること | 需要があるか（買うか） | 現場が使い続けるか（切り替わるか） |
| ユーザー確保 | 難しい | 容易（社内にいる） |
| 最大の障壁 | 顧客が振り向かない | 現場が既存のやり方を変えない |
| 成功指標 | 継続課金 | 旧手段（Excel等）の廃止率 |
社内DXではユーザーを確保しやすい代わりに、行動変容が難しいという非対称があります。指示されれば1回は使いますが、面倒なら翌週にはExcelに戻ります。だからこそSTEP2の指標を「導入したか」ではなく「旧手段が廃止できたか」に置いてください。IPA「DX白書」や経済産業省「DXレポート」が指摘するとおり、阻害要因は技術より組織側にあります（総務省「情報通信白書」でも同様の傾向が示されています）。
また、企画者が現場ではないケースが多いのも社内DXの特徴です。STEP1の段階で現場の1人を当事者として巻き込めているかが、成否をほぼ決めます。
株式会社100は、世界上位1%・日本唯一のHubSpot認定エリートパートナーとして100社以上のCRM導入・活用を支援し、Lovableの日本公式パートナーとしてMVPの企画・構築・検証設計をご支援しています。
仮説を1文に落とすことからです。「誰が・どんな状況で・何に困り・どうなれば・どうするか」を書けるまで、作り始めないでください。測定できない仮説から作られたMVPは、結果が出ても解釈できません。
7ステップ合計で5〜9週間が目安です。超える場合はスコープ削減が不十分か、仮説が曖昧です。構築工程（STEP4）は1〜2週間に収めてください。
STEP2（検証指標と撤退基準の決定）です。所要1日にもかかわらず最も飛ばされ、飛ばした場合の代償が最も大きい工程です。ここがないと結果を解釈できず、プロジェクトが止まらなくなります。
数値と判定日をセットで書きます。例：「4週間後、週1回以上使っている人が3名以下なら中止。◯月◯日の定例会で判定」。判定日を決めないと「もう少し様子を見る」が繰り返されます。
基準は1問です。「この機能がなければ仮説を検証できないか？」。管理画面、細かな権限制御、外部システムの自動連携、デザインの作り込み、エッジケースの網羅は、多くの場合削れます。
できます。画面イメージだけ用意して裏側は人が手作業で処理する方法（コンシェルジュ型）なら、実装ゼロで体験価値を検証できます。価値を確認してから自動化に投資するのが正しい順序です。
実データを入れた瞬間に表記ゆれ・欠損・例外パターンが噴出し、それこそが本番化の要件だからです。ダミーデータでの検証は、この発見を先送りにするだけです。
5〜15名が目安です。多すぎると個別の声が拾えません。期間は2〜4週間。初週は物珍しさで使うため、2週目以降が本当の評価です。
使わなかった人に理由を聞いてください。離脱理由には仮説の欠陥が直接現れます。使い続けた人へのインタビューは、たいてい「便利です」で終わり情報量が少なくなります。
いいえ。選択肢は継続・転換・撤退の3つで、「転換」は敗北ではありません。検証の過程で当初と違う課題が見つかるのは、MVPが正しく機能した証拠です。最初の仮説がそのまま当たるほうが稀です。
企画・設計30%、構築30%、検証・判断40%が推奨です。多くのプロジェクトは構築に80%を割いています。構築が安く速くなったぶん、浮いたリソースは企画と検証に回してください。
ユーザーは確保しやすい一方、行動変容が難しいという非対称があります。成功指標を「導入したか」ではなく「旧手段（Excel等）を廃止できたか」に置いてください。またSTEP1の段階で現場の1人を当事者として巻き込むことが決定的に重要です。