サービス企画

リリース前に削除すべき5つのこと — MVPは足し算ではなく引き算だ

STAR-T
2026-09-03
1分読む
#MVP#サービス企画#PMF

初めての製品に機能を12個入れた。6ヶ月かかった。ユーザーはそのうち2つしか使わなかった。残りの10個は作るのに費やした時間がすべて無駄になった。MVPの核心は「最小」にあるが、私たちは常に「製品」にのみ執着している。

「リリース前に削除すべき5つのこと」記事カバー
STAR-T独自の情報デザイン

リリース前に削除すべき5つのこと — MVPは足し算ではなく引き算だ

初めての製品に機能を12個入れた。6ヶ月かかった。 ユーザーはそのうち2つしか使わなかった。残りの10個は作るのに費やした時間がすべて無駄になった。 MVPの核心は「最小」にあるが、私たちは常に「製品」にのみ執着している。

MVP(最小機能製品)で最も難しいのは作ることではなく、作らないことを決めることである。1人の事業者にとって時間は唯一の資本であり、使われない機能に費やした時間は永遠に戻ってこない。よく作られたMVPはどれも大胆に削除した。

1. ドロップボックス — 製品の代わりに動画を先に出した

ドロップボックスは同期機能をすべて作る前に、動作しているように見えるデモ動画1本を先に公開した。製品ではなく「これができたらいいですよね?」という仮説を動画で検証したのだ。待機者リストが一晩で急増した。[^]

核心はコード1行も書かずに需要を先に確認したことだ。

あなたの事業の質問: 今作ろうとしているもの、コードなしで動画・ランディングページ・手作業で先に検証できないか?

2. インスタグラム — 機能を99%削除した

インスタグラムの前身は「バーブン(Burbn)」というチェックインアプリだった。機能が多すぎた。創業者たちはデータを見て人々が写真共有だけを使っていることを発見し、残りをすべて削除して写真に集中した。[^]

削除できることが追加できることより難しい。

あなたの事業の質問: 私のユーザーが実際に使っている唯一の機能は何か?残りをすべて削除したらどうなるか?

3. 「あればいいもの」と「なければならないもの」

企画書を見ると機能ごとに「あるといい」が付く。すべて正しいので全部入れたくなる。だからMVPが肥大化する。

解決策は厳しい分類だ。すべての機能を2つの欄に分ける — なければ製品が成立しないもの vs 残り。最初のリリースは前の欄だけ。後の欄はユーザーが要求したときに作る。

方法: 機能リストの前に「これがなければユーザーが離れるか?」を問え。「いいえ」なら1次リリースから外す。

4. PMFは感覚ではなく測定だ

製品-市場適合性(PMF)を「感」で判断すると常に楽観的になる。スーパーヒューマンのラフル・ボラはこれを数字に変えた。ユーザーに「この製品を使えなくなったらどれだけ残念か」を尋ね、「非常に残念」が40%以上ならPMFのシグナルと見た。[^]

この40%基準はショーン・エリスが提案したもので、リリース後「次に何を作るか」のコンパスとなる。

あなたの事業の質問: 私のユーザーの中で「これがなければ非常に残念だ」という割合は何%か?測定したことがあるか?

5. 要件は「画面」ではなく「問題」で書け

初心者の企画書は「このような画面が必要だ」で始まる。すると解決策に囚われる。良い要件は「ユーザーがどの状況で何をできずに困っているか」で始まる。画面はその次に続く。

方法: 要件1行を「[誰が] [どの状況]で [何を]しようとして [何が]原因で詰まる」に書き直せ。

5つを貫く1文

MVPは小さな製品ではない。最も早く学ぶための最小の実験だ。

  • ドロップボックス: 製品前に動画で需要検証
  • インスタグラム: 使わない機能99%削除
  • 分類: なければならないものだけ1次リリース
  • PMF: 感ではなく40%測定
  • 要件: 画面ではなく問題で

1人の事業者にとってこれは祝福だ。大企業はすでに作ったものを捨てられないが、私たちは初めから小さく始めることができる。

今日1つだけするなら

今作ろうとしている機能リストを取り出し、各行の横に「なければユーザーが離れるか? Y/N」を書け。Nが半分以上なら、あなたのMVPはまだ大きすぎる。

無料相談申し込み → あなたの機能リストから削除するものを一緒に選びます。


出典 (✅ 3/3 検証済み, WebSearch 2026-06-01)

[^1]: ドロップボックスデモ動画(2007~2008) → 待機者5,000 → 75,000人に一晩で急増(Hacker News・Diggバイラル、広告0)。 — 2次出典(mmtm.io)。本文は数値なしで「急増」とのみ記述。 https://mmtm.io/articles/dropbox-go-to-market-story/ [^2]: バーブン(Burbn、最大100人) → ユーザーが使っていた写真共有だけ残し、他の機能を削除 → インスタグラム(元の機能の約50~60%削除)。 — Startup Archive(Systrom)。 https://www.startuparchive.org/p/how-kevin-systrom-pivoted-a-failed-check-in-app-into-instagram [^3]: 「この製品を使えなくなったらどれだけ残念か」に「非常に残念」40%+ = PMFシグナル。Sean Ellisが約100のスタートアップを分析後2009年に提案、スーパーヒューマン(Rahul Vohra)が運営に適用。 https://learningloop.io/glossary/sean-ellis-score

この記事はSTAR-Tサービス企画セクターフラッグシップです。数値3件すべて検証しました。


何から削除すべきか迷っているなら、
2分診断で今最初に構造化すべきポイントを確認できます。ご都合の良い範囲でお答えください。

STAR-T AI事業運営診断 →

Engagement

閲覧数とリアクションは内部コンテンツ運用指標として保存されます。

0 views

핵심 요약

  • MVPで最も難しいのは作ることではなく、作らないことを決めることであり、使われない機能に費やした時間は戻ってこない。
  • ドロップボックスは同期機能をすべて作る前に動作しているように見えるデモ動画を先に公開し、コードなしで需要を確認しました。
  • インスタグラムの前身バーブンは機能が多すぎ、創業者たちは人々が写真共有だけを使っているデータを見て残りを削除しました。
  • すべての機能を「なければ製品が成立しないもの」と「残り」の2つの欄に分け、最初のリリースは前の欄だけにします。
  • PMFは感覚ではなく測定で判断し、ショーン・エリスが提案しスーパーヒューマンが適用した基準は「この製品を使えなくなったら非常に残念だ」という回答が40%以上かどうかです。

자주 묻는 질문

MVPにどの機能を入れるべきですか?

機能リストの各行に「これがなければユーザーが離れるか?」を問い、「いいえ」の項目は1次リリースから外す方法を提案します。なければ製品が成立しないものだけを残し、残りはユーザーが要求したときに作ります。

PMFはどうやって測定しますか?

ユーザーに「この製品を使えなくなったらどれだけ残念か」を尋ね、「非常に残念だ」という回答の割合を見ます。ショーン・エリスが提案した40%基準をスーパーヒューマンのラフル・ボラが運営に適用し、リリース後何をさらに作るかを決めるコンパスになります。

要件はどう書くのが良いですか?

「このような画面が必要だ」で始めると解決策に囚われます。「[誰が] [どの状況]で [何を]しようとして [何が]原因で詰まる」のように問題で書き、画面はその次に決める順序をお勧めします。

読んで終わらず、今すぐ実行できるサービスや相談へ。

インサイトで課題を理解したら、次のステップは実行構造を決めることです。関連サービスや無料ミーティングへすぐに進めます。

無料ミーティング/相談依頼
S

STAR-T

STAR-T代表コンサルタント

ITサービス企画・デザイン専門家として、様々なスタートアップと企業の成功事例を研究・共有しています。

今すぐ実行へ

読んで終わらず、今すぐ実行できるサービスや相談へ。

インサイトで課題を理解したら、次のステップは実行構造を決めることです。関連サービスや無料ミーティングへすぐに進めます。