アプリ開発のMVPは、機能を雑に減らした完成品ではありません。
失敗すると企画全体が崩れる仮説を、最小の時間と機能で確かめるための実験です。
先に「誰のどの行動を、何の数字で確かめるか」を決めると、必要機能と後回しにする機能を分けられます。
検証後に外注、内製、学習のどこへ進むか迷う場合は、アプリ開発の目的別相談ガイドで次の選択肢を整理できます。
| 最初に決める項目 | 決定内容 |
|---|---|
| 危険な仮説 | 外れたら企画が成立しない前提 |
| 成功の証拠 | 観察できる行動と判定値 |
| 実装上限 | 証拠を得るために必要な機能だけ |
まだ題材が定まっていない場合は、初心者向けのアプリ題材の選び方で解決したい場面を一つに絞ってからMVPを設計してください。
MVPは最小の製品ではなく最小の検証である
MVPの境界は、画面数ではなく検証したい不確実性で決まります。
GOV.UKのアルファ段階ガイドは、全体を作るのではなく最も危険な仮定を試せるだけの複雑さに留める考え方を示しています。
実験で捨てる可能性が高いコードへ、通知設定の細かな装飾や多段階の権限管理まで先払いする必要はありません。
一方、動作不良を「最小」と呼ぶことはできません。
GOV.UKのプロトタイプ作成ガイドは、紙のスケッチから動くコードまで目的に合う試作品を選び、利用者と検証することを勧めています。
押せないボタンや保存できない入力では、価値の有無と単なる不具合を区別できないためです。
最初に検証する仮説を点数で選ぶ
思いついた仮説を「不確実性」と「外れたときの影響」で採点します。
どちらも一から五までとし、二つを掛けた値が大きいものから試します。
| 仮説 | 不確実性 | 影響 | 優先点 | 最初の検証方法 |
|---|---|---|---|---|
| 対象者は週三回以上この作業をする | 3 | 5 | 15 | 五人への行動インタビュー |
| 通知があれば入力を完了する | 4 | 4 | 16 | 通知付き試作品の一週間利用 |
| 月額課金を受け入れる | 5 | 5 | 25 | 価格を示した申込意向テスト |
この例では、支払い仮説が外れたときの影響が最も大きいため、精巧な画面を作る前に価格提示への反応を確かめます。
ただし、申込ボタンのクリックを実際の課金継続と同一視せず、次の検証へ進むための弱い証拠として扱います。
検証条件からMVPの機能境界を引く
機能一覧を作る前に、観察したい行動を一文で書きます。
「対象者が月曜日から金曜日まで通知を受け、五日中三日以上記録する」のように、対象、期間、行動、判定値を含めます。
| 検証したい仮説 | MVPに入れる機能 | 観察する証拠 | 入れない機能 |
|---|---|---|---|
| 毎朝の服薬記録を忘れる人が通知を使う | 時刻設定、通知、完了記録 | 通知後の記録完了率 | 家族共有、分析グラフ |
| 写真から在庫を記録したい店がある | 撮影、品名入力、一覧 | 一週間の継続記録数 | 自動認識、会計連携 |
| 通勤中に三分の復習を続けられる | 問題表示、回答、履歴 | 翌週の再訪率 | 対戦、ランキング |
- 利用者が開始するきっかけを一つ決める
- 価値が届くまでの最短経路だけを残す
- 結果を測るイベントを実装する
- 失敗時に利用者を守る最低限の処理を加える
- 検証に関係しない設定と装飾を後回しにする
GOV.UKのアルファ段階のユーザー調査は、想定利用者と複数の案や試作品を確かめ、目的達成に役立つかを学ぶことを重視しています。
作った人だけで操作確認を終えると、説明を知っている人にしか通じない導線が残ります。
二週間のMVP検証を組み立てる計算例
ここでの時間は相場ではなく、一人が平日に四時間ずつ使えるという仮定です。
十日間で使える四十時間を、証拠が得られる順に配分します。
| 作業 | 時間 | 成果物 |
|---|---|---|
| 仮説と判定基準の固定 | 4時間 | 一枚の実験計画 |
| 画面と計測の実装 | 18時間 | 操作可能な最短経路 |
| 不具合確認と配布準備 | 6時間 | テスト記録 |
| 五人への利用テスト | 7.5時間 | 一人90分の観察記録 |
| 集計と次の判断 | 4.5時間 | 継続、修正、中止の決定 |
機能実装へ三十時間を使って調査を二時間に縮めると、MVPは小さな製品になっても検証装置として弱くなります。
判定基準と観察時間を先に確保し、残りを実装上限にする順番が安全です。
数字と観察を組み合わせて次の行動を決める
一つの割合だけで採用を決めず、完了率と途中で止まった理由を一緒に見ます。
GOV.UKの成功指標ガイドも、サービスが問題を解けているかを示す指標を定め、利用者調査と組み合わせて改善判断に使う考え方を示しています。
| 結果 | 解釈 | 次の行動 |
|---|---|---|
| 完了率が高く、同じ価値を語る | 中核仮説を支持する証拠がある | 次に継続性か支払いを検証する |
| 完了率が低く、操作で迷う | 価値より導線の問題が大きい | 操作を直して同じ仮説を再検証する |
| 完了率が高いが再利用しない | 一度の便利さはあるが習慣価値が弱い | 利用頻度の前提を見直す |
| 対象者が問題を経験していない | 課題仮説そのものが弱い | 対象者か企画を変更する |
失敗結果は開発の失敗ではなく、大きな投資を避けるために早く得た情報です。
記録には都合のよい意見だけでなく、離脱箇所、発言、操作時間、想定外の使い方を残します。
MVPを公開版へ進める前に品質条件を切り替える
限定的な検証版とストア公開版は、同じ合格条件ではありません。
AppleのApp Review Guidelinesは提出物の完成性、実機試験、十分な機能性を求めています。
Google Playの機能性ポリシーも、クラッシュせず意味のある機能を持つことを公開アプリへ求めています。
検証が通った後は、セキュリティ、アクセシビリティ、障害対応、問い合わせ、プライバシー表示を公開条件として追加します。
MVPで省いた項目を忘れないように、実験用の除外一覧と公開前の必須一覧を分けて残してください。
アプリ開発のMVPでよくある質問
MVPは何画面あれば成立しますか？
画面数の共通正解はなく、検証したい仮説を観察できる最短経路で決まります。
GOV.UKのアルファ段階ガイドも、取引全体ではなく難しい部分へ絞り、危険な仮定を試せる最低限を作る考え方を示しています。
一画面でも行動と判定値を取得できれば成立し、五画面あっても何を確かめるか不明ならMVPとはいえません。
MVPは無料で配らないと検証できませんか？
無料である必要はなく、価格受容が重要な仮説なら金額を示すこと自体が検証になります。
ただし、Appleの審査ガイドラインが示す課金と提出の条件を満たす前に、実際の購入だと誤認させる操作を公開してはいけません。
事前登録、価格付きの説明、契約を伴わない面談など、段階に合う方法を選びます。
MVPの成功率は何％を目標にすべきですか？
一律の成功率はなく、既存の行動、対象人数、失敗時の損失に合わせて開始前に決めます。
GOV.UKのパフォーマンス測定ガイドは、目的に合う指標をプロジェクト初期から定め、得たデータを改善の優先順位へ使うよう案内しています。
小人数の初回テストでは割合だけを一般化せず、何人中何人かと観察理由を併記してください。
最小機能より最小の学びを設計する
MVPで守るべきなのは機能数の少なさではなく、次の投資判断に使える証拠です。
- MVPの優先対象は、不確実性と外れた場合の影響を掛けた点が大きい仮説です。
- 検証条件は、対象、期間、行動、判定値の四要素で構成します。
- 最小機能には、価値が届く経路と結果を測る仕組みが必要です。
- 継続、修正、中止の判断には、数字と利用者の観察理由を併用します。
- ストア公開版では、検証版で省いた品質と運用の条件を追加します。
機能境界を画面の流れへ落とすときは、アプリ開発のフローチャート作成法を使うと、正常経路と例外経路を実装前に整理できます。
