MVPで何を検証するのか ── 確かめたい仮説を、1つに絞って1文で書く

「まずMVPで小さく作って、検証してから本格的にやりたいんです」。新規事業の相談で、よく聞く言葉です。私たちもそのほうがいいと思います。ただ、続けて「何を検証しますか」と聞くと、多くの場合ここで会話が止まります。

「使われるかどうかを確かめたい」。返ってくるのはだいたいこれです。気持ちは分かるのですが、これは仮説ではありません。使われたとして、誰に、何が刺さったのかが分からないままだからです。

MVPが何を作る手法かはMVP開発とは何かに工程として書きました。この記事はその手前、何を確かめるために作るのか、の話です。

「使われるか」は、仮説ではありません

仮説と呼べる形にするには、少なくとも3つの穴が埋まっている必要があると考えています。誰が、どの場面で、何に払うか。この3つです。

「誰が」は、業種や属性ではなく、その人が置かれている状況まで書きます。「中小企業の経営者」ではなく「従業員5人の整体院の院長で、患者が3回目以降に来なくなるのを気にしている人」。ここまで書くと、次に声をかけるべき相手が決まります。

「どの場面で」は、その人がいつ困るかです。月末なのか、来店の翌日なのか、新人が入ったときなのか。場面が決まると、画面を開くきっかけが決まり、通知をいつ出すかまで決まります。

「何に払うか」は、お金とは限りません。月額を払うのか、いまの手作業をやめてこちらに乗り換えるのか、自分の顧客に勧めてくれるのか。払うものが決まると、8週間の後に何を数えればいいかが決まります。

3つとも埋まった1文が、仮説です。埋まっていない穴があるうちは、画面を描いても何を作らないかが決められません。

架空の想定例で、1文にしてみる

ここから先は架空の想定例です。整体院の院長向けに、来店後のセルフケア動画を患者に届けるサービスを考えている、とします。

最初の相談で出てくる説明は、たいていこうです。「院長が動画を登録できて、患者はスマホで見られて、決済もできて、視聴の分析も見られるものを作りたい」。作りたいものの一覧ではあるのですが、仮説ではありません。

3つの穴を埋めると、こうなります。

「患者の再来店が3回目で途切れることを気にしている整体院の院長は、施術の翌日に患者へセルフケア動画を届けるために、月3,000円台の会費を払う」。

これで、声をかける相手が院長に決まります。動画を出す場面が施術の翌日に決まります。数えるものが、会費を払った院長の数に決まります。逆に言うと、この1文には「患者が動画を見て満足するか」は入っていません。それは別の仮説で、今回は確かめないと決めたことになります。

1文にする過程で、何が本当の売り物なのかが入れ替わることもあります。この例でも、書いているうちに「払うのは院長ではなく患者のほうでは」と気づくかもしれません。そうなったら1文を書き直します。画面を描く前に気づけたなら、それがいちばん安い修正です。

検証になるMVPと、検証にならないMVP

仮説が1文になると、画面の選び方が変わります。

検証にならないMVPは、作りたい機能を全部、薄く入れた縮小版です。会員登録、動画一覧、視聴画面、決済、院長の管理画面、視聴の分析。それぞれを簡易版にして8週間に詰める。一見MVPらしいのですが、リリースしたあと院長が申し込まなかったとき、理由が分かりません。動画が足りなかったのか、決済が面倒だったのか、そもそも翌日に届ける価値がなかったのか。全部が薄いので、どれも切り分けられない。

検証になるMVPは、1文に直結する画面だけを厚く作ったものです。さきほどの例なら、院長が動画を登録して患者に送る画面と、患者がスマホで見る画面。この2つの流れが本体です。会費の決済は初期に含めず、請求書を手で送る。視聴の分析はCSVで出して、最初の数ヶ月は手で集計する。

「決済がないなら本番じゃない」と言われることがあります。ですが、院長が請求書を受け取って振り込むなら、それは払う意思の確認として決済画面より強い証拠です。決済を初期に含めていない理由は、審査や規約の手間だけではなく、検証の段階では手作業のほうが証拠として濃いからでもあります。

目安として、8週間で作る画面のうち、1文に直接つながらない画面が半分を超えていたら、それは縮小版になっています。減らす相談をします。

数字は、上の目標より下の線を先に決める

仮説には数字が要ります。ただ、置き方を間違えると、リリース後に何も判断できなくなります。

よくあるのは、上の目標だけを決めることです。「初月で院長50人」。この数字は、達成できなければ「もう少し続ければ届くはず」という理由がいくらでも出てきます。目標は判断の材料になりません。

先に決めておくべきなのは、下の線です。これを下回ったら、いったん止める。「知り合いの院長30人に直接声をかけて、2ヶ月目の時点で会費を払っているのが5人未満なら、この形は続けない」。この線があると、8週間後の打ち合わせで感情ではなく数字で話せます。

数字の大きさそのものは、事業によって違うので私たちには決められません。院長30人に声をかけられる関係があるのか、広告で集めるのかでも変わります。決めるのは発注側です。私たちができるのは、その数字が画面から取れる形になっているかを確かめることです。「2ヶ月目も使っている」を数えるなら、いつ誰が何を開いたかが残る作りにしておく必要があります。これは設計の最初の2週間で決めます。

地味ですが、効きます。

8週間の後、判断する場面

初回リリースのあと、下の線と照らし合わせる打ち合わせを置きます。時期は仮説によって変わりますが、月単位で数える仮説なら2ヶ月目の終わりあたりが多いです。そこで選ぶのは3つのうちどれかです。

続ける。下の線を越えていて、1文の仮説がおおむね当たっていた。この場合は、初期に外していたもの（決済、分析画面）を月額の改善の中で順番に足していきます。

直す。数字は線の近くで、使われ方が想定と違った。院長は動画を送らず、患者が自分で探しに来ていた、というような場合です。1文の「どの場面で」を書き直して、画面の入口を変えます。作った画面の大半は残るので、作り直しではなく修正で済むことが多いです。修正がどこまで月額の枠に収まるかは、開発中に「やっぱりこうしたい」が出たときに線引きを書きました。

やめる。線を下回り、声をかけた院長の反応も薄かった。この判断が出せるのは、下の線を先に決めていた場合だけです。線がないと「もう少し」が続き、そのまま半年が過ぎます。

正直に書いておきます。私たちの契約は開発2ヶ月とリリース後12ヶ月の月額改善契約の組み合わせで、合計14ヶ月の型です。「やめる」と決めたあとの月額の扱いは、契約の前に必ず聞いてください。2ヶ月で検証だけをして、外れたら終わりにしたい方には、この型は重いと思います。その進め方なら、開発だけを一括で請ける会社のほうが収まりがいいかもしれません。

仮説が1つに絞れないときは

「確かめたいことが3つある」という相談もあります。院長が払うか、患者が動画を見るか、来店が増えるか。

そのときの並べ方は、外れたら事業そのものが成り立たなくなる順です。院長が払わなければ、患者が動画を見ても事業にはなりません。だから最初の8週間は「院長が払うか」だけを確かめる。患者の視聴は、その次です。

順番を決めると、画面の順番も決まります。院長側の画面が先で、患者側の画面は最小限。8週間の中で何週目に何をしているかは2ヶ月で作れるもの、作れないものに週ごとに書いています。仮説を1文にする作業は、その最初の2週間の設計の中でやっています。

絞る作業は、発注側にとって痛いものです。作りたかった機能を後回しにするからです。ただ、8週間で3つの仮説を薄く確かめるより、1つを濃く確かめて次に進むほうが、結果的に早く着きます。

相談のときに、持ってきてほしいもの

仕様書は要りません。持ってきてほしいのは、3つの穴を埋めようとした1文と、下の線の数字です。埋まっていなくて構いません。「誰が」は決まっているが「何に払うか」が空欄、という状態で来ていただいたほうが、60分の相談でそこを一緒に埋められます。

相談の前に決めておくと話が早いことは、開発会社に相談する前に、決めておくと話が早い3つのことに書きました。そこにある「成功の判断基準」を、新規事業向けに一段細かくしたのがこの記事の1文と下の線です。

1文が決まれば、3営業日以内に画面構成のラフをお出しします。ラフに並んだ画面のうち、1文に直接つながらないものがあれば、そこで削ります。実際の画面構成の例は作れるものの例にあります。