今日の問い
価値仮説を確かめるために、何を作り、何を今は作りませんか。
30秒でつかむ
MVPは小さい完成品ではなく、最小の労力で最大の検証済み学習を得るための製品版です。小ささだけでなく、何を学ぶかが先にあります。
範囲を守るには、実装する項目だけでなく、今回の対象外を理由付きで書きます。
30秒図解 · LESSON 10
絞り込み図
価値の核まで、意図的に削る
対象外を明記して、検証したい価値だけを残します。
- 可能な全機能
- 今回の対象
- 主要な一場面
- 検証する価値
CLUE · 見抜く手掛かり
なくても仮説を試せるものは何か
TRAP · ありがちな罠
品質まで削って小さく見せる
原則
「まずは全部の基本機能を」と考えると、検証したい仮説がぼやけます。ログイン、通知、設定画面を揃えても、利用者が価値を感じるかは分からないままです。
Eric RiesはMVPを、顧客についての検証済み学習を最小の労力で最大化する版と定義しています。決まった機能数の公式ではなく、状況ごとに判断が必要な実験手段です。
「この版で何を学ぶか」を一文で固定しましょう。その学習に必要な最短の利用経路だけを残します。それ以外は対象外へ移し、外しても検証できる理由を書きます。
たとえば教室比較の価値を確かめるなら、対象は「条件を入力し、3件を比較し、体験予約へ進む」までです。アカウント同期やおすすめ通知は便利でも、この仮説には必須でないかもしれません。一方で、誤情報を見分ける出典表示は、信頼を損なわずに試すため必要です。
対象外は、今回の問いを守る境界線です。次の検証で範囲へ戻して構いません。
MVPを、最小の製品そのものではなく、少ない労力で顧客について学ぶための版として捉える原則を支える。
良い例と惜しい例
機能の縮小と学習範囲の設計
AIへの指示例
目的: 価値提案の最も危険な仮説を確かめるMVP範囲を定義する
制約: 学習に不要なログイン、通知、管理機能を自動追加しない。安全と信頼に必要な条件は削らない
参照: value-proposition.md、experiment-plan.md、success-criteria.md
受入条件: 学習目標、最短の利用経路、対象内、対象外、対象外にする理由を明記する
確認問題
セルフチェック
1. MVPの範囲を決める基準として最も適切なのはどれですか。
最終制作へ反映する
in-out-scope.mdでMVPの境界を固定する
今回学ぶことを一文で書き、最短の利用経路に必要な対象内と、今は作らない対象外を分ける。
Acceptance criteria
- 対象内の各項目が、一つの学習目標に必要な理由を持つ
- 対象外に具体的な項目と、今回外せる理由が記録されている
今日のまとめ
- MVPは最小の労力で検証済み学習を得るための製品版
- 学習目標から対象内と対象外を決めると、機能の膨張を防げる
- 次は、対象内の要件をタスクと受入条件へ落とす