← エピソード一覧に戻る Episode 134 Chapter 1
Chapter 2
Chapter 3
Chapter 4
Chapter 5
0:00 / 0:00
スクリプト
Chapter 1 オープニング ― 足すより先に削る
タカシ
皆さんこんにちは、タカシです。今日は SaaS 立ち上げでかなり誤解されやすいテーマ、MVP範囲設計を扱います。実は初期の失敗は、作る量が少なすぎることより、何を学ぶ製品なのかが曖昧なことから起きやすいんです。
ミカ
ミカです。MVP って、どうしても『機能を削った簡易版』みたいに聞こえます。でもそれだけだと、ただ未完成なプロダクトを早く出す話にも見えますよね。範囲設計って、どこが経営判断になるんでしょうか。
タカシ
ポイントは、何を削るかではなく、何の仮説を検証するために削るかです。最初の顧客が本当に欲しい仕事の流れを一つ通すために、あえて周辺機能を捨てる。MVP は省略版というより、学習用に焦点を合わせた一撃なんですね。
ミカ
なるほど。全部を少しずつできる製品より、『この仕事だけはちゃんと終わる』製品のほうが、むしろ初期には強いわけですね。広く見せるより、狭く刺すほうが次の判断材料が増える、と。
タカシ
その通りです。今日は、良い MVP範囲設計の考え方、Vanta や Kubecost、Linear の具体例、そして初心者が陥りやすい失敗まで順番に見ていきます。皆さんの事業でも、今の仕様は学習を速くしているか、考えながら聞いてみてください。
Chapter 2 基本 ― MVP は機能一覧ではなく仮説の器
タカシ
Y Combinator は、MVP では見た目の豪華さより、顧客にとって目的が明確で、主要なユースケースがちゃんと通ることが大事だと整理しています。つまり最初に決めるべきは画面数ではなく、『この製品で何を完了させるのか』なんです。
ミカ
でも実際には、営業からはこの機能、顧客からはあの機能、と要望がどんどん増えますよね。創業者としては不安だから、つい保険で盛りたくなる気持ちもあります。どこで線を引けばいいんでしょう。
タカシ
そこで効くのが、今回検証したい仮説を一文で固定することです。たとえば『50〜300名規模の B2B SaaS が、SOC 2 準備の手作業を短時間で前に進められるか』のように置けば、その仮説を前進させない機能は原則として外せます。
ミカ
仮説が先にあると、要望を全部同じ重さで扱わなくて済みますね。便利そうだけど今はいらないものと、価値到達に直結するものが分かれる。仕様会議というより、仮説検証会議になる感じです。
タカシ
その感覚です。SVPG も、MVP は価値が伝わり、実際に使え、事業として成立し得る形であるべきだと述べています。削るのは大事ですが、価値の核まで削ると反応が悪い理由が見えなくなる。だから『小さいけれど仕事は終わる』が基準になります。
Chapter 3 事例 ― Vanta と Kubecost は何を絞ったか
タカシ
まず Vanta です。初期から完成したセキュリティ自動化 SaaS を作ったわけではなく、スプレッドシートや手作業も交えながら、SOC 2 準備のどこを軽くすれば顧客が前に進めるかを確かめていました。範囲を広げるより、最も嫌われる作業に集中したんですね。
ミカ
『まず全部自動化する』じゃなくて、『一番つらい工程を先に軽くする』なんですね。これなら確かに、顧客が払う価値も見えやすいし、どこまで作れば十分かも判断しやすい。初期のプロダクトって、勇気ある切り捨てが必要なんだなあ。
タカシ
Kubecost も象徴的です。創業者たちは Kubernetes のコスト可視化に絞った MVP を週末で作り、Grafana ダッシュボード中心のかなり小さい形で公開しました。すると公開後数日で約 150 ユーザーが使い始め、会社設立前に 2〜3 社の有料顧客まで付いたそうです。
ミカ
それは面白いですね。最初から請求管理とか権限管理まで全部載せていたら、そこまで早くは検証できなかったかもしれません。『コストが見えない』という一点の痛みだけを抜き出したから、反応の有無がはっきり見えたわけですね。
タカシ
まさにそうです。Steve Blank の言う minimum feature set は、最初の顧客が対価を払う最小機能セットを見極める発想です。全部入りにすると安心に見えますが、初期の経営では『何にお金が動くか』が見えなくなるほうが危険なんです。
Chapter 4 深掘り ― 守るべきは機能数ではなく体験
タカシ
Linear も、MVP範囲設計を体験設計として捉えていた例です。待ちリストが 1 万件を超えても、一般公開を急がず、毎週招待する人数を 10 人前後に抑えて、速さと使い心地が本当に価値になるかを丁寧に見ていました。
ミカ
つい『要望が多いなら早く広げよう』となりそうなのに、むしろ絞ったんですね。機能追加より、最初の体験を壊さないことを優先した。これは SaaS の立ち上げでかなり大事そうです。最初に好きになってもらえないと、継続にもつながらないですし。
タカシ
その通りです。Linear は要素を blocker と enabler に分けて、体験を壊す問題を優先していました。MVP範囲設計では、機能を足すか削るかだけでなく、『この最初の仕事体験を崩すものは何か』を見極めることが非常に重要なんですね。
ミカ
なるほど。初期の仕様会議で揉めたら、『その機能は最初の価値到達を前に進めるのか、横に広げるだけなのか』で考えると整理できそうです。便利なもの全部より、最初の成功体験を一つ作るほうが強いんですね。
タカシ
まさにそこです。SaaStr も、初期版でも顧客が買う理由を持つ minimum sellable product であるべきだと指摘しています。だから MVP は『未完成でもいい』のではなく、『狙った顧客が価値を感じる形で最小化されている』ことが条件なんです。
Chapter 5 クロージング ― 明日からの設計手順
タカシ
よくある失敗も整理しておきましょう。一つ目は、顧客セグメントが曖昧なまま複数業種向けの要望を盛ること。二つ目は、MVP を安い完成版だと思って価値の核まで削ること。三つ目は、手動で補える部分まで全部自動化しようとして学習を遅らせることです。
ミカ
耳が痛いですね。しかも登録数だけ見て『反応があった』と思い込むのも危なそうです。大事なのは、狙った仕事が本当に終わったか、導入後一週間で価値実感が起きたか、そこまで見ないと範囲設計の当たり外れはわからないんですね。
タカシ
その通りです。明日からできることは三つあります。まず、今回検証する仮説を一文で固定すること。次に、顧客が最初に完了すべき仕事の流れを一つ選ぶこと。最後に、その流れ以外は手動運用も使って後回しにすることです。これだけで仕様のノイズはかなり減ります。
ミカ
MVP範囲設計って、作る量を減らす技術というより、学習速度を上げる経営技術なんですね。皆さんもぜひ、自社の仕様書を見返して、『これは仮説検証を前に進めるのか』で赤入れしてみてください。今回はここまでです。
タカシ
ありがとうございました。最初のプロダクトで勝つ会社は、たくさん作った会社ではなく、何を捨てるかをうまく決めた会社です。次回も SaaS 立ち上げの論点を一つずつ解きほぐしていきます。それではまたお会いしましょう。