ローンチ時にSaaSのMVPに含めるべきもの、含めるべきでないもの

minimum viable product の「最小限」という言葉は、誰もが見過ごす部分です。創業者は小さく始めるという考えにうなずきながら、四十もの画面、三つのユーザー権限、課金エンジン、分析ダッシュボード、そして「あ、それからすべてと連携してほしい」という仕様書を渡してきます。それはMVPではありません。楽観をめいっぱい振り切った、完成品そのものです。そしてこれこそ、最初のローンチが遅れ、予算を超過し、それでもなぜか顧客が本当に欲しかった一つのものを欠いている、最も多い理由なのです。

私はかなりの数の小さな企業や一人の創業者が、最初のソフトウェア製品を世に出すのを手伝ってきました。技術的な部分でつまずくことはめったにありません。難しいのは——毎回——まだ何を作らないかを決めることです。MVPとは、夢の製品から機能を無作為に削り取った小型版ではありません。意図的な賭けです。本物のユーザーの前に置ける最小のもので、核心となるアイデアがあなたのお金と時間をさらに費やす価値があると証明するものです。

ですからこれは、もっと多くの創業者が仕様書を書く前に読んでくれたらと願うガイドです。専門用語もなく、「素早く動いて壊せ」という芝居もありません。最初のリリースに属するものと、待てる——そして待つべき——ものの線引きをする、実践的な方法だけです。

MVPとは実際に何か(そして何でないか)

まず定義をはっきりさせましょう。混乱のほとんどはここから始まるからです。MVPとは、本物の人があなたの製品が約束する一つの価値ある行為を行えるようにする、最小で最もシンプルな版です。そして、その人がもう一度それをしに戻ってくるかどうかを学べるようにします。それだけです。これはたまたま動くソフトウェアでできた学習の道具であって、完成品を削ぎ落としたローンチではありません。

肝心な言葉はviable(成り立つ)です。よくある間違いは「最小限」を読み取り、ユーザーを困らせるほど素っ気ないものを出してしまうことです——途中で落ちる半端なフロー、空の画面につながるサインアップ。それは最小限で成り立つのではなく、最小限で壊れているのです。もう一つの失敗はその逆で、あまりに「完成」していて作るのに一年かかり、その頃には八週間で検証できたはずの推測を証明するために資金を使い果たしている、というものです。

私が使う思考のテストはこうです。リストにあるすべての機能について問いかけます。これを取り除いても、ユーザーは製品が存在する理由である一つの核心的な成果を、まだ得られるだろうか? 答えが「はい」なら、それはほぼ確実にMVPではありません。この問い一つで、ほとんどの仕様書は半分に削れます——そして削られる半分こそ、あなたを遅らせるはずだった半分なのです。

あなたの製品が果たす一つの仕事を見つける

何を作るか決める前に、あなたの製品が誰かのために果たす一つの仕事について、容赦なく明確になる必要があります。ビジョンではありません。ロードマップでもありません。うまくいけば人の一日を良くし、お金を払う気にさせる、一つの繰り返せる行為です。難航する仕様書のほとんどは、まさにここが曖昧です——仕事ではなくプラットフォームを描いているのです。

この一文を声に出して完成させてみてください。「ユーザーは私の製品に______しに来て、______して帰っていく。」 シフト管理ツールなら、管理者は来週の勤務表を公開しに来て、すべてのシフトが埋まりチームに通知された状態で帰っていく。請求アプリなら、フリーランサーは顧客に請求しに来て、送信済みで追跡できる請求書を手にして帰っていく。この一文をきれいに埋められないなら、まだスコープを定める段階ではありません——まだ考える段階です。

どのSaaS MVPにも本当に必要なもの

いくつかのものは、最も無駄を削ぎ落とした初版でも譲れません——わくわくするからではなく、それがなければ製品が使えないか、あなたに何も教えてくれないからです。これらは天井ではなく床だと考えてください。シンプルに作りつつも、きちんと作りましょう。

• サインインの手段。メールとパスワードの一つのログインでも構いません——ただし本物の、安全なものを。すべてはユーザーが誰かを知ることに掛かっているからです。
• 核心となるワークフローを端から端まで。一つの仕事を、ユーザーの最初のクリックから価値ある成果を得る瞬間まで——行き止まりも、肝心な経路上の「近日公開」ボタンもなしに。
• データが実際に置かれる場所。使い捨てのプロトタイプではなく本物の保存先を。ユーザーの作業が再読み込みに耐え、明日また戻ってこられるように。
• 何が起きているかをあなたが見る手段。基本的なログか簡単な管理画面を。何かが壊れたとき——必ず壊れます——推測せずに理由を突き止められるように。
• ユーザーがあなたに連絡する手段。メールのリンク一つでも構いません。初期のユーザーはあなたが想定しなかった境界にぶつかります。黙って去るのではなく、あなたに伝えてほしいのです。
• 信頼の最低限：プライバシーに関する注記、まっとうなデータの扱い、そして人々の情報で無謀なことをしないこと。

このリストにないものに注目してください。課金、凝ったオンボーディング、設定ページ、モバイルアプリ、連携です。なぜかはすぐにお話しします。床の要点は、仕上げられるほど小さく、学べるほど堅いことです。動くログイン、成果を届ける一つのワークフロー、本物のデータ、そしてユーザーを観察し対話する手段。それが成り立つ製品です。

v1からあえて外すもの

ここは創業者が抵抗する節なので、はっきり言わせてください。最初のローンチに不可欠に感じるものの大半は、不可欠ではありません。「本物の製品」にはそれがあるから不可欠に感じるのです——でもあなたはまだ本物の製品を作っているのではなく、問いを作っているのです。これらを外すのは手を抜くことではありません。それこそがMVPの規律そのものです。

自動課金と複雑な価格設定

バージョン1で、セルフサービスの課金エンジン、段階的プラン、日割り計算、督促ロジックは、まず必要ありません。初期のユーザーが払いたいなら、手作業でお金を受け取れます——請求書、決済リンク、短い電話。最初の十人の顧客への手作業の課金は、自動課金では分からないことを教えてくれます。そもそも誰かが払うのかです。集めるお金があると証明できてから、機械を作りましょう。

凝った権限と役割

複数の役割の権限システム——管理者、マネージャー、閲覧者、細かなアクセス規則——は本物のエンジニアリングの泥沼であり、テストの対象範囲を莫大に増やします。最初のリリースには、一種類のユーザーでほぼ常に十分です。本当の権限の必要は、実際のチームがそれを使う様子を見て学ぶもので、それは紙の上で推測したものとはめったに一致しません。

連携、ネイティブモバイルアプリ、そしてダッシュボード

「すべてと連携する必要がある」は、静かにスケジュールを倍にする言葉です。連携はせいぜい一つ選び、それも核心の仕事の一部である場合だけにしましょう。ネイティブのiOSとAndroidのアプリは、ほぼ常に待てます——レスポンシブなウェブアプリは今日でも電話で動きます。そして皆が欲しがる分析ダッシュボードは? ユーザーはまだ作っていないデータを分析できません。まずデータを生み出すものを出し、見せるものができてから可視化しましょう。

線を引くためのシンプルな方法

原則を知ることと、機能の一つひとつが我が子のように感じられる自分の仕様書にそれを当てはめることは、別物で、後者の方が難しいものです。これは、すべてを「不可欠」へと漂わせるのではなく、各項目に決断を迫るから機能する方法です。

1. 1
   思いついた機能をすべて書き出す

   まずは全部吐き出す——まだふるい分けはしない。望みのリストを丸ごと机に出し、何も言われないまま潜み、構築の途中で不意打ちとして再び現れないようにします。
2. 2
   核心の仕事に照らして印をつける

   各機能について問います。ユーザーが一つの核心の仕事を端から端まで完了するのに、これは必要か? それを「核」「役立つ」「いつか」と印づけます。正直に——ほとんどは後ろの二つに落ちます。
3. 3
   v1には「核」だけを残す

   あなたのMVPは「核」の山だけで、それ以外はありません。「役立つ」と「いつか」の山は却下ではありません——本来あるべき場所に停められた、あなたのロードマップです。
4. 4
   削った結果を常識で確かめる

   残ったものを見て問います。本物のユーザーが、これだけで本物の価値を得られるか? 得られるなら、MVPのスコープを定められています。もし何かが本当に核心のフローを壊すなら、その一項目だけを戻す——他は何も戻しません。

規律は四つ目の手順にあります。「もう一つだけ戻そう」という誘惑がいつもあり、そしてまた一つ、と続いて、気づけば静かに完成品をまた作り直しています。本当に核心のフローを壊す項目だけを救うことを自分に許してください——単により良くするだけの項目ではなく。より良くするのは、バージョン2のためにあります。

成り立つとは、それでも本物に感じられねばならないということ

線の反対側にも失敗の形があり、名前をつける価値があります。小さく出そうと急ぐあまり、一部の創業者は粗末なものを出し——それをMVPと呼びます。作業を失う核心フロー、404を返すサインアップ、仮の文字だらけの文章。それはあなたのアイデアを公平に検証しません。壊れた体験をユーザーが我慢するかを検証しているのであり、答えは常に「いいえ」です。本当は実行が失敗したのに、アイデアが失敗したと結論づけてしまうのです。

「最小限」は範囲に適用されるのであって、残す部分の品質には決して適用されません。機能は少なく、一つひとつは堅く。あなたが出す一つのワークフローは、完成しているように感じられるべきです——速く、明快で、信頼できるように——たとえ製品がそれしかしなくても。狭い製品をうまく作る方が、広い製品を下手に作るより毎回勝ります。とりわけ、見知らぬ人に自分の作業を委ねてくれと頼むときには。

MVPはゴールではない——最初の計測値だ

ここがすべての見方を変える部分です。ローンチは目標ではありません。目標は、その後の数週間で学ぶことです。出してみて「ユーザーは核心を気に入っているが、Xを求め続けている」と教えてくれるMVPは大成功です——たとえXがあと一か月の作業を意味しても。沈黙の中に出て、誰も戻ってこないMVPもまた、その役目を果たしています。誰も望まなかった土台の上に残り三十の機能を作るのを、あなたから救ってくれたのです。

ですから最初の数週間を、構築と同じくらい意図的に計画してください。アンケートで言うことではなく、人々が実際に何をするかを観察します。戻ってきた人と、戻ってこなかった人の両方と話します。あなたの当初の仕様ではなく、実際の使われ方に、バージョン2に何を入れるかを決めさせましょう。先ほど停めておいたロードマップは約束ではありません。仮説であり、あなたのユーザーがまさにそれを採点しようとしています。

よくある質問