MVPの作り方｜仮説から始める5ステップと設計方法を解説

結論：MVPの作り方は仮説選びから始まる5ステップ

MVPは、顧客について学ぶ1仮説を、観測可能な最小表現へ変えたものです。図の順に進める前に「MVP制作票」を用意し、仮説、観測場面、最小表現、制作順、停止条件、廃棄・引継ぎ候補を一枚にまとめます。イノベーション総合研究所では、制作範囲と次の判断を同時に決めることを重視しています。

制作を終える条件と、範囲を変更できる条件も先に合意します。根拠のない機能追加を続けないための約束です。新しい証拠が出たなら、理由と再判断日を記録して範囲を変えられます。

用語の定義はMVPとは何か、表現物の目的と寿命はMVPとプロトタイプの違いで確認できます。本稿で扱うのは、1つの仮説を制作順と構成へ変える実務です。

機能追加は、どの条件で受けるのか

機能の追加を止める条件は、文章にするだけでは不十分です。制作会議で要望を受けたときに、今回の仮説へ必要かを判断できる記録まで用意します。まず、基準を作ることと、実際に使うことの違いを確認します。

基準の明文化と、判断の場での使用を分ける

独自調査は、直近で関わった新規事業の撤退基準について単一回答で尋ねたものです。MVP固有の効果測定ではありませんが、明文化と使用状況を分けて見る材料になります。

比較軸と判断への使い方を確認してください。

出典：イノベーション総合研究所「新規事業の実態と意思決定に関する調査」（2026年4月）。比率の記載がある7区分の合計は94.2%で、未記載の1区分は推定していません。

事前に明文化した回答は24.3+15.0=39.3%ですが、そのうち15.0ポイント分は判断の場で守られませんでした。既知の事前明文化2区分に占める参考比は、15.0÷39.3=38.2%です。MVP制作でも、条件を決める作業と、変更要求に対して条件を使う運用を分けて設計します。

変更要求は4欄の受付票で受ける

変更要求を受ける際には、例外理由、追加証拠、影響範囲、再判断日の4欄を使います。要望の強さと、今回の観測に必要な理由を切り分けるための記録です。

比較軸と判断への使い方を確認してください。

四欄をそろえることは、変更を自動承認するためではなく、必要性を判断するためです。制作責任者と仮説の判断者が今回の観測に必要かを決め、不要な要望は今後の課題として保管します。

たとえば営業から「管理画面も必要」と要望が来た場合、購入候補が権限を確認しなければ試行できない証拠があるかを確かめます。「将来は必要そう」という予想と、今回の観測を妨げる条件は別です。

ステップ1：仮説は、どう絞るのか

最初に作るのは画面でも機能一覧でもなく、仮説票です。今回のMVPで結果が変われば、制作や投資の判断も変わる問いを1つ選びます。

1仮説を観測可能な一文にする

仮説票には、対象者、課題場面、現在の代替、提示価値、期待する行動を書きます。将来の売上目標や全機能を一つの文へ詰めません。

比較軸と判断への使い方を確認してください。

たとえば、月次締めを担当する管理職を対象者にします。「手動サービスへ実データを提供し、再利用を希望する」と書きます。画面機能ではなく、価値と観測行動が先です。

Eric Riesは本人記事「Minimum Viable Product: a guide」で、MVPを、最小の労力で顧客について最大の検証済み学習を得る新製品の版と定義しています。最小化する対象を、機能数だけにしない根拠になります。

最も判断が変わる仮説を選ぶ

不確かでも、結果が次の制作判断を変えない問いは後へ回せます。「ロゴの好み」より、「対象顧客が業務データを渡して試行するか」のほうが、次の投資を変える場合があります。

技術の実現可能性が未確認なら、MVPよりPoCを先に選ぶことがあります。MVPとPoCの違いで、判断境界を分けてください。

複数の問いが結び付いている場合も、制作票では主仮説を一つにします。残りは前提条件か、次の仮説として分離してください。反応がなかったとき、どの制作判断へ戻るかを明らかにするためです。

含めない仮説と部品を同時に書く

仮説を絞るときに「今回は作らない」欄も埋めます。将来必要な機能を否定する欄ではありません。今回の観測に使わない部品を制作範囲から外す欄です。

たとえば通知、管理画面、権限管理が将来必要でも、手動サービスへの再利用意向を確かめるだけなら後回しにできる場合があります。ただし、個人情報、安全、契約上の必須条件は外せません。

当社の支援事例には、MVPへ500万円を投じても顧客を得られなかった案件があります。担当者は機能不足だと考えていましたが、見直すべきだったのは顧客の課題です。顧客自身が困っていると認識していない問題を、解こうとしていました。

「機能が足りないのだと思って追加開発を考えていた。でも本当の問題は、顧客の課題を自分たちの頭の中だけで決めていたことだった。500万円の授業料は高かったが、同じ間違いを繰り返さなくなった。」

顧客課題からMVPを再設計し、4ヶ月でパイロット顧客3社を獲得しました。追加開発費は当初の1/3です。仮説を変えるべき場面で機能追加を答えにせず、課題の確認へ戻った事例です。

この事例を制作判断へ移すなら、追加機能の選定より先に、顧客が課題と認識する場面を確認します。既存MVPへ投じた費用と仮説の支持は別の情報です。残す部品と捨てる部品を分け、次の顧客行動を観測できる構成へ戻してください。

ステップ2：指標と基準は、いつ決めるのか

ステップ2では、観測方法と制作完了の条件を決めます。何が測れる状態まで作るのかを先に置くと、必要な機能と後回しにできる機能を分けやすくなります。

観測箇所から制作項目を逆算する

期待行動が「申込む」なら、申込導線と対象者を識別する記録が必要です。「再利用する」なら、一度目と二度目を同じ条件で追えるようにします。

画面を作った後で計測を相談すると、必要な識別子や同意がなく、結果を再現できないことがあります。先に観測箇所を書き、そこへ到達する最小の体験だけを作ります。

比較軸と判断への使い方を確認してください。

詳細な指標選定や証拠仕分けはMVPの検証方法で扱います。本稿は、観測に必要な部品を制作票へ入れるところまでです。

KPIは判断者と受取日まで決める

同調査では、KPIを経営層と合意し、定期モニタリングと判断への活用までできている回答は28.6%でした。新規事業全体のKPI運用についての自己申告であり、MVP固有の成功率ではありません。

制作票では、計測できる状態を作るだけで終えず、誰がいつ受け取るかまで決めます。数値を集めた後に受取人を探す状態では、制作完了と次の判断がつながりません。

制作完了と変更の条件を合意する

制作完了と変更の条件には、今回の仮説、観測に必要な部品、作らない部品、変更を受ける4欄を書きます。制作中の会議では、新しい要望をこの票と照合します。

顧客行動の証拠が増えた場合、法令や安全条件が判明した場合、技術制約で観測不能になった場合は変更候補です。例外理由、追加証拠、影響、再判断日を記録します。

「役員が欲しいと言った」「競合にある」という理由だけでは、今回の仮説との関係が分かりません。将来要件として残し、今回の制作には自動で入れないようにします。

ステップ3：最小の形は、どう選ぶのか

仮説と観測仕様が決まったら、必要な表現を四区分へ仕分けます。製品コードを作る前に、人や資料で代替できないかを確認します。

作る・手動代替・説明・今回は作らないへ分ける

まず、今回の観測に必要な部分を次の4区分へ仕分けます。将来の製品に必要かどうかではなく、今回その部品がなければ仮説を判別できないかを問いにします。

比較軸と判断への使い方を確認してください。

たとえば、課題の受容を確かめるなら、説明資料と申込導線で足りる場合があります。利用時の価値を確かめるなら、裏側を手動にしても、顧客が受け取る体験は省けません。

TISの技術ノウハウサイトFintan「仮説検証とMVPへの向き合い方」は、MVP開発が必須ではないこと、使い捨てを前提に機能要件を絞ること、人力で代用できる部分を分けることを案内しています。制作範囲を将来製品の縮小版から考えない実務例です。

MVPの形態を仮説から選ぶ

章頭の図は、代表的な4形態と確かめられる問いを対応させたものです。申込みを見たいなら説明資料やLP、実際の利用価値を見たいなら手動代行や単機能を候補にします。

形態名を先に決めず、観測行動に必要な表現を選んでください。動画の再生や感想だけで継続利用を判定する、といった問いと形のずれを避けます。

安全・法務・倫理は「今回は作らない」に入れない

使い捨てMVPでも、対象者へ害を与えてよいわけではありません。個人情報、機密情報、医療・安全、契約、アクセシビリティなど、検証時点で守る条件を先に確認します。

Fintanの同記事も、使い捨てを前提に非機能要件を抑える場合の不都合や、セキュリティへの注意を示しています。最小とは、必要な保護を削ることではありません。

判断に迷う場合は、対象者が負うリスクを減らす形へ戻します。実データを持たずに試す、対象範囲を限定する、専門部門の承認を得るなどを制作条件にします。

制作前の仮説、変更受付、判断者がつながっているかを確認したい方へ。6因子×24問の診断で、着工前の断線を整理できます。

MVP制作のどこで詰まっていますか

6つの論点から、まだ決め切れていないものを1つ開いてください。次に確認する材料を整理できます。

01　顧客と課題の仮説を絞れていない

対象者、課題場面、現在の代替、提示価値、期待行動を一文でつなぎます。

• 誰の反応を学ぶか
• どの場面を再現するか
• 何が起きれば判断が変わるか

02　機能追加を止められない

今回の観測へ必要な証拠があるかを、変更受付票で判断します。

• 例外理由があるか
• 追加証拠があるか
• 再判断日を置いたか

03　測る行動と制作項目がつながらない

期待行動から、識別、提示、記録に必要な部品だけを逆算します。

• 対象条件を識別できるか
• 提示条件を残せるか
• 起きた行動を記録できるか

04　MVPの形を選べない

説明資料、手動代行、単機能、動画のうち、仮説を最短で判別できる形を選びます。

• 申込みを見たいか
• 利用価値を見たいか
• 動くイメージを見せたいか

05　制作の担当者と受取人が曖昧

部品ごとに作る人と、完了を受け取って判断する人を分けます。

• 制作責任者は誰か
• 結果の受取人は誰か
• 廃棄・引継ぎを誰が決めるか

06　市場へ出した後の判断条件がない

続ける、仮説を変える、追加確認する、制作を終える条件を提供前に置きます。

• 提供期間はいつまでか
• 未実装条件を渡したか
• 次の判断日を決めたか

ステップ4：どこまで作るのか

ステップ4では、機能の優先順位ではなく、観測までの順序で作ります。同時に、部品ごとの廃棄条件と引継ぎ候補を記録します。

観測できる順に制作する

制作順は次のように置けます。

比較軸と判断への使い方を確認してください。

見た目を最後にするという一律の順序ではなく、価値の理解にデザインが不可欠なら先に作ります。制作票へ残すのは、なぜその部品が観測に必要なのかという理由です。

国立研究開発法人科学技術振興機構（JST）のSCORE平成30年度募集要項では、想定顧客への検証で明らかにしたい仮説とMVPの機能を明確に結び付けて記載するよう求めています。公募資料の要請を一般企業の必須様式とはしませんが、仮説と制作項目を一対一で確認する参考になります。

開発要件を「仮説に必要な理由」で書く

開発チームへは、機能名だけでなく、仮説ID、観測行動、必要理由、作らない範囲、廃棄条件を渡します。

比較軸と判断への使い方を確認してください。

この形式なら「認証機能を作る」と「対象者を識別する」を分けられます。対象者を個別招待で識別できるなら、大きな認証基盤は今回不要かもしれません。

部品を廃棄・参考・引継ぎ候補に分ける

MVPの制作完了時点で、すべてを本番資産へ変えません。

• 廃棄：仮説専用の画面、仮データ、短期の手作業など
• 参考：設計判断や実装上の学びは残すが、コードは流用しないもの
• 引継ぎ候補：レビュー後に次版へ使える可能性がある部品

引継ぎ候補は、次工程の責任者による安全性、性能、保守、データ、権限の確認を待つ状態です。表現物の寿命と目的はMVPとプロトタイプの違いで詳しく扱っています。

当社の支援事例では、意欲ある5名を集めても3ヶ月間議論だけが続いた案件がありました。全員が自分の制作責任を判断できず、待ち状態になっていました。

「人を増やせば解決すると思っていた。でも、5人で十分だった。誰が何をやるかを決めただけで、チームが動き始めた。最初からこの設計があれば、3ヶ月を無駄にしなかった。」

役割を再定義して2週間で動き始め、3ヶ月で最初のマイルストーンへ到達しました。制作責任が曖昧なまま人を増やすのではなく、担当者と受取人を決め直した事例です。

制作部品ごとに「作る人」と「受け取って完了を判断する人」を分けると、完成を宣言しても受取人が不在になる状態を避けやすくなります。営業資料は営業責任者、計測ログは検証責任者が受け取り、仮実装の廃棄・引継ぎは技術責任者が判定する、といった役割分担です。

ステップ5：市場に出したあと、どう判断するのか

制作側の完了は、対象顧客へ渡せるMVPと、その結果を解釈するための条件がそろった状態です。提供前の確認を済ませ、検証担当と判断者へ引き継ぐところまでを制作に含めます。

提供前の完成条件を確認する

完成条件は、予定機能の消化率ではありません。次を確認します。

• 対象者と提示条件を識別できる
• 顧客が中核価値を誤解なく体験できる
• 期待行動が起きたか、起きなかったかを記録できる
• 安全・法務・倫理上の必須条件を満たす
• 判断者、提供期間、制作終了日が決まっている

一つでも欠けた場合、機能追加ではなく、観測仕様へ戻ります。説明で補えるのか、対象を絞るのか、制作そのものが不要なのかを判断します。

30%は共通の完成度基準ではない

イノベーション総合研究所では、実務上の目安として「30%の完成度で営業資料と組み合わせて市場に出す」という進め方を使っています。作り込みの前に、価値が刺さるかを早く確かめる意図です。

30%は、完成度を客観的に測る尺度や、全事業共通の品質基準ではなく、作り込みを抑える姿勢を表す目安です。安全や法令上の要件を3割に減らさず、今回の検証に必要な品質を満たしてください。

制作票では、未実装部分を営業説明で補っても観測が歪まないかを確認します。説明担当が毎回代行しなければ価値が届かないなら、その条件を残します。

対象者と提供条件を制作側から引き継ぐ

MVPを誰へ出すかは、制作後に営業へ丸投げしません。仮説票の対象条件、課題場面、除外条件を引き継ぎます。

BtoBでは、使う人、運用する人、購入を判断する人が異なる場合があります。BtoB顧客インタビューのやり方を使い、誰の行動かを分けてください。

制作側は、説明の有無、手動代替、制限機能、既知の不具合も渡します。これらが欠けると、顧客行動の理由をMVPだけへ帰してしまいます。

制作を閉じ、次の判断へ渡す

提供開始後は、制作票にない要望を自動で実装しません。変更受付票へ戻し、例外理由、追加証拠、影響、再判断日を確認します。

当社の支援事例には、PoCを3回行っても毎回「もう少しデータが必要」で終わった案件があります。回ごとに検証する問いが変わり、判断基準が定義されていませんでした。

「3回失敗して分かったのは、PoCのやり方ではなく、PoCの設計が間違っていたということだった。判断基準を先に決めるだけで、こんなに景色が変わるとは思わなかった。」

検証論点を3つに絞り、4回目のPoCで初めて事業化承認へ進みました。過去1年半から4ヶ月へ短縮した個別事例です。制作物を増やす前に、何が分かれば次へ進めるのかを決め直しました。

PoCとMVPは同じものではありませんが、追加制作の理由を「もう少し必要」だけで済ませない点は共通します。追加開発を選ぶ前に、未決の仮説、次に得る証拠、制作終了日、受取人が決めることを書いてください。

たとえば、面談数を増やしたいだけなら新機能は不要かもしれません。逆に、実利用時の操作完了を観測できないなら、その経路だけを作る理由になります。

市場で得た反応の判定、証拠の採用・保留・廃棄はMVPの検証方法へ引き継ぎます。本稿の完成点は、検証を終えることではなく、検証可能なMVPと条件を渡すことです。

MVPの作り方で起きやすい失敗

制作が膨らむ原因は、技術力の不足だけではありません。仮説、変更受付、担当者、受取人の断線を確認します。

MVPへ複数の仮説と機能を詰め込む

複数の顧客、課題、価値を一つの制作票へ入れると、各機能の必要理由が曖昧になります。今回の主仮説へ必要な部品だけを入れ、残りは次票へ分けます。

イノベーション総研が点検を重視するのは、「ニーズがある」という思い込みです。機能を作る前に、誰のどの課題を仮説として置いたかを確認してください。

MVPの完成度を上げ続け、市場へ出せない

完成品の要件一覧から引き算すると、どの部品も必要に見えます。観測行動から足し算し、作る・手動・説明・今回は作らないへ分けます。

たとえば管理画面の見栄えを整えても、顧客が中核価値を体験する前に離脱するなら、今回の学びは増えません。合意した制作範囲へ戻り、追加証拠がない要望は後へ回します。

MVPを出した後に指標を決める

計測箇所を後付けすると、対象者、提示条件、手動支援を区別できない場合があります。制作順の最初に、識別と観測の仕込みを置きます。

必要なのは、ログを取得できることと、そのログで誰が何を決めるかの両方です。判断者と受取日まで制作票へ置いてください。

MVPの結果を会議で報告して終える

もう一つ点検したいのが、決裁者への情報不足です。制作物や未実装の一覧を渡すだけでなく、その情報をどの判断に使うのかまで確認してください。

判断者へは、今回の仮説、制作範囲、観測可能な行動、変更履歴、引継ぎ候補を渡します。市場の結果がまだない段階では、追加制作を承認する材料と、本格投資の材料を分けます。

変更要求を口頭で受け続ける

口頭の要望は、前半で示した変更受付票へ移します。「管理画面が欲しい」という要望なら、対象顧客が権限確認なしでは試行できない証拠があるか、観測・日程・廃棄予定に何が影響するかを確認します。

変更理由を尋ねるのは、要望を拒否するためではありません。今回の仮説へ必要かを判断し、必要なら再判断者と日付を置いて制作票を正式に更新するためです。

MVPの作り方に関するよくある質問

制作前から引継ぎまでに出やすい疑問へ答えます。期間やツールを一律に決めず、今回の仮説と提供条件から選ぶ際の判断材料にしてください。

Q. MVPはどのくらいの期間で作りますか

A. 共通の期間はありません。観測に必要な最小表現と、対象者へ安全に提供できる状態から決めます。日程だけを固定せず、制作終了条件と再判断日を置いてください。

Q. エンジニアがいなくてもMVPを作れますか

A. 仮説によっては可能です。説明資料・LP型、手動代行型、動画・デモ型を検討します。実際の利用行動を製品上で測る必要がある場合は、必要部分だけの開発体制を用意します。

Q. MVPにはノーコードツールを使えますか

A. ノーコードは制作手段の候補です。観測行動に必要な機能、データの扱い、権限、安全、廃棄・出力方法を確認します。特定ツールを使うこと自体を制作目的にはしません。

Q. 仮説は本当に1つだけにしますか

A. 事業全体には複数の仮説があっても、一つの制作票で判断する主な問いは一つです。前提条件や副次的な観察は別欄にし、主仮説の支持と混ぜないようにします。

Q. 外注先には何を渡せばよいですか

A. 渡すものは、仮説票、観測仕様、四区分の最小表現マップ、制作完了と変更の条件、部品台帳です。機能一覧だけでは伝わらない手動代替や廃棄予定を示し、変更受付の責任者も決めます。

Q. MVPを出した次は何をしますか

A. 事前の判断基準と観測結果を照合し、続ける、仮説を変える、追加確認する、制作を終えるのいずれかを決めます。その際に使う手順は、MVPの検証方法で解説しています。

本記事のまとめ｜MVPの作り方は計測と判断まで設計する

MVP制作は、1つの仮説を選び、観測したい顧客行動から最小の表現へ変換する仕事です。最初に制作票を開き、「今回確かめること」と「今回は作らないこと」を並べてください。

制作中の変更は証拠と影響を確認して受け、提供時には条件と未実装部分を判断者へ渡します。完成した機能の数ではなく、次の判断に使える状態まで作れたかで制作を閉じます。

MVP制作票を自社の仮説、発注体制、変更会議に合わせて設計したい方へ。着工前の範囲決めから廃棄・引継ぎ候補まで一緒に整理します。