「プロトタイプを作る」「MVP を出す」という相談では、まず何を確かめたいかをそろえる必要があります。画面の操作を試すのか、顧客が申し込むかを見るのか。目的が違えば、必要な試作品と作業範囲も変わります。
プロトタイプは試すための形の一つです。MVP は顧客から何を学ぶかを軸に検証物を選ぶ考え方で、プロトタイプを使うこともあります。一方、MVP という語は提唱された時点の定義と現場での使われ方がずれたまま流通しています。出どころまで遡ると、誰が言い出したのかという帰属自体も割れています。
プロトタイプと MVP は、どう重なるのか
プロトタイプは、形や操作を試し、設計上の疑問を確かめるために作ります。社内だけでなく、利用者に見せて反応を確かめることもあります。MVP は、顧客について何を学ぶかを決め、その学びを得られる最小の形を選ぶ考え方です。スケッチやプロトタイプを MVP として試す場合もあれば、動く製品を使う場合もあります。使える機能を一般公開することが、すべての検証の開始条件ではありません。
次の表は排他的な分類ではなく、検証を設計するときの観点です。
| プロトタイプ | MVP | |
|---|---|---|
| 中心になる問い | この形で意図や操作を伝えられるか | この形から顧客について何を学べるか |
| 試す相手 | 関係者や利用者。顧客に見せることもある | 学びを得たい顧客 |
PoC を加えて「作れるか」「使えるか」「売れるか」と並べる説明もあります。ただし、プロトタイプでも利用者に試してもらえます。MVP も、販売や一般公開そのものを合格条件にする言葉ではありません。何を学ぶための検証かを先に決める方が、必要な形を選びやすくなります。
この違いを、社内向けか顧客向けか、捨てるか育てるかだけで固定すると、どちらの検証も設計しにくくなります。
MVP は誰が言い出した言葉なのか
Eric Ries は2009年8月3日、自身のブログで MVP を定義しました。書籍『The Lean Startup』（2011年）より前の発信です。ただし、これを語の初出や造語者の証明にはできません。造語したのは誰かという問いでは説明が割れます。
- ある日本語の解説記事は、スティーブ・ブランクとエリック・リースによる提唱を紹介しています
- 第三者の回顧記事は、Frank Robinson が2001年に造語したと説明します。ただし、造語した年を示す当時の一次資料は、この調査では確認できていません
- 2008年に保存された Product & Market Development Inc. の当事者サイトには、MVP を製品の適切な大きさと投資対リスクで説明するページがあり、会社紹介には Frank Robinson が代表として載っています
2008年の当事者サイトは、MVP を顧客と提供側の双方にとって適切な大きさの製品と説明し、投資対効果をリスクで割る考え方も示しています。したがって、この定義を第三者の回顧だけに頼る必要はありません。一方、2008年の資料から2001年の造語を証明することもできません。
Steve Blank も2012年の自身のブログで、Lean Startup などが生まれる前に Robinson が同じ考え方を実践していたと書いています。これも先行する実践を示す証言で、2001年に語そのものが作られた証明ではありません。
「最小限の製品を作る」は、提唱者側が否定している
Ries の2009年の定義はこうです。最小の労力で、顧客について検証された学びを最大量集められる、新製品のバージョン。中心にあるのは学びであって、機能の少なさではありません。
Ries の組織の公式サイトは、もっと直接的に書いています。MVP はその名前にもかかわらず、最小限の製品を作ることについての話ではない。小さく作った製品という理解は、公式に誤解として否定されています。
それでも語は独り歩きしました。Wikipedia は、MVP の使われ方があいまいになり、プロトタイプに近いものから完全に市場対応した製品まで、広い範囲を指すために使われていると指摘しています。
広めた側の当事者も、このずれを認めています。スケートボードから始めて車に至るあの図を描いた Henrik Kniberg は、2016年1月25日の自身のブログで、MVP という語そのものが混乱と不安の原因になっていると書きました。同じ記事には、顧客の間で MVP が "Minimum Releasable Crap" と揶揄されるという話も出てきます。そのうえで、Earliest Testable Product、Earliest Usable Product、Earliest Lovable Product という言い換えを提案しています。
どこまで作るかは、得たい学びから決める
検証のために作るものは、確かめたい問いに必要な範囲まで絞れます。割り切ったぶん、続けると決まったときに土台として使えないことがあります。どこまで作るかを決める際は、得たい学びと、後で作り直す可能性の両方を見ます。
Nue が提供している AI受託開発 は、2週間という期間を先に固定しています。開始条件は1つだけで、解決したいことが1つ決まっていること。要件書は前提にしません。2週間で出すのは、動いて人に触ってもらえるものです。作り込んだ製品ではなく、確かめたい一点が動けば十分だと考えています。2週間で動くところまで行けるのは、実装の多くをAIコーディングが担っているからです。設計とレビューがどう変わるかはAIコーディングとは何かの記事に書きました。
作るものが決まっていない相談には、プロダクト開発支援の4週間という入口もあります。相談の状態による選択で、プロトタイプからMVPへ進む順番を示すものではありません。
範囲を先に決めてから期間を見積もると、追加したい機能に合わせて期間も延びがちです。Nue の2週間の枠では、まず解決したいことを1つ決めます。候補が複数あるなら、何を先に確かめるか優先順位を付けます。
試したプロトタイプを製品の土台にできるか
使える場合も、作り直す場合もあります。Nue のAI受託開発では、検証後に続けると決めても、作り直した方が早ければそう伝えます。プロトタイプをMVPとして試した場合でも、その形を本開発の土台にできるかは別に判断します。
Nue では、2週間試した末に止めると決めた場合も、成果として扱います。
合格条件は、作る前に決める
何を確認できたら次に進むのかを、作る前に決めます。合格条件を後から決めると、追加する機能が今回の判断に必要か見分けにくくなります。
対象、成功の定義、合格ライン、間違えたときの手順の4点を先に文章にする。この決め方は 生成AIのPoCが本番に行かない理由の記事にまとめました。
作りすぎのサイン
- 確かめたい一点を1文で言えない。 問いが複数あるなら、どの顧客行動や操作を先に見るか決めます
- 機能を足しても、続けるか止めるかの判断は変わらない。 その機能が今回のMVP検証に必要か見直します
- 何ができたら次に進むかが決まっていない。 試す相手と合格条件を決めてから、作る範囲を見積もります
- 作り直す可能性のある試作品を、再利用だけを理由に作り込んでいる。 今回確かめる操作に必要な範囲へ絞れるか確認します
顧客に何を試してもらい、何を確かめるか
仮に予約サービスを作るとします。画面のプロトタイプを利用者に操作してもらえば、希望日時を選ぶときに迷う箇所を確かめられます。予約の需要を知りたいなら、実際に申し込める小さな受付ページを用意し、予約件数を事前に決めた基準と比べます。操作のしやすさだけでは、予約したい人がいるかは分かりません。画面のプロトタイプをMVPとして使うなら、予約を希望する人の行動をどう確かめ、結果をどう判断するかまで決めます。
打ち合わせでプロトタイプやMVPの意味が食い違ったら、呼び方を決める前に、誰に何を見せ、どの操作や行動を確かめるかを具体的にします。結果をどう判断するかまで決めれば、必要な試作品と作る範囲を相談できます。