スタートアップ検証スタック：12のプロジェクトが教えてくれたエビデンスの重要性

CB Insightsはスタートアップの失敗事例101件を分析し、42%が市場ニーズの欠如により失敗していることを明らかにしました。私も同じ失敗パターンを小規模ながら経験しています。SureInsure（保険分析ツール）を、たった一人のユーザーにも「この製品が欲しいですか？」と聞くことなく、機能完成まで作り込んでしまいました。誰も欲しがっていませんでした。開発には3週間かかりました。その3週間を節約できたはずの検証は、たった一afternoon で終わるものです。¹

TL;DR

スタートアップの検証には特定の順序があります。望ましさ（人々はそのソリューションを求めているか？）、実現可能性（チームはそのソリューションを構築できるか？）、そして持続可能性（そのソリューションでビジネスを維持できるか？）です。9ヶ月間で12のプロジェクトを立ち上げた結果——Ace Citizenship、Return (941)、ResumeGeni、Banana List、Water、Reps、Design Gallery、Sorting Visualizer、Starfield Destroyer、SureInsure、amp97、そして個人サイト——あらゆる検証のアンチパターンを身をもって経験しました。構築前に検証したプロジェクトは、より早くリリースでき、ユーザーを獲得しました。構築してから検証したプロジェクトは、高い授業料を払う結果となりました。

---

私の検証スコアカード

プロジェクト	構築前に検証したか？	結果
ResumeGeni	はい（ランディングページ＋ウェイトリスト）	アクティブユーザー、収益あり
Ace Citizenship	はい（コミュニティリサーチ＋インタビュー）	ユーザーベース拡大中
個人サイト	部分的（コンテンツは検証済み、デザインは未検証）	Lighthouse 100/100、安定したトラフィック
Banana List	いいえ（自分のかゆいところを掻いただけ）	自分には便利、市場での牽引力なし
SureInsure	いいえ（まず機能完成まで構築）	ユーザーゼロ、お蔵入り
Sorting Visualizer	いいえ（週末プロジェクト）	ポートフォリオ作品、製品ではない

パターンは明白です。コードを書く前に検証エビデンスに投資したプロジェクトはユーザーを獲得しました。先に構築してから検証したプロジェクトは、一度も成果を生みませんでした。²

---

検証の順序

なぜ順序が重要なのか

エンジニアはまず実現可能性に注目します。「それを作れるか？」プロダクトマネージャーはまず持続可能性に注目します。「それをマネタイズできるか？」どちらも、スタートアップの42%を殺す問いを飛ばしています。「実際に誰かがそれを欲しがっているのか？」³

正しい順序は、検証コストが最も安い仮説から順にテストしていきます。

1. 課題の検証（その課題は実在し、痛みを伴うものか？）
2. ソリューションの検証（提案するソリューションはその課題に対処するか？）
3. チャネルの検証（ターゲット顧客にリーチできるか？）
4. 収益の検証（顧客はお金を払うか？）
5. スケールの検証（ユニットエコノミクスはスケール時に成り立つか？）

各ステージのテストコストは前のステージより高くなります。先のステージに飛ぶと、未検証の安価な仮説に依存する高コストの仮説をテストすることになり、リソースの無駄遣いになります。

---

ステップを飛ばしたプロジェクト

SureInsure：機能完成の罠

SureInsure——LLMを活用した保険契約分析ツール——を作ったのは、保険の書類がわかりにくいと感じたからです。検証アプローチは皆無でした。個人的な不満が市場ニーズに一般化できると思い込んでいました。

3週間の開発で、保険契約書を解析し、補償のギャップを指摘し、除外事項を平易な言葉で説明できる実用的なツールが完成しました。技術的には動作しました。問題は、保険契約者が分析ツールを積極的に探していないことでした。痛みは実在しますが潜在的なものです——保険金請求が却下されるまで、自分の補償が不十分だと気づかないのです。潜在的な痛みに対しては、どれだけ製品の品質を上げても流通の問題は解決できません。

検証で明らかになったであろうこと： 保険契約者と十数人会話するだけで、「保険契約アナライザー」で検索する人は誰もいないことがわかったはずです。課題が発生するのは保険金請求時であり、契約内容確認時ではありません。チャネル（検索）と課題のタイミング（危機的状況）が一致していないのです。⁴

Banana List：自分のかゆいところを掻く

Banana List（SwiftUI + SwiftDataの買い物リストアプリ）を作ったのは、特定のワークフローが欲しかったからです。すばやくメモでき、iCloud同期があり、それ以外は何もいらない。検証は自分自身の使用——自分用のツールとしては有効ですが、市場のエビデンスは何も生みません。

Banana Listは動きます。毎日使っています。このアプリは一人のユーザーに完璧にサービスを提供しています。間違いはアプリを作ったことではなく、「自分がこの製品を欲しい」ということが「市場がこの製品を欲しがっている」に一般化できると思い込んだことです。私の使用は実現可能性と個人的な望ましさを検証しましたが、市場の望ましさや流通については何も検証していませんでした。

---

先に検証したプロジェクト

ResumeGeni：コードの前にランディングページ

ResumeGeniは一つの問いから始まりました。求職者はATSシステムに最適化されたAI生成の履歴書にお金を払うだろうか？アプリケーションコードを一行も書く前に、バリュープロポジションを説明するランディングページを作り、ウェイトリストフォームを追加しました。

エビデンス： - Redditとlinkedinへのターゲット投稿から2週間で340件のメール登録 - 「いつ使えますか？」と返信してきた12人のユーザー - アーリーアクセスにお金を払うと申し出た3人のユーザー

ウェイトリストは望ましさ（人々はATS最適化された履歴書を求めている）とチャネル（Reddit/LinkedIn上の求職者コミュニティ）を検証しました。エビデンスが私の基準を超えてから初めて、FastAPIバックエンド、HTMXフロントエンド、LLM統合の構築に投資しました。⁵

Ace Citizenship：まずコミュニティリサーチ

Ace Citizenship（市民権試験対策アプリ）は、コードではなくコミュニティリサーチから始めました。市民権取得準備のフォーラム、サブレディット、Facebookグループで2週間かけて以下を観察しました。 - 最も頻繁に質問されていること - 既存のソリューションに対する不満 - 何があれば良いと思っているか

リサーチにより、ギャップが明らかになりました。既存の対策アプリはコンテンツはカバーしていますが、試験戦略はカバーしていません。この戦略ギャップが製品の差別化要因になりました。リサーチが既存製品では対処されていない明確な差別化要因を生み出してから初めて、開発を開始しました。⁶

---

30日フレームワーク（経験により改良）

第1週：課題の検証

方法： 潜在顧客10〜15人に対して構造化インタビューを実施します。ソリューションの説明はしません。課題の領域にのみ集中します。

実際に効果のある質問： - 「最後に［課題］を経験したときのことを教えてください。何が起きましたか？」 - 「何を試しましたか？何がうまくいき、何がうまくいきませんでしたか？」 - 「現在、［課題］への対処にどれくらいの時間やお金を費やしていますか？」

エビデンスの成果物： 課題の頻度と深刻度のマトリクス。15人中7人未満しかその課題を頻繁（週1回以上）かつ苦痛を伴う（回避策にお金や時間を費やしている）と述べない場合、その課題には十分な市場の引力がありません。⁷

第2週：ソリューションの検証

方法： 同じインタビュー対象者にソリューションのコンセプト（ワイヤーフレーム、ランディングページ、または口頭での説明）を提示します。礼儀正しさではなく、反応の強さを測定します。

強いシグナル： 「いつ使えますか？」「アーリーアクセスにお金を払えますか？」「このソリューションを必要としている同僚を紹介させてください。」

弱いシグナル： 「面白いですね。」「良さそうですね。」「たぶん試すと思います。」SureInsureについて友人から3つとも聞きました。誰一人として実際の利用には至りませんでした。

エビデンスの成果物： コミットメント率。15人中3人未満しか具体的なアクション（登録、入金、紹介）を取らない場合、そのソリューションは課題と十分に一致していません。⁸

第3週：チャネルの検証

方法： 小規模な顧客獲得実験を2つ実施します。チャネルごとに200〜500ドルを費やし、ターゲット顧客にリーチできるかをテストします。

ResumeGeniでは、2つのチャネルをテストしました。 - Redditの求職者コミュニティ：オーガニック投稿で340件の登録（費用0ドル） - LinkedInのターゲットコンテンツ：150ドルの費用で45件の登録（1件あたり3.33ドル）

Redditが勝ちました。チャネル検証により、継続的な顧客獲得の努力をどこに投資すべきかがわかりました。⁹

第4週：収益とユニットエコノミクスの検証

方法： 製品のプレセールを行うか、アーリーアクセスの支払いを受け付けます。

エビデンスの成果物： 見込み顧客から有料顧客へのコンバージョン率。B2Bで2%未満、B2Cで0.5%未満の場合、本格的な開発に投資する前にバリュープロポジションの見直しが必要です。¹⁰

---

私が実践してしまった検証のアンチパターン

アンケートの罠

アンケートは表明された選好を測定します。顧客インタビューとコミットメント行動は明らかにされた選好を測定します。80%が「その製品を使う」と回答するアンケートは、実際には約5%の採用率に相当します。SureInsureで表明された選好と明らかにされた選好のギャップを学びました。友人全員が「それは便利そうだ」と言いました。ローンチ後にその製品を使った友人はゼロでした。¹¹

創業者のオーディエンス問題

個人的なネットワーク内だけで検証する創業者は、偏ったデータを受け取ります。友人は応援的なフィードバックを提供しますが、それは市場の行動を予測しません。見知らぬ人へのコールドアウトリーチは、より質の高い検証データを生み出します。なぜなら、見知らぬ人には励ます社会的インセンティブがないからです。

ResumeGeniの検証がうまくいったのは、登録がReddit上の見知らぬ人から来たからです。友人からではありません。SureInsureの「検証」が失敗したのは、私のことを知っている人にしか聞かなかったからです。¹²

---

重要なポイント

創業者の方へ： - 実現可能性より先に望ましさを検証してください。最も一般的な失敗パターンは、動かない製品を作ることではなく、誰も欲しがらない製品を作ることです - 表明された熱意ではなく、コミットメント行動（登録、入金、紹介）を測定してください。礼儀正しい関心は購買行動を予測しません - ウェイトリスト付きのランディングページは一afternoon で作れます。機能完成まで作り込むには数週間から数ヶ月かかります

スタートアップに参加するエンジニアの方へ： - 技術アーキテクチャにコミットする前に、検証エビデンスを見せてもらうよう求めてください。適切な技術投資は、どの仮説が検証済みかに依存します - プロトタイプは本番品質ではなく、学習速度を優先して作ってください。最初のバージョンの目的はエビデンスの生成であり、大規模な顧客サービスではありません

---

参考文献