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

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

MVPは、少ない労力で顧客について学び、次の判断を変えるために作ります。図の順に進める前に「MVP制作票」を用意し、仮説、観測場面、最小表現、制作順、停止条件、廃棄・引継ぎ候補を一枚にまとめます。

イノベーション総合研究所では、制作範囲と次の判断を同時に決めることを重視しています。

MVPで検証する仮説の数に共通の決まりはありません。本稿では、制作範囲を広げすぎず、反応が得られない理由を見分けるため、主な問いを一つ選ぶ方法を勧めます。

技術上・安全上の前提は別欄で管理します。

制作を終える条件と、範囲を変更できる条件も先に合意します。これは、根拠のない機能追加を続けないための約束です。

ただし、新しい証拠が出たなら、理由と再判断日を記録して範囲を変えられます。

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

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

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

まず、基準を作ることと、実際に使うことの違いを確認します。

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

撤退・中止基準の明文化と運用状況

事前に明文化・守られた24.3%（216名）

事後に明文化・守られた27.7%（246名）

事前に明文化・守られなかった15.0%（133名）

事後に明文化・守られなかった5.7%（51名）

口頭合意・守られた8.3%（74名）

口頭合意・十分に機能せず5.7%（51名）

未設定9.1%（81名）

わからない4.1%（36名）

01530%

事業開始前に撤退・中止基準を明文化した349名のうち、133名は実際の判断で守られなかったと回答しました。約38.1%（133÷349）です。

これはMVPの機能追加を直接測った数字ではなく、基準を守らなかった理由もこの設問では分かりません。

点検するのは基準への機械的な従属ではなく、変更の根拠と判断者が記録されているかです。顧客の新しい要望や安全上の問題が分かれば、基準を見直すこともあります。

当初の基準、今回得た事実、変更理由を残せば、惰性の追加と必要な修正を分けて振り返れます。

MVP制作でも、検証する問いと作る範囲を合意した後に変更要求が出ます。その際は、「誰のどの行動を確かめるために必要か」を示し、範囲を変える理由と、追加費用・日程への影響を判断者へ渡します。

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

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

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

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

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

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

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

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

たとえば、月次締めを担当する管理職を対象者にします。そのうえで、仮説は「手動サービスへ実データを提供し、再利用を希望する」と書きます。

つまり、画面機能ではなく、価値と観測行動が先です。

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

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

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

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

複数の問いが結び付いている場合も、制作票では主仮説を一つにします。そして、残りは前提条件か、次の仮説として分離してください。

これは、反応がなかったとき、どの制作判断へ戻るかを明らかにするためです。

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

仮説を絞るときに「今回は作らない」欄も埋めます。ただし、将来必要な機能を否定する欄ではありません。

あくまで、今回の観測に使わない部品を制作範囲から外す欄です。

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

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

実際には、顧客自身が困っていると認識していない問題を、解こうとしていました。

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

ターゲット顧客10社へのヒアリングからMVPを再設計し、BizDev人材が営業を支援。支援開始4ヶ月でパイロット顧客3社を獲得しました。

追加開発費は、当初の追加開発計画の3分の1に抑えられました。既存MVPの500万円を分母にした数字ではありません。顧客課題からMVPを再設計した支援事例

この事例では、機能の追加よりも先に、顧客が対価を払いたい課題を確かめ直しました。制作判断へ応用するなら、既に投じた費用だけで追加開発を決めず、顧客の優先課題と照らして、残す機能・作り直す機能を選びます。

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

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

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

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

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

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

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

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

同調査で、定量的な目標・指標を経営層と合意し、定期的に確認・見直しを行い、継続判断に使えたと回答した人は254名、28.6%（全888名）でした。

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

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

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

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

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

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

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

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

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

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

MVPの形態を仮説から選ぶ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

04　MVPの形を選べない

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

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

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

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

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

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

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

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

架空例：月次締め支援を、手動MVPから作る

複数部門の報告を取りまとめる管理職向けに、月次締め支援を試す架空例です。「入力画面を使いたいか」ではなく、「合意した範囲のデータを提供し、集計結果を受け取り、翌月も依頼するか」を主な問いにします。

以下は説明用の設計で、当社の支援実績ではありません。

一度の無料利用や好意的な感想だけで開発を広げず、再依頼という行動と、現在のやり方より何が良くなったかを確認します。手動MVPで価値を確かめても、有料販売の需要や自動化後の採算は次の検証に残ります。

機密情報が必要なら利用目的と保管・削除を先に合意し、難しい場合は匿名化したデータ等で確認できる範囲を限定します。

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

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

観測できる順に制作する

安全・法務・情報管理の条件は、制作に着手する前に確認します。その前提を満たしたうえで、対象者と提示内容を記録し、顧客が価値を体験できる経路を作ります。

以下は、その順序を整理した例です。

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

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

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

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

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

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

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

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

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

当社が支援した大手製造業では、社内公募で集まった5名の役割が決まらず、3ヶ月間議論が続いていました。顧客開発・技術検証・社内調整などの役割を割り当て直し、不足していた顧客開発のスキルは、期間限定の外部BizDev人材で補いました。

「誰が何をやるかを決めただけで、チームが動き始めた。」

役割を再定義してから2週間で動き始め、3ヶ月で顧客ヒアリング30社と仮説の検証結果報告を完了しました。引用は役割設計に関する本人の振り返りで、実際の支援では外部人材の配置とスキル移転も行っています。

MVP制作そのものではなく、顧客開発とチーム運営の事例です。5名の役割設計と顧客開発支援の事例

この考え方をMVP制作へ応用するなら、部品ごとに「作る人」と「受け取って完了を判断する人」を決めます。例えば、営業資料は営業責任者、計測ログは検証責任者が受け取り、仮実装の廃棄・引継ぎは技術責任者が判断する役割分担です。

これは当研究所による応用例で、上の案件で行った作業の説明ではありません。

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

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

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

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

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

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

完成度の割合ではなく、今回確かめることから品質を決める

MVPの完成度を、すべての案件で共通の割合に換算することはできません。画面の説明だけで確認できる仮説もあれば、実際に使わなければ分からない操作や運用条件もあるためです。

まず、今回の顧客行動を観察できる最小の形を決めます。

機能の数は絞っても、安全・法令・情報管理など、試行に必要な条件は省略しません。未完成の箇所を明示し、利用範囲と中止条件を相手と合意したうえで検証してください。

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

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

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

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

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

制作を終え、次の判断へ引き継ぐ

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

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

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

検証論点を3つに絞り、4回目のPoCで初めて事業化フェーズへのGo承認を得ました。過去3回のPoCには計1年半を要しており、今回は支援開始から約4ヶ月で判断に到達しています。

同じ作業の所要期間を比較した短縮率ではありません。検証設計を見直してGo承認へ進んだ支援事例

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

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

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

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

制作が膨らむ原因は、技術力の不足だけではありません。確かめる仮説、変更の判断者、制作担当、完成を受け取る人が決まっているかを確認します。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

A. MVPで検証する仮説の数に共通の決まりはありません。本稿では制作範囲と結果の解釈を明確にするため、主な問いを一つ選ぶ方法を勧めています。前提条件や副次的な観察は別欄に残します。

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

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

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

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

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

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

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

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