MVP

一言でいうと

利用者について確かめたい仮説を検証するために、必要最小限の範囲で作って世に出す製品です。

提唱者と登場年

英語版Wikipediaは、この語を2001年にFrank Robinsonが命名して定義し、その後Steve BlankとEric Riesが広めたと記述しています。製品開発のコンサルティングを行うSyncDevは、MVPを、売り手と顧客の双方にとってリスクに対する見返りを最大にする製品と説明しています。

広く知られる定義は、Eric Riesが2009年8月のブログ記事で示したものです。RiesはMVPを「チームが最小の労力で、顧客についての検証済みの学びを最大限に集められる、新しい製品の版」と定義しました。この定義の中心は、製品の小ささではなく、何を学ぶかです。

何を解決するか

MVPは、時間と費用をかけて作り込んだ製品が、市場に出してから誰にも使われないと判明する事態を避けるための手段です。顧客が実際にその課題を抱えているか、その解決策にお金を払うかといった仮説は、作る前の調査だけでは確かめきれません。最小限の製品を実際に使ってもらい、行動の結果から仮説の正否を判断します。

前提として、何を学べば次の判断ができるかを、作る前に決めておく必要があります。検証する仮説と、成功と判断する基準が無いまま出すと、結果を見ても次に何をすべきか決められません。

実際の進み方

最初に、検証したい仮説と、その仮説が正しいと判断する指標を決めます。次に、その指標を測るために最低限必要な機能だけを作ります。場合によっては、裏側を人手で処理し、画面だけを用意する形も取られます。

公開後は利用状況や顧客の反応を測り、仮説が支持されたか否かを判断します。支持されれば範囲を広げ、支持されなければ方向を修正します。作る、測る、学ぶの一巡をできるだけ短くすることが、MVPを使う目的です。

導入でよくある失敗

• 機能を削っただけの未完成品を出し、品質の低さが理由で使われないのか、需要が無いのかを区別できない
• 検証する仮説を決めずに出し、数字を見ても判断ができない
• MVPのつもりで作ったものを作り直さずに拡張し続け、初期の設計の制約を抱え込む

求人票にこの語がある場合に読み取れること

「MVP開発」と書かれた求人は、新規事業や立ち上げ期のプロダクトで、仕様が固まる前から開発に加わる役割だと読み取れます。短い期間で作って捨てる判断を繰り返すため、作り込みよりも速度と仮説検証への関与が求められます。候補者には、MVPで何を検証し、結果を受けて何を作り直したかを確認してください。

隣接手法との違い