需要検証：コードを書く前に
これは開発者が最も飛ばしたがる、しかし最も致命的なステップです。私たちはコードを書くのが一番得意で、一番楽しいので、アイデアが浮かんだ瞬間に黙々と作り始め、3か月後にローンチして——誰も来ない。検証の目的はただひとつ、最小のコストで、大量の時間を投じる前に、本当にお金を払ってくれる人がいると証明することです。
!
最大の死因：市場に需要がない
ベンチャーデータ機関 CB Insights によるスタートアップ失敗要因の定番分析では、「市場に需要がない（no market need）」が長年にわたり失敗要因のトップに君臨し、失敗したスタートアップの約 35–42% がこれに起因します——資金不足やチームの問題よりも多いのです。言い換えると、プロジェクトを殺すのは、たいてい「作れなかったこと」ではなく、「誰も欲しがらないものを作ってしまったこと」なのです。出典：CB Insights "Top Reasons Startups Fail"、多数の検証系記事で引用されている（参考資料を参照）
2種類の検証を混同しない
- 問題の検証（Problem validation）：そのペインポイントは本当に存在し、十分に痛いのか？人々は今どうやって間に合わせで解決しているのか？
- 解決策の検証（Solution validation）：自分のこの具体的な解決策を、彼らは使いたいと思い、お金を払いたいと思うのか？
順番は問題が先、解決策が後です。よくある間違いは、問題の検証を飛ばしていきなり解決策の検証に進むこと——その結果、「誰も本当には痛がっていない」問題を、より精巧に解いただけになってしまいます。
検証ツールボックス（コストの低い順）
- 顧客インタビュー（最も安く、最も過小評価されている） ターゲット層から 5–10 人を見つけ、今この問題をどう処理しているか聞きます。ポイントは、過去の実際の行動を聞くこと。未来についての仮定は聞かないこと。「こういう製品があったら使いますか？」とは聞かないでください（誰でも気をつかって「使う」と言います）。「最後にこの問題に直面したのはいつですか？そのときどう解決しましたか？そのためにいくら／どれだけの時間を使いましたか？」と聞くのです。この考え方は『The Mom Test』で、「あなたのお母さんでさえ善意の嘘でごまかせない」具体的な質問をせよ、とまとめられています。
- ランディングページテスト（Landing page test） まだ存在しない製品のランディングページを作ります。それが何を、誰のために解決するのか、価格はだいたいいくらかを明確に説明し、「今すぐ入手／ウェイティングリストに参加」ボタンを置きます。それをターゲット層（コミュニティ、広告、X）に届け、コンバージョン率を見ます。開発者の強みがここで爆発します——あなたは一晩でローンチできるのに、他の人は1週間かかるのです。
- フェイクドアテスト（Fake door test） ランディングページに「購入／申し込み」ボタンを置き、クリックすると「近日公開、メールアドレスを残していただければ一番にお知らせします」と表示します。クリック率は本当の購買意欲を直接数値化してくれます。「いいね」よりずっと正直です。
- ウェイティングリスト／事前登録（Waitlist） メールアドレスを集めることで、関心を検証しつつ最初のユーザーを蓄積します。注意：メールを残すハードルは非常に低いので、メールアドレスの数は実際の需要を過大評価します。虚栄の数字に騙されないようにしましょう。
- 予約販売／前金を受け取る（最強のシグナル） 製品ができる前に、本物のお金を払ってもらう（あるいは前金を払ってもらう、早割を買ってもらう）。お金を払う意思こそ、唯一嘘をつかない需要のシグナルです。予約販売できれば、検証はほぼ成功と言えます。
◆
シグナルの「信頼度」ランキング
口頭で「買う」と言う < メールを残す < フェイクドアの購入ボタンを押す < 有料のウェイティングに参加する < 実際にお金を払う。右に行くほど信頼できます。検証するときは、できるだけ右に寄せること——「たくさんの人がいいねした」を成功と見なさないでください。
開発者にやさしい軽量な検証フロー
上のツールを一連の流れにつなげると、たいてい数日から2週間で走り切れます：
| ステップ | アクション | 判断シグナル |
|---|---|---|
| 1. 定義 | 「私は【誰】のために【何】を解決する」と、仮の顧客像を書き出す | 一文で言い切れるか |
| 2. 人を探す | ターゲット層に接触できるチャネルを3つ挙げる（ある subreddit、あるコミュニティ、あるキーワード） | 接触できないならニッチを変えて戻る |
| 3. インタビュー | 5–10 人の実ユーザーと話し、過去の行動と支出を聞く | 同じ強いペインポイントが繰り返し現れるか |
| 4. ランディングページ | 価値 + 価格 + CTA を明確にしたページをローンチする | 訪問者→登録／購入クリックのコンバージョン率 |
| 5. お金を求める | 予約販売、早割、前金の受け取りを試す | 実際にお金を払う人がいるか |
いつ検証をやめ、構築を始めるか
検証は無限の先延ばしではありません。「お金を払う人がいる」という明確なシグナル（予約販売の成功、あるいはインタビューで複数の人が自分から「今買えますか、いつローンチですか」と聞いてくる）を手にしたら、調査をやめ、最小限の実用プロダクト（MVP）を作り始めるべきです。完璧な検証は存在しません。目標はリスクを許容できる水準まで下げることであって、リスクをゼロにすることではありません。
!
検証 ≠ 友人に聞くこと
親しい友人や家族は、あなたの気持ちに配慮して「いいね、私も使うよ」と言ってくれます。これは偽のシグナルです。必ずあなたに気をつかう義理のない、見知らぬターゲットユーザーを見つけ、できるだけ「お金を払う／情報を残す」というコストのかかる行動で確かめてください。「好きかどうか」というコストゼロの口先の表明ではなく。
この章で覚えておくこと
- 「誰も欲しがらない」はスタートアップの最大の死因（CB Insights 約 35–42%）。検証はそれを防ぐためにある。
- まず問題を検証し、次に解決策を検証する。過去の実際の行動を聞き、未来の仮定は聞かない。
- ツールボックス：インタビュー → ランディングページ → フェイクドア → ウェイティングリスト → 予約販売。コストと信頼度が順に上がっていく。
- 最も硬いシグナルは「実際にお金を払う人がいる」こと。それを手にしたら調査をやめ、MVP を作り始める。
検証が通り、製品を作り始めた。次は応用編に入ります。まず本当に役立つマーケティングフレームワークをいくつか補強しましょう。それらはこの先のすべての集客アクションの土台となる思考になります。