素早くリリースし、アイデアを本当に検証できるMVPのスコープ設計方法
シードラウンドを調達し、エンジニアを2名採用し、6か月のランウェイでローンチを目指します。6か月後、洗練されたプロダクトは手元にあるのに、そのラウンドが本来答えを出すはずだったたったひとつの問い——「本当にこれを欲しがる人がいるのか」——への答えはありません。これはアーリーステージのソフトウェア開発で最も一般的で、最も高くつくミスです。基礎を打ち、壁を組み上げ、キッチンまで設置してから、そもそもその土地に住民がいるかを確認するようなものです。
MVPはそれを防ぐためのものです。しかし、私たちが目にする「MVP」の多くは、創業者がすでに頭に描いている完成形プロダクトのミニチュア版に過ぎません。それはMVPではありません。小さなV1であり、1週間の顧客との会話とランディングページ1枚で学べる以上のことは、ほとんど学べません。
MVPは「プロダクト」ではなく「問い」である
「minimum viable product(実用最小限のプロダクト)」というフレーズは、しばしば「可能な限り小さいプロダクト」と誤読されます。そうではありません。MVPとは、他の方法では答えが出せない特定のビジネス上の問いに答えるために、実際のユーザーの前に出せる最小のものです。
問いが「多忙な飲食店オーナーは、在庫照合の自動化に月99ドルを払うか」であれば、MVPはそれを実証あるいは反証するものです。多くの場合それは、手動で運用されるサービス、スプレッドシート、あるいは裏側で人間が実際に作業する粗いWebフォームです。認証・課金・モバイル対応ダッシュボードを備えたフルスタックアプリになることは、ほとんどありません。
定義を書き換えると、作るものが変わります。問いが軸になれば、答えに近づけない機能は削られます。残るスコープは小さく、鋭く、そして守れるものになります。
ランウェイを燃やす4つのスコーピングミス
数十件のMVP案件を通じて、私たちは同じ高くつくパターンを繰り返し目にしてきました。
プロダクトではなく、プラットフォームを作ってしまう。 創業者は、有料ユーザーが1人もいないうちに、管理画面、マルチテナントアーキテクチャ、ロールベースの権限、分析ダッシュボードに何週間も投資します。これらは本物のプロダクトには本当に必要なものです。しかしMVPの段階では、「自分が何を作っているかをすでに理解している」という賭けにすぎません。実際にはそうではありません。あなたは今、それを見つけようとしている最中なのです。
「ローンチに必須」と「問いに答えるために必須」を混同する。 ストアをローンチするにはチェックアウトフローが必要です。しかし、買い手が特定の商品を購入するかどうかをテストするのに必須ではありません。「入荷通知」ボタンと手動での請求書発行だけでも、はるかに低いコストで購入意思を実証できます。
磨き上げてから見せようとする。 実際のユーザーの手に渡った粗いMVPは、誰にも見せていない磨き上げられたデモに勝ります。市場はシグナルを与えてくれますが、社内チームがくれるのは意見に過ぎません。
MVPをプロトタイプと混同する。 プロトタイプは捨てるものです。MVPは薄いけれど本物です。裏側の配管がガムテープでできていたとしても、実際の取引を処理し、実際の価値を届けます。この2つを混同すると、6か月後に後悔する脆弱なコードか、誰も対価を払っていない美しくクリック可能なモックアップのどちらかを手にすることになります。
すべての機能に問う、たったひとつのテスト
機能をMVPのスコープに入れる前に、ひとつだけ問いを立ててください。「これを取り除いても、MVPは私たちが検証しようとしているビジネス上の問いに答えられるか?」答えが「はい」なら、その機能は削ってください。
誠実に適用すれば、このテストは典型的な初期バックログの60〜80%を消し去ります。創業者は、削られた機能ひとつひとつが「負けた賭け」のように感じられて抵抗します。しかし、そうではありません。それは、より良い判断を下せるだけのデータが揃った瞬間まで、判断を先送りしただけの賭けなのです。
5ステップのスコーピング・ロードマップ
本物のMVPをスコープする際に、私たちがクライアントと共に辿る手順は次のとおりです。
1. ビジネス上の問いを1文で書き出す。 プロダクトビジョンではありません。反証可能な問いです。「ホーチミン市の工場マネージャーは、紙の記録に代わるモバイル版ダウンタイム記録アプリに月200ドルを払うか?」は問いです。「ダウンタイム記録プラットフォームを作る」は問いではありません。
2. その問いに答える最小の成果物を特定する。 ある問いにとっては、ランディングページと20件の事前注文で十分です。別の問いには、人間がバックエンドを担う2画面のモバイルアプリが必要になります。フルスタックのソフトウェアプロダクトが必要なケースは、ごくわずかです。
3. 機能リストを下書きし、大胆に削る。 すべての項目に対して、先ほどのたったひとつのテストを適用してください。それ以外はすべて「V1.1」リストに送り、MVPが問いに答えを出した後にのみ見直します。
4. 機能ではなく、時間で厳格な予算を立てる。 誠実にスコープを切れば、ほとんどのMVPは6〜12週間で十分です。計画がそれを超えるなら、スコープが間違っています。ステップ3に戻ってください。
5. 成功と撤退の基準を最初に定義する。 「トライアルユーザーの15%が30日以内に有料へ転換すれば継続する。そうでなければピボットするか停止する。」構築を始める前に書き出したこれらの数字は、後になってサンクコストに引きずられた判断から自分自身を守ってくれます。
実践ではどのように見えるか
ある物流分野のクライアントは、6か月の構築が必要だと確信して私たちのもとに来ました。ドライバーアプリ、配車オペレーター向けWebアプリ、顧客ポータル、そしてルート最適化エンジンです。しかし、彼らのビジネス上の問いは実はもっと狭いものでした。「小規模なトラック運送事業者は、より優れた案件マッチングに月額料金を払うか?」私たちは8週間のMVPをスコープしました。配車オペレーター向けWebアプリを1つ、ネイティブアプリの代わりにドライバー向けのTelegramボット、そして裏側での手動マッチングです。ローンチから10週間後、彼らには40社の有料事業者が付き、モデルが機能するという明確なシグナルを得ていました。フルスタックのプラットフォームはその後に、収益で資金を賄い、創業者の仮説ではなく実利用データに基づいて形作られました。
もう一方の未来は容易に想像できます。6か月の構築、洗練された4パーツからなるプロダクト、そしてそこで初めて、どの仮説が間違っていたかを知ることになるのです。
この規律は積み重なる
MVPを上手くスコープすることは、一度きりの練習ではありません。それは習慣です。この同じ規律が、後に「2週間ごとに機能をリリースするチーム」と「四半期をまるまる使って誰も使わないリリースを出すチーム」を分けます。この規律を早く身につけた創業者は、市場から離れない会社を築きます。そうでない創業者は、アイデアが尽きる前にランウェイが尽きる傾向にあります。
すでに重く感じるスコープ文書を眺めているなら、それこそが「削るべきだ」というシグナルです。どこを削るのが安全か分からないなら、それは経験あるパートナーと話す価値のあるテーマです。MerkTechsでは、ベトナムおよび東南アジア各地のチームが、四半期単位ではなく数週間でリリースできるMVPをスコープするのを支援してきました。そしてより重要なのは、そのMVPがウィッシュリストではなく答えを携えて戻ってくるということです。もしあなたが今その段階にいるなら、私たちはいつでも最初の対話の準備ができています。