MVPの範囲を定める方法：最初の開発を本当に重要なものだけに絞り込む

アプリのアイデアを持って私たちのところへ来る人のほとんどは、すでにその完全版を頭の中で作り上げています。ダッシュボード、設定ページ、紹介プログラム、ダークモードまで説明できます。けれども普通は、その絵のどの一部分が動けば全体を取り組む価値あるものにするのか、を語れません。MVPの範囲を定めるとは、その一部分を見つけ出し、残りを後回しにする勇気を持つという、地味で少し痛みを伴う作業です。

私は多くの最初の製品が作られるのを見てきましたが、苦戦するものがチームの怠慢で失敗することはほとんどありません。失敗するのは、最初の週から範囲が間違っていたからです。バージョン1に詰め込みすぎ、誰かが何かを学ぶ前に予算が尽き、ローンチの頃にはチームはスタートラインに立つだけで全てを使い果たしています。実際のユーザーが何をしたかに反応する資金は残っていません。

ですからこれは、コードを一行でも書く前に私が人々に渡すガイドです。アジャイルの儀式や派手なフレームワークの話ではありません。ただ一つの正直な問い——このアイデアが本物かどうかを教えてくれる、作れる最小のものは何か？——と、「もう一つだけ機能を」という誘惑が忍び寄るたびにそれに答え続ける規律の話です。その誘惑は必ず忍び寄ってきますから。

MVPとは実際に何か（そして何でないか）

この言葉は使われすぎてすり減っているので、正確にしましょう。実用最小限の製品（MVP）とは、実際のユーザーに本当の価値を届け、スライド資料からは学べなかったことを教えてくれる、アイデアの最小版です。皆が忘れる肝心の語は実用です。たとえ一つのことしかしなくても、誰かにとって最初から最後まで本当に機能しなければなりません。

MVPが何でないかはこうです。あちこち壊れた、完成品の中途半端版ではありません。捨てるためのプロトタイプでもありません。そして確実に「安い版」でもありません——安さは良い範囲設定の副産物であって、目的ではありません。目的は学ぶことです。最も高くつく問いに答えるために、できる限り少ないお金を使うのです。すなわち、誰かがこれを使うのか、そして私が思う通りに使うのか？

この区別は聞こえる以上に重要です。「最初の20%」という発想は、あらゆる方向で壊れ、どこにも役立たないものを生みます。「一つのことを、きちんと」は、人が手に取り、実際に使い、意見を持てるものを生みます。意見こそが全てです。沈黙の上では反復できません。

作りすぎの罠、そしてなぜこんなにも陥りやすいのか

誰も範囲を広げすぎようとはしません。それは妥当な判断を一つずつ積み重ねるうちに起こります。もちろんアカウントが要るからとログインを足す。アカウントにはパスワード再設定フロー、メール認証、設定ページが伴う。設定はプロフィールを意味し、それは画像アップロードを、それは保存場所を意味する。各ステップはそれ単体では理にかなっています。積み重なると、アイデアを特別にする部分がまだ始まってもいないのに、二か月と予算の大半を使っているのです。

罠のもう半分は感情的なものです。機能を削るのは、アイデアが小さいと認めるように感じます。そうではありません——どの機能が重要かまだ分からないと認めているだけで、それは単に事実です。ユーザーがいないうちに作る機能はすべて目隠しで置いた賭けです。それらの賭けの一部は外れますが、MVPから削ったものは、決して置かなかったがゆえに、外れても最も安く済む賭けです。

MVPが果たすべき唯一の仕事を見つける

どんな製品も、最終的にどれほど大きくなろうと、コアループ——価値を生み出すためにユーザーが繰り返す単一の連なり——を持っています。予約アプリなら空き枠を見つけ、予約し、リマインドを受ける。マーケットプレイスなら物を出品し、誰かが見つけ、お金が動く。社内ツールならデータを一度入力し、どこでも使う。製品の他のすべては、このループを支え、飾り、拡張するために存在します。あなたのMVPはそのループです。ループだけです。

自分のものを見つけるには、この文を声に出して完成させてください。「ユーザーは ______ するために私の製品に来て、______ なら満足する。」 最初の空欄が仕事です。二つ目は、それがうまくいったとどう分かるかです。両方の空欄を一息で埋められないなら、まだコアを見つけていません——範囲を定める準備も、ましてや作る準備もできていません。

コアループと、不可欠に感じるが実はそうでないものとの違いには、容赦なくあってください。ログインは不可欠に感じます。たいていバージョン1では違います——多くのMVPは一本の共有リンク、手動の招待、あるいはアカウントなしでローンチし、認証の仕組みを作る前に必要なことをすべて学びます。分析ダッシュボードは不可欠に感じます。違います。ユーザーが十一人なら、データベースを手で読めます。ループまで削ぎ落とせば、どれほど多くが脱落するか驚くでしょう。

すべての機能を「必須」「あると良い」「今はやらない」に分ける

コアループに名前を付けたら、大きな機能リストを取り、各項目を三つのバケツに分けてください。バケツは意図的に大ざっぱです。大ざっぱさこそが、果てしない「でも、もしかしたら」の会話を止めるからです。

• 必須：これなしではコアループが文字通り機能しない。取り除けば製品はない。このリストは衝撃的なほど短く保つ——通常は三〜六項目。
• あると良い：製品を良くするが、それなしでもループは動く。ここにあるものはすべてバージョン2を待つ。最初の開発では例外なし。
• 今はやらない：今は作らないと意識的に選ぶ機能。書き留めることが大切——アイデアが捨てられたのではなく、順序づけられただけだと、自分とチームを安心させる手段になる。

これを機能させる秘訣は三つ目のバケツです。多くの人は「必須」対「あると良い」だけで議論し、それは消耗し、決して終わりません。「今はやらない」リストこそ安堵の宿る場所です——あの面白いアイデアは安全で予定済み、ただ今ではない、と未来の自分への約束です。何も捨てられていないと人々が信じれば、何もかもをバージョン1に残そうと戦うのをやめます。

機能リストではなく、時間とお金で範囲を定める

すべてを変える静かな転換があります。「何が欲しいか」で範囲を定めるのをやめ、「予算と締め切りに何が収まるか」で定め始めるのです。まず、コアの問いに答えるためにいくらのお金と何週間を使う気があるかを決めます。それから機能リストをその箱に収めます。逆さまに聞こえますが、これは自分に課せる最も有用な制約です。さもなければ避けてしまう優先順位づけを強いてくれるからです。

固定された箱は心理的なことも起こします。予算が青天井だと、あらゆる機能が議論の余地ありで、リストは膨らむばかりです。箱が固定されると——たとえば八週間と決まった金額——会話は反転します。「これを足すべきか？」ではなく「これが入るなら何が出るのか？」になります。良いMVPを作るのはこの二つ目の問いです。トレードオフが隠れず見え、チームは意図して選びます。

実例：作業管理のアイデアを絞り込む

私たちが手がけた事例で具体的にしましょう——匿名化していますが、こうした案件の実態に忠実です。小さな暖房・配管会社が、現場チーム向けのアプリを望んで来ました。紙の上では概要は膨大でした。リアルタイムの作業スケジューリング、バンのGPS追跡、顧客ポータル、自動請求、各車両の部品在庫、見積りビルダー、写真ドキュメント、そしてオーナー向けのレポート一式。最終的には本当に有用な製品です。最初の開発としては、何かを学ぶ前に一年分の予算を使い切る確実な方法でした。

そこで私たちは例の演習をしました。オーナーにあの文を尋ねたのです。「ユーザーはこれに来て ______ し、______ なら満足する。」 いくらかのやり取りの後、本当の答えが浮かびました。技術者たちの最大の日々の苦痛はスケジューリングでも請求でもなく——書類の往復でした。作業を終え、時間と部品を紙に走り書きし、走って戻り、事務所の誰かがそれを全部、しばしば数日後に、しばしば誤りとともに、会計システムに打ち直すのです。コアループは単純にこうでした。現場で起きたことを、一度、その場で記録し、誰も打ち直さなくて済むようにする。

選ばれたもの——そして選ばれなかったもの

すべてが分類されました。必須バケツは四つに絞られました。各技術者向けの今日の作業一覧、作業ごとに時間と使用部品を記録する簡単なフォーム、写真の添付、そして提出された瞬間に事務所がそのデータを見られる仕組み。それがMVPのすべてでした。GPSも、顧客ポータルも、見積りビルダーも、凝ったレポートもなし——すべて明示的に「今はやらない」リストに、後で来るという注記とともに置きました。

私たちはそのコアを、一年の大半ではなく数週間で作りました。そして全アプローチを正当化する部分はここです。稼働するや、チームの本当の優先事項は概要と違うと分かりました。オーナーは次はGPS追跡だと思っていましたが、技術者はほとんど触れませんでした。彼らが声高に望んだのは、アプリの中から顧客に到着時間帯をメッセージで送ることでした——元のリストにすら載っていなかった機能です。MVPが小さく安かったので、数か月前に推測したものではなく、本当に欲しかったものを作る予算が残っていたのです。

MVPの範囲を静かに台無しにする間違い

「小さく保つ」を受け入れたチームでも、たいてい同じ数個でつまずきます。どれも劇的ではありません。見ていない隙に範囲を再び膨らませる、ゆっくりした水漏れです。やがてある日、「最小限」の製品はまた三十画面と六か月の工程を抱えています。

• 端を金メッキする：コアループがまだ粗いのに、自分しか見ない管理画面を磨くのに何日も費やす。ユーザーが触れるものを磨き、裏方は不格好でも機能すればよしとする。
• 持っていない規模のために作る：最初の十人が戻るかを証明すべきときに、百万ユーザー向けに設計する。規模の問題は、規模という幸せな問題を抱えてから解く。
• 「必須」と「業界標準」を混同する：どの競合も機能Xを持つからといって、あなたのMVPがコアアイデアを検証するのにそれが必要とは限らない。あなたは完成品を出すのではなく、実験を行っている。
• すべての例外ケースを事前に設計する：誰かが普通の正常な経路を使うか分かる前に、稀で奇妙な入力に対処する。どの例外ケースがそもそも本物かは、実際の利用に教えてもらう。
• 完了の定義がない：「完成」がどう見えるかを記した一文がなければ、開発は決して終わらない。スコープクリープは、ゴールラインのないプロジェクトが大好きだ。

これらのうち一つだけ防ぐなら、最後のものにしてください。明確に書かれた完了の定義——「技術者が作業の時間と部品を電話で記録でき、事務所がそれを即座に見られる」——は、範囲を正直に保つ最も強力な単一の道具です。提案される追加はすべて、その一文に照らされます。一文に資さないなら、どれほど良くてもバージョン2のアイデアです。

MVPの範囲を定めるための簡単なプロセス

まとめると、最初の開発を始める前に私が誰とでも歩む順序はこうです。意図的に低テクです——大半は、部屋に開発者が要るよりずっと前に、一枚のドキュメントと正直な会話でできます。

1. 1
   コアループに名前を付ける

   文を完成させる。「ユーザーは ___ をしに来て、___ なら満足する。」 できないなら、まだ範囲を定める準備はできていません——本当の仕事が浮かぶまで話し続けてください。
2. 2
   機能をすべて吐き出し、それから分類する

   願望リストすべてを頭から紙に出す。各項目を必須・あると良い・今はやらないに分ける。「必須」リストは無慈悲なほど短く保つ。
3. 3
   箱を固定する

   機能リストを確定する前に、予算と締め切りを決める。リストを箱に収める。逆ではない。
4. 4
   完了の定義を書く

   動くコアループを記した具体的な一文。これがプロジェクトの残りを通じてスコープクリープに対するあなたの盾です。
5. 5
   作り、出し、観察し、それから決める

   コアを実際のユーザーに届ける。彼らが実際に何をするかを観察する。以前の推測ではなく彼らの振る舞いに、「あると良い」リストから次に何が降りてくるかを選ばせる。

最後のステップが出発点へ戻ることに気づいてください。良いMVPは一度きりの出来事ではなく、車輪の最初の一回転です。小さく範囲を定め、出し、学び、学んだことが次の開発の範囲を定め直します。勝つチームは、完璧な製品を事前に計画した者ではありません——誰もそれはできません。現実がまだ舵を切れるほど速く、本物をユーザーの前に出した者です。

よくある質問