AIでMVPの機能をMust・Laterに分ける方法

MVPのMustは「重要そうな機能」ではなく、検証したい仮説と利用者のCore Jobを成立させるために欠かせない機能です。機能を一つ外したときにも、想定利用者が目的を達成でき、仮説を確かめる観察結果が得られるなら、その機能はLater候補です。反対に、利用者が完了できなくなる、または検証対象を測れなくなるならMustに残します。セキュリティ、プライバシー、権限、データ保護などの前提条件は、便利機能と同じ優先順位で切り捨てません。

最初に決めるのは機能一覧ではなく、誰がどの状況で何を終えられるようにするか、そして今回どの仮説を検証するかです。Must / Laterは一般的な機能価値の順位ではありません。対象ユーザー、検証条件、代替手段が変われば判定も変わります。

MVP Scope Matrix

表は横にスクロールできます

区分	今回の扱い	判定の問い
Must	検証に必要な最小の体験を作る	これを外すとCore Jobか仮説検証が成立しないか
Later	手動・既存手段で代替し、学習後に再判断	外してもJobを完了でき、今回の観察を続けられるか
Out of scope	今回は作らない	今回の仮説にもCore Jobにも必要ないか
Guardrail	実装前に満たす条件	安全性・権限・データ保護などの前提を満たすか

検証する仮説とCore Jobを一文にする

たとえば「小規模イベントの主催者は、参加者が開催情報を見つけて申し込めるページがあれば、既存の案内方法より申込手順を完了しやすいと感じる」という仮説を置きます。これは架空例です。実際の対象者や効果を確認した結果ではありません。

次に、利用者の開始状態と完了状態を書きます。「開催情報を知っている」から「必要事項を入力し、申込受付の結果を確認できる」までのように、画面数ではなくJobの終点を示します。仮説を検証するために何を観察するかも決めます。操作を最後まで終えたか、どこで止まったか、入力の質問が残ったかなど、記録できる事実にします。基準値や目標値がまだないなら、数字を作らず「初回テストで記録し、次回に比較基準を決める」と残します。

仮説とJobが曖昧なまま機能を分類すると、要望の強さや実装の見栄えがMust判定を左右します。依頼者が望む機能、実際に解消したい困りごと、検証に必要な情報を分けてください。仮説が複数ある場合は、一度に全部を試すのではなく、今回のMVPが答える問いを一つに絞る方が結果を解釈しやすくなります。

機能ごとの判定を記録する

表は横にスクロールできます

機能候補	仮説との関係	Job完了への必要性	外した場合の代替	観察できる結果	暫定判定
開催情報の表示	情報を見つけられるか	申込判断の前提	なし	内容を理解し次へ進めるか	Must候補
申込内容の入力	申込を完了できるか	完了に必要	口頭受付等が実際に使えるなら比較	入力から受付まで完了するか	Must候補
受付結果の表示	申込が受理されたか	結果確認の一部	運営から別手段で通知できるか	利用者が次の状態を理解するか	条件付き
おすすめイベント	申込体験の仮説に直結するか	初回Jobに必須とは限らない	一覧を手動で確認	今回の仮説と無関係なら観察不要	Later候補

この表は判断を揃えるための作業票です。機能名だけでMustを決めず、代替手段が本当に使えるか、利用者に余計な手間や誤解を押し付けないかを確認します。「あとで手動対応」は、担当者・方法・利用者への案内が決まって初めて現実的な代替です。代替が実行できないのにLaterへ移すと、Job自体が途中で止まります。

Mustの根拠は「仮説の測定」と「Job完了」を分けて書きます。ある機能はJob完了に必要でも、仮説の測定には不要かもしれません。逆に、Job完了に直接見えない計測項目でも、仮説を判断する観察に必要な場合があります。その場合も、取得する情報の必要性、利用者への説明、保存範囲を確認し、計測を目的化しないでください。

架空例：イベント申込MVP

参加者が開催日・場所・対象を確認し、申込を送って受付状態を知ることをCore Jobとします。開催情報、必要事項の入力、送信結果の表示はMust候補です。参加者の好みによる推薦、複数イベントの比較保存、運営ダッシュボードの細かな分析は、初回の仮説に必要か、既存手段で代替できるかを見てLater候補にできます。

ただし、申込が送信されたのに受付結果が表示されない設計では、利用者が二重送信したり運営へ問い合わせたりする可能性があります。結果表示を単なる装飾としてLaterに分類する前に、失敗時・通信中・受付済みの状態を含めてJobが閉じるかを確認します。参加者情報を扱う場合の収集範囲やアクセス制御も、機能価値の点数で後回しにするのではなく、開始前に満たす条件としてレビューします。

機能を一つ外したときに、どの画面や操作がなくなり、代わりに誰が何をするかを記録します。利用者の完了条件が変わるなら、機能削減ではなくCore Jobや検証仮説の変更かもしれません。仮説が変わるなら、分類表の判定も更新し、古いMust / Laterをそのまま引き継がないでください。

Promptの例

「次の機能候補を、利用者、利用状況、Core Job、今回検証する仮説に照らして整理してください。各候補について、Job完了に必要か、仮説を測るために必要か、外した場合の代替と担当、観察できる結果、依存関係、未確認事項を別々に示してください。Must・Later・Out of scopeの案と、その根拠を提示してください。セキュリティ、プライバシー、権限、データ保護などの前提条件は便利機能と同じ点数で比較せず、別のレビュー項目として抽出してください。仮説や利用者条件に書かれていない効果、目標値、法的要件は推測しないでください。判断できない項目は質問として残し、最終決定は担当者が行います。」

AIの出力は分類のたたき台です。Mustの理由が抽象的な「重要」「あると便利」だけなら、その機能を外したときの利用者の状態と仮説への影響を説明させます。提案が具体的でも、実際の利用者の要望や技術的な制約が確認されたことにはなりません。

優先順位を点数だけで決めない

Impact、工数、リスクを簡易スコアへ置く方法はありますが、数値だけで結論を自動化しません。見積もりの幅が大きい、依存先が不明、利用者の前提が未確認といった不確実性は、点数に埋めず別欄に残します。高い効果の仮説でも、成立条件が確認できていなければ「Must確定」ではなく「追加確認が必要」です。

機能の依存関係も見ます。単独では不要でも、別のMustを成立させる入力・権限・データ構造があるかもしれません。反対に、ある機能を追加すると運用、サポート、監査、データ移行が必要になり、実装本体より広い範囲へ影響することもあります。機能表には直接の画面だけでなく、利用者の操作、運用担当、失敗時の復旧まで含めてください。

失敗時の切り分け

表は横にスクロールできます

症状	見落とし	次の確認
Mustが多すぎる	仮説と要望が混ざっている	今回判断したい仮説を一つに絞る
すべてLaterにできる	Core Jobの終点がない	利用者が何を終えれば成功か定義する
削ったら使えない	代替手段を実行可能と確認していない	担当・方法・利用者への案内を確定する
点数の高い機能が採用された	前提や依存を無視した	Guardrailと依存関係を独立レビューする
リリース後に仮説を測れない	観察方法が機能要件にない	何を誰がどう記録するか確認する
利用者へ結果が伝わらない	失敗・完了状態の設計不足	Jobの開始から終了までを再点検する
実装後にScopeが膨らむ	変更管理の境界がない	新要望を次の仮説として分ける

レビューでは、Must候補だけでなくLaterにした機能も読み返します。Laterに残すことで、誰のどんな負担が増えるかを書き、許容できる理由を確認してください。利用者に重大な不利益や情報リスクがあるなら、便利機能より後に送る判断は成立しません。反対に、今回の仮説と無関係な磨き込みを後回しにするのは、MVPの範囲を明確にする判断です。

実装後は仮説ごとに結果を記録する

MVPを作った後に、当初の仮説、対象ユーザー、実施条件、観察方法を再確認します。観察記録には、実際に見た結果と解釈を分けて残してください。「利用者が途中で止まった」は観察、「説明文が原因だ」は仮説です。原因を確認せずに機能を追加すると、違う問題へ対処することがあります。

Mustを実装しても利用者がJobを終えられなかった場合は、何が不足したかを操作の順で見ます。Later機能が必要だった可能性もありますが、入力、説明、権限、処理状態、代替手段の案内など別の原因もあります。結果が仮説を支持しなかった場合も失敗と決めつけず、対象ユーザーや前提が適切だったかを次の検証課題に分けます。測定方法や対象が変わった場合は、前回との単純比較を避けます。

Next Action

まず、今回のMVPで答えたい仮説を一文にし、その対象ユーザーとCore Jobの完了状態を書きます。機能候補を一つずつ表へ置き、削除影響と代替手段を確認してください。曖昧なMustは質問待ち、権限・安全性・データ保護の論点はGuardrailとして分けます。分類を関係者と合意した後、MustだけでJobを最後まで試せるかを架空入力または安全なテストデータで確認します。

AIものさしの判断

Mustは「最初の版に入れたい機能」ではなく、「今回の仮説を確かめながらCore Jobを完了するために外せない要素」です。Laterへ移す前に、代替手段と利用者への影響を確認します。安全性や権限の前提を機能の便利さと点数で競わせず、未確認の効果や基準値を作らないこと。仮説、判定理由、未確認事項、次の観察を同じ表に残せば、後からMust / Laterを見直すときも判断の経緯を追えます。