開発・新規事業
MVP開発で何を作る？最初の機能を絞るための判断基準
MVPの機能は、最初に確かめたい仮説から選びます。検証に必要な機能、手作業で補う機能、後回しにする機能の分け方を解説します。
資料確認・原稿更新：
新しいサービスを考えると、登録、検索、通知、決済、分析など、必要そうな機能が次々に出てきます。その一覧から単純に数を減らすだけでは、価値を確かめるために大切な機能まで削ってしまうことがあります。
MVPの機能を決めるときは、最初に「この開発で何が分かれば、次へ進めるか」を明確にします。
1. 確かめたい仮説を一つの文にする
「便利な予約サービスを作る」では、何を検証するかが曖昧です。「電話で日程調整している担当者が、空き時間を提示できると調整の往復を減らせる」のように、誰のどの場面を変えたいかを書きます。
リーン・スタートアップの方法論では、MVPを学習の過程を始めるためのものと位置づけています。ここからNicoが重視するのは、開発範囲と確認したいことを対応させる考え方です。参考：The Lean Startup — Methodology
2. 「価値を試すために必要か」で分ける
次は予約サービスを想定した例で、実際の受託事例ではありません。
- 検証に必要仮説を確かめる機能
- 手作業で補う最初は人が代わりに行う
- 後回し検証後に判断する
本文の考え方を整理した説明図です。
| 分類 | 機能・作業の例 | 判断理由 |
|---|---|---|
| 初回に必要 | 候補日時の提示、回答、予約結果の確認 | 調整の往復が減るか確かめるため |
| 手作業で補う | 少人数の利用者登録、導入時の説明 | 小規模な検証では運営が対応できるため |
| 検証後に考える | 複雑な組織管理、高度な分析画面 | 中核となる価値の確認には直結しないため |
手作業で補う場合も、運営にかかった時間を残します。人の支援があって成立した体験を、そのまま自動運用でも成立すると判断しないためです。
3. 小さくしても必要な品質を確認する
機能を絞ることと、利用者に必要な配慮を省くことは別の判断です。扱う情報、利用範囲、誤操作時の影響を確認し、アクセス制御やデータの扱いなど、検証に必要な条件を決めます。
試作品を見せるだけなのか、実際の業務で使ってもらうのかでも、必要な準備は変わります。
4. 完成前に、次の判断を決めておく
見るのは登録数だけではありません。中心となる操作を完了できたか、どこで迷ったか、もう一度使う場面があるかを確かめます。対象者や検証期間に合わせて、継続・変更・見送りの条件を事前に置きます。
最初の整理には、次の項目を使えます。
- 対象となる利用者と利用場面
- 確かめたい仮説
- 仮説を試すために必要な体験
- 今回作る機能と、運営が補う作業
- 観察・計測する項目
- 検証後に判断すること
Nicoでは、構想から必要最小限の開発範囲を整理し、試作と検証につなげます。