MVPで検証すべき仮説の立て方

「とりあえず小さく作る」はMVPではありません。何を確かめたいかを先に決めることが、MVPの設計と評価の基準になります。仮説の立て方を整理します。

仮説なきMVPは方向感のない開発になる

MVPを作ること自体が目的になってしまうと、「小さいシステムをリリースした」という事実だけが残り、何がわかったかが曖昧なまま終わります。

フィードバックが集まっても、「それが課題なのか、それとも仮説の設定が間違っていたのか」が判断できません。改善の方向が定まらず、なんとなく機能を追加し続ける状態になりやすいです。

仮説は、「このMVPを動かせば〇〇が確認できるはず」という形で立てます。

例として、受注管理システムのMVPを作る場合：

仮説の例

これらが仮説として立っていれば、MVPを動かした後に「実際にどうだったか」を確認する基準になります。

仮説を立てるときに必要な要素は3つです。

誰が：仮説の対象となるユーザーや担当者を特定します。「現場の入力担当者」「管理職の承認者」「月次集計を行う経理担当」など、役割によって確認したいことが変わります。

何をすることで：MVPが提供する機能・体験を具体的にします。「受注データを入力する」「一覧から検索する」「承認操作を行う」など。

どうなるはず：期待する変化や結果を定量・定性の両面で表現します。「確認連絡が減る」「入力ミスが減る」「操作に迷わない」など。

MVPで確認したい仮説が複数出てきた場合は、優先順位をつけます。

「このMVPで最も確かめたいことは何か」を一つ選ぶと、スコープの判断が明確になります。最重要の仮説を検証するために必要な機能がMVPの最小スコープになります。

優先順位が低い仮説は、次のフェーズで確認する対象として記録しておきます。

MVPを動かした後、仮説に対して「正しかったか・外れていたか」を評価します。

「外れた」という結果も価値があります。フルスケールで作り込む前に外れを発見できたことが、MVPを作った意味です。