MVPとは？最初のアプリで機能を絞る方法と、外れたときの扱い

「このアプリは使われるか」では広すぎます。「距離を選ぶだけで、走りたい周回コースを見つけられるか」のように、行動と価値が分かる質問へします。

質問が広いと、結果が出ても読めません。使われなかったとき、機能が足りないのか、そもそも要らないのか、知られていないのかが区別できないからです。

狭くするコツは、利用者が取る行動を一つ入れることでした。「選ぶ」「送る」「記録する」。行動が入っていれば、それが起きたかどうかで判定できます。

⚠️ 質問は、作り始める前に書いてください。作ったあとに立てると、できたものに合わせた質問になります。それでは何も確かめられません。

質問が一つに絞れているかは、答えが「はい／いいえ」で返るかで分かります。「どう思われるか」では測れません。行動が起きたか起きなかったかで判定できる形にします。

質問を書いておくと、作っている最中の判断にも使えます。新しい機能を思いついたとき、この質問に答えるために要るかどうかで決められます。要らないなら後回しの箱へ入れて、手を止めずに済みます。

思いついた機能を、必須・後回し・作らないの3つに分けます。判断の基準は一つで、その機能が無いと仮説を試せないかです。

「あると便利」は必須ではありません。便利かどうかではなく、試せるかどうかで切ります。ここを曖昧にすると、全部が必須に見えます。

⚠️ 「作らない」の箱を必ず作ってください。後回しと作らないを分けないと、すべてが「いつかやる」になります。対象外だと決めたものは、そう書いておくほうがあとで迷いません。

分けるときは、必須の箱から埋めないほうがうまくいきました。先に「作らない」を決めると、残りが自然に絞られます。必須から埋めると、全部が入ります。

箱に入れたあと、必須が5つ以上あるなら質問が広すぎます。前の節に戻って、質問のほうを狭くしてください。機能を削る作業に見えて、実は質問を削る作業です。

MVPで一番やってはいけないのが、機能をどれも半分ずつ作ることです。入口はあるが結果が出ない、結果は出るが保存できない。これでは仮説が試せません。

一往復だけを最後まで通します。入力して、結果が出て、価値が届く。ここが通っていれば、他の機能が無くても確かめられます。

3番目を入れているのは、失敗する場面のほうが多いからです。候補が0件、通信が切れた、権限が無い。ここで止まると、利用者は仮説を試す前に離れます。

完了条件の書き方はアプリの仕様書は何を書けばいい？個人開発で使う九つの項目にまとめました。操作で書くと、通ったかどうかが決まります。

一往復が通ったら、そこで一度止めて出す判断もできます。他の機能は、反応を見てから決めればよい。作り続けているうちは、仮説を試せていません。

「価値が届く瞬間」は、利用者が何かを得た時点で置きます。結果が画面に出た、相手に送れた、記録が残った。作る側の作業が終わった時点ではありません。

一往復に入れるかどうかで迷ったら、それを抜いて成立するかを考えます。保存機能を抜いても価値が届くなら、初回は無くても試せます。抜くと何も起きないなら必須です。

1. 01　開始地点を決める。何から始めるか

   利用者が何を入力・選択して始めるかを決めます。

2. 02　価値が届く瞬間を一つに決める

   結果を見る、相手へ送る、記録できるなど、成功状態を一つにします。

3. 03　失敗しても次の行動が分かる形に

   空データ、通信失敗、権限拒否でも次の行動が分かるようにします。

MVPを出して、思ったように使われないことがあります。というより、そのほうが多いと思います。ここでどう動くかで、次の版が変わります。

やりがちなのが、すぐ機能を足すことです。足りないから使われないのだろう、と考える。ただ、仮説が外れているなら、機能を足しても結果は変わりません。

私は返信アプリを公開して、9日間で利用者が0人でした。感覚では使われるはずだと思っていたので、そこで同じ領域のアプリを118本調べました。分かったのは、想定していた差が差になっていなかったことです。機能を足しても順番は変わらない状態でした。経緯は公開9日で利用者0人。118本を調べて、返信AIが選ばれにくい理由を見直したに書いています。

このとき効いたのは、何を中心に置くかから見直したことでした。機能の追加ではなく、仮説そのものを置き換えています。

見る順番を決めておくと動きやすいです。届いていないのか、使われていないのか、使われたが価値が無かったのか。この3つは対処がまったく違います。届いていないなら知らせ方の問題で、機能とは関係がありません。

⚠️ 外れたこと自体は失敗ではありません。確かめるために作った版なので、答えが出たということです。困るのは、答えが読めない作り方をしていたときのほうです。

3つを見分けるには、それぞれ別の情報が要ります。届いているかは表示回数、使われているかは起動や操作、価値があったかは継続。どれも見ていないと、機能の話に戻ってしまいます。

見る順番を間違えると、直す場所も間違えます。届いていないのに機能を足すのが典型で、私もそこで時間を使いました。

反応が少ないときに、見る数字を増やしたくなるのも要注意です。細かく測っても、仮説が外れていることは分かりません。測る前に、3つのどれなのかを先に考えるほうが早いです。

後回しにした機能は、忘れないためではなく、なぜ今は作らないかを記録します。理由が残っていないと、あとで見たときに「やり忘れ」に見えます。

利用者の反応で前提が変わったとき、追加するか改めて判断できます。前提が変わったのに、当時の理由のまま放置するほうが問題です。

「作らない」に入れたものも同じです。対象外だと決めた理由を書いておけば、似た要望が来たときに同じ判断ができます。私は企画の台帳に、書けない理由を書いた行をそのまま残しています。

削った理由を残しておくと、説明する材料にもなります。なぜこの機能が無いのかと聞かれたとき、決めた理由があれば答えられます。

失敗や却下をそのつど記録へ変える考え方は個人開発で失敗を記録する六項目。却下と障害から残した形式にまとめました。削った判断も、同じ種類の記録です。

記録の形式は問いません。⚠️ ただし、会話の中に残さないことだけ決めています。やり取りの中に埋もれると、数週間後には探せません。

後回しにした機能を、期限つきにしないほうがよいと思います。「次の版で」と書くと、前提が変わっても入れることになります。条件のほうを書いておくと、判断がやり直せます。

MVPとは何ですか？

最初に確かめたい仮説を一つ決めて、それを試すために必要な流れだけを完成させた版です。思いついた機能を少しずつ入れた小型版ではありません。ここを取り違えると、どの機能も中途半端な版ができます。

どこまで機能を削ればいいですか？

その機能が無いと仮説を試せないかで切ってください。「あると便利」は必須ではありません。便利かどうかではなく、試せるかどうかです。ここを曖昧にすると、全部が必須に見えます。

機能を削ると魅力が無くなりませんか？

⚠️ 機能をどれも半分ずつ作るほうが危ないです。入口はあるが結果が出ない、結果は出るが保存できない。これでは仮説が試せません。一往復だけを最後まで通すほうが、確かめられます。

エラー処理も最初から作りますか？

失敗する場面のほうが多いので、次の行動が分かる形にはしておきます。候補が0件、通信が切れた、権限が無い。ここで止まると、利用者は仮説を試す前に離れます。丁寧な作り込みは後回しで構いません。

出してみて使われなかったらどうしますか？

すぐ機能を足さないでください。仮説が外れているなら、足しても結果は変わりません。届いていないのか、使われていないのか、使われたが価値が無かったのか。この3つは対処がまったく違います。

削った機能はどう管理しますか？

なぜ今は作らないかを一緒に書いてください。理由が無いと、あとで見たときに「やり忘れ」に見えます。前提が変わったときに、追加するか改めて判断できる形にしておくのが目的です。

必須の機能が多くなってしまいます。

質問が広すぎる可能性があります。機能を削る前に、確かめたい質問のほうを狭くしてください。必須が5つ以上あるなら、たぶん2つ以上のことを同時に確かめようとしています。

MVPはどのくらいの期間で作るべきですか？

期間では決められません。作るものによって変わります。ただ、作っているあいだは仮説を試せていないので、短いほうが答えを早く受け取れるのは確かです。

MVPを出したあと、次は何をしますか？

質問に答えが出たかを見ます。出ていれば次の質問へ、出ていなければ測り方を直します。答えが読めない状態で次の機能へ進むと、何を確かめているのか分からないまま作り続けることになります。

⚠️ この記事は、MVPを出せば利用者が増えることを保証するものではありません。私自身、出して9日間で利用者0人という結果を受け取っています。MVPは当てるための方法ではなく、早く答えを受け取るための方法です。

また、どのくらいの期間で作るべきかも書いていません。作るものによって変わるためです。

覚えておくと使えるのは、質問を先に書くという1点です。作ったあとに立てた質問は、できたものに合わせた形になります。それでは何も確かめられません。

作った量ではなく、答えを受け取れる形になっているかで判断してください。そこだけが MVP の条件です。