---
title: "個人開発のPMF検証ガイド — 最初の10ユーザーから何を聞き、何を直すか【2026年最新】"
description: "「リリースしたのに使われない」濃霧を抜けるPMF検証の型を、未達3サイン・10ユーザー7質問テンプレ・4分類マトリクス・4週間スプリントまで、ShiftB校長の一次情報で一気通貫解説します。"
url: "https://shiftb.dev/articles/indie-dev-pmf-validation"
publishedAt: "2026-05-01"
updatedAt: "2026-05-01"
author: "立川修平（ぶべ）"
category: "indie-dev"
tags: ["個人開発", "PMF", "ユーザーインタビュー", "検証", "リテンション"]
---

# 個人開発のPMF検証ガイド — 最初の10ユーザーから何を聞き、何を直すか【2026年最新】

「サービスを作ったのに、初日に来た数十人が二度と戻ってこない」「ユーザーから感想はもらえたが、何を直せば伸びるのか全くわからない」「友人に聞いたら『いいね』とは言われるが、誰もお金を払ってくれない」—— ShiftBの個人開発相談で、リリース直後の受講生がほぼ全員ぶつかるのがこの**PMF（プロダクトマーケットフィット）未達**の壁です。

個人開発の最大の落とし穴は、リリース直後に**「使われていないのに、その理由がわからない」**という濃霧の中に入ってしまうこと。集客を増やしても穴の空いたバケツに水を注ぐだけで、定着しないユーザーが増えるほど自信だけが削られていきます。

僕自身、**Vibely**というオンラインスクール向けSaaSを社内ツールから派生させ、**1年以上のPOC（社内検証）**を経てSaaS化しました。最初は「教材管理／受講生のブログ投稿／進捗管理」の3機能だけに絞り、機能の追加よりも**「最初の数十人の声を聞いて何を捨てるか」**の判断に時間をかけ続けたことで、build in publicでの事前登録50件以上、複数のオンラインスクールへの導入につなげました。一方で、過去には急行性向けの家庭教師マッチングサービスのように、**「ユーザーの声を取らずに自分の頭で機能を増やしたサービス」**は刺さらずに頓挫させた経験もあります。

この記事では、ShiftB校長として**受講生**の個人開発を伴走してきた経験と、僕自身が複数のサービスをリリース・撤退・成功させた一次情報をベースに、**PMF未達を見抜く3サイン／最初の10ユーザーから聞くべき7質問テンプレ／フィードバックを4分類して優先順位を決めるマトリクス／4週間スプリントの実行プラン**まで、再現性のある「PMF検証の型」を一気通貫で解説します。リリース直後の濃霧を抜ける具体的な道筋を、最後まで読めば必ず手に入ります。

## 個人開発が最初に死ぬ「PMF未達」とは何か

個人開発の生存率を最も大きく左右するのは、開発スピードでも技術選定でもありません。**「リリース後、PMF未達のフェーズをどれだけ早く正しく抜けるか」**です。ここで濃霧に迷い込んだ開発者は、9割が半年以内に手を止めます。

### PMF（プロダクトマーケットフィット）の定義

PMFとは、ベンチャーキャピタリストのマーク・アンドリーセンが提唱した概念で、**「市場が求めているプロダクトを、その市場に提供できている状態」**を指します。アンドリーセンは「スタートアップで重要なことは唯一PMFだけで、それ以外のすべてはPMF達成のための前段か、達成後の機能拡張にすぎない」と書いています。

この概念は元々スタートアップ向けに語られてきたため、個人開発者にとっては「自分には大げさすぎる」と感じられがちです。しかし、個人開発こそ**リソースが圧倒的に少ない**ぶん、PMFを意識せずに進めると簡単に詰みます。100人のチームなら「機能を10個試して2個当てる」ができますが、1人で運営する個人開発は**外せる球数が極端に少ない**のです。

### 個人開発のPMFは法人と何が違うか

個人開発のPMFは、法人スタートアップが目指すPMFとは目標水準が違います。VCマネーで動くスタートアップは「年商10億円規模に届くPMF」を目指しますが、個人開発で目指すべきはもっと小さく、もっと早く判定できるものです。

| 軸 | 法人スタートアップのPMF | 個人開発のPMF |
| --- | --- | --- |
| 市場規模 | TAM 1,000億円〜の大市場 | TAM 数億円のニッチでもOK |
| ターゲットユーザー | 幅広いセグメント | 自分も含む濃い数百〜数千人 |
| 判定までの期間 | 1〜3年 | 3〜6ヶ月（短サイクル前提） |
| 判定指標 | 急成長カーブ・調達倍率 | 定着ユーザー・有料転換・口コミ |
| 失敗時のコスト | 数千万〜数億円 | サーバ代と数ヶ月の時間 |
| 必要なPMFサイン | NPS50・40%ルール達成 | 10〜30人の濃いユーザーの定着 |

重要なのは、個人開発のPMFは**「自分も顧客でいい」「市場が小さくてもいい」「3ヶ月で見える」**という3点です。法人並みの基準で自分のサービスを見ると、ほぼ全プロダクトが「未達」と判定されてしまいます。個人開発の現場では、この基準を正しくスケールダウンして使う必要があります。

### 受講生で観測した「PMFしたサイン vs してないサイン」

ShiftB受講生の個人開発を伴走する中で、PMFに近づいているプロダクトと、そうでないプロダクトには非常に明確な差が現れます。以下は、受講生のリリース後3ヶ月時点での所感としてまとめた、典型的な対比の目安です（厳密な計測値ではなく、判定の指針として参考にしてください）。

| 観測項目 | PMFに近づいているサイン | PMF未達のサイン |
| --- | --- | --- |
| 初回登録ユーザーの再訪率 | 1週間後に40%以上が戻ってくる | 1週間後の再訪率が10%以下 |
| 口コミ発生 | 登録経路の3割以上が「友人紹介・SNS」 | 登録経路の95%以上が広告・自分の発信 |
| ユーザーからの能動的フィードバック | 聞かなくても要望が届く | こちらから聞かないと何も来ない |
| サポート問い合わせの質 | 「機能追加してほしい」が多い | 「使い方がわからない」「動かない」が大半 |
| 有料転換率 | ターゲット層に絞ると2〜10% | 誰も払わない、または払うが即解約 |

左列のサインが2つ以上揃っていれば、PMFに「近づいている」と判定して伸ばすフェーズに進めます。逆に右列に該当する項目が3つ以上あれば、それは**集客を強化するフェーズではなく、検証を回すフェーズ**です。穴の空いたバケツを集客で埋めようとせず、まずバケツを直す方が圧倒的に投資対効果が高いということです。

## PMF未達を見抜く3つのサイン — 数字で測る

定性的な観察だけでは、自分のプロダクトを正しく判定できません。開発者は自分のサービスに愛着があるため、どんな状況でも「あと一押しでいけそう」と感じる認知バイアスが働きます。これを乗り越えるには、**数字で見るPMF未達のサイン**を3つだけ覚えておけば十分です。

![PMF未達を見抜く3つのサイン：リテンションカーブ、Sean Ellis Test、口コミの自然発生](https://shiftb.dev/images/articles/indie-dev-pmf-validation-three-signs.png)

### サイン1: リテンションカーブが横ばいにならない

最も信頼できるPMFの先行指標が**リテンションカーブ**です。これは「Day0に登録したユーザーが、Day1・Day7・Day30…でどれだけ戻ってきているか」をプロットしたグラフのこと。PMFに近いプロダクトでは、このカーブが**ある時点で横ばい（プラトー）になります**。横ばいになった水準が、そのプロダクトの「コアユーザーの濃度」です。

逆にPMF未達のプロダクトでは、リテンションカーブはひたすら下に落ち続け、Day30〜Day60あたりで0%付近に着地します。つまり登録した全員が時間とともに離れていく状態です。

| 計測タイミング | PMF近い | PMF未達 | 判定の目安 |
| --- | --- | --- | --- |
| Day1 | 50〜70%が再訪 | 10〜20% | 初回体験の質 |
| Day7 | 30〜45%が再訪 | 5%以下 | 習慣化の入口 |
| Day30 | 20〜35%で横ばい開始 | 1〜2% | コアユーザーの存在 |
| Day60 | Day30とほぼ同水準 | 限りなく0に近い | 定着の確定 |

個人開発の現場では、Day7が10%を下回り、かつDay30が3%以下になっていれば、それは**「集客より先に、何かを直すべき状態」**です。このシグナルを無視して新規登録を増やしても、定着率は変わらず、サーバ代だけが増えていきます。

### サイン2: Sean Ellis Test 40%ルールを下回る

スタートアップ業界で最も有名なPMF判定法が、Dropbox初期グロースを担ったSean Ellisが提唱した**40%ルール**です。実際のユーザーに対して、たった1問の質問をします。

> 「もしこのサービスが今日から使えなくなったら、あなたはどう感じますか？」  
> a. 非常に残念（耐えられない）  
> b. やや残念（不便だが我慢できる）  
> c. 特に何も感じない（他で代替できる）

この質問で**「a. 非常に残念」と答える割合が40%以上**になればPMF達成、というのが古典的な閾値です。Buffer社が公表している検証では、回答数は40〜50人もあれば統計的な傾向が見えるとされており、個人開発でも十分実施可能な規模です。

個人開発で実施する場合のコツは2つ。1つ目は、対象を**「コア機能を最低2回は使ったユーザー」**に絞ること。1度しか使っていない人に聞くと、当然多くは「特に何も感じない」と答え、結果が歪みます。2つ目は、**「a」を選んだ人には必ずフォローアップ質問を続ける**こと。「具体的にどの場面で困りますか？」「代わりに何を使いますか？」と聞くと、コアバリューの正体が浮かび上がります。

### サイン3: 口コミが自然発生していない（NPS批判者超過）

3つ目のサインは**「サービスがユーザーの口から自然に語られているか」**です。これは定量化できる指標としてNPS（Net Promoter Score）が便利ですが、個人開発の小規模なユーザー基盤では、もっとシンプルに観察できます。

- 新規登録の経路に「友人から聞いた」「Xで誰かが紹介していた」が一定割合で混じっているか
- SNSでサービス名を検索したとき、自分以外の投稿が出てくるか
- ユーザーから「友人にも勧めたい」「招待コードはありますか」と能動的に聞かれるか

この3つすべてが「ノー」なら、たとえ登録ユーザーが数百人いても、それは「広告で集めただけの観客」であってコミュニティではありません。PMF達成プロダクトの大きな特徴は、自分が止まっても**口コミが回り続ける**ことです。逆にPMF未達のうちは、運営者が手を動かし続けないと登録数も即座にゼロに落ちます。

僕自身、自社サービスを運営する中で、この口コミシグナルの重要性を痛感しました。ある時期から「知人に勧められて」という導線が自然発生するようになり、そこから伸び方が変わりました。それまでの「自分の発信頼みの集客」のフェーズと、口コミが回り出したあとでは、運営の体感が全く違いました。

## 最初の10ユーザーから聞くべき7質問テンプレ

PMF未達のサインを掴んだあとにやるべきは、**「最初の10ユーザーから生の声を聞き、何を直すべきかの仮説を立てる」**ことです。ここを「アンケート」で済ませようとすると失敗します。アンケートは仮説の裏取りには使えても、仮説そのものを生み出す力は弱いからです。

### Mom Test の鉄則3つ — 嘘を引き出さない聞き方

スタートアップの古典『The Mom Test』（Rob Fitzpatrick著）で語られている有名な原則があります。タイトルの由来は「自分の母親に『私のアイデアどう思う？』と聞いたら、絶対にお世辞しか返ってこない」という現実です。これは個人開発の身内ヒアリングでも全く同じ罠が起こります。

Mom Testの3つの鉄則を、個人開発のヒアリング向けにまとめると次のとおりです。

1. **自分のアイデアではなく、相手の人生を聞く**：「私のサービスどう思う？」ではなく「最近、◯◯で困った場面ありますか？」
2. **未来の仮定ではなく、過去の具体を聞く**：「使いますか？」ではなく「直近でその問題に直面したのはいつでしたか？」
3. **意見ではなく、行動と事実を聞く**：「あったらいいと思いますか？」ではなく「今その問題、どうやって解決していますか？お金を払っていますか？」

この3つを守ると、相手の「お世辞」が引き出されにくくなり、**本人すら言語化できていなかった行動の事実**が浮かび上がります。個人開発の検証で本当に欲しいのはこの「事実」であって、「意見」ではありません。

### 7質問テンプレ — そのままコピペで使える

以下は、ShiftBで僕が受講生に勧めている「最初の10ユーザーヒアリング7質問」です。30分のオンライン通話で全部聞き切れる分量に収めてあります。

1. **Q1. 直近でこの問題に直面したのはいつ、どんな場面でしたか？**  
   → 過去の具体エピソードを引き出す。「最後に困ったのは1ヶ月以上前」と返ってきたら、痛みが弱い証拠。
2. **Q2. その問題、現在はどうやって解決していますか？**  
   → 既存代替手段を聞く。「Googleスプレッドシート」「メモ帳」「諦めている」など、答えがない問題は潜在ニーズが弱い。
3. **Q3. その代替手段で、特に不便なのはどこですか？**  
   → 自分のプロダクトが解決すべき具体的な摩擦点を特定する。
4. **Q4. これまでこの問題を解決するために、お金や時間を投資したことはありますか？**  
   → ペイン強度の判定。財布を開いた経験があれば本物のペイン、なければ「気になっているだけ」のレベル。
5. **Q5. 私のサービスを実際に使ってみて、どこでつまずきましたか？**  
   → オンボーディング上の障害を直接聞く。「特になかった」と返ってきたら追加で「最初の3分で何がわかりにくかったですか？」と深掘りする。
6. **Q6. 今このサービスが明日からなくなったら、どう感じますか？**  
   → Sean Ellis Testの実質版。表情と即答性も観察する。
7. **Q7. 最後に、このサービスを誰に紹介したいと思いますか？具体的に誰の顔が浮かびますか？**  
   → 「特に思いつかない」なら口コミは絶対に回らない。具体的な人名・属性が出てきたら、ターゲット像が一気にシャープになる。

### 良い質問・悪い質問の対比表

以下は、ヒアリングで「お世辞しか引き出せない悪い質問」と「事実を引き出す良い質問」の対比です。同じ知りたい内容でも、聞き方一つで返ってくる情報の質が大きく変わります。

| 知りたいこと | 悪い質問（NG） | 良い質問（OK） |
| --- | --- | --- |
| ペインの強度 | この問題ってよく困りますか？ | 最後にこの問題で困ったのはいつ、どんな場面でしたか？ |
| 支払意志 | 月◯円なら払いますか？ | いまこの問題を解決するために、何かにお金を使っていますか？ |
| 機能優先度 | この機能あったら使いますか？ | いまの代替手段の中で、一番イラッとする瞬間はどこですか？ |
| 差別化要素 | うちのサービスのどこが好きですか？ | 類似サービスを試したことありますか？やめた理由は？ |
| 口コミ可能性 | 友達に勧めたいと思いますか？ | このサービスを紹介するなら、具体的に誰の顔が浮かびますか？ |

### 30分ヒアリングの進め方

30分の枠で7質問を聞き切るには、構成を固定するのが鉄則です。僕が受講生に教えているのは以下の時間配分です。

- **0〜3分：**アイスブレイク。「今日はサービスの宣伝じゃなく、◯◯さんの普段の業務を教えてもらう時間です」と先に宣言する
- **3〜13分：**Q1〜Q4（過去の行動と既存代替の事実集め）
- **13〜23分：**Q5〜Q6（自社プロダクト体験とSean Ellis質問）
- **23〜28分：**Q7と、相手から自由に話してもらう余白
- **28〜30分：**お礼と、追加で連絡してもよいかの許可取り

重要なのは、ヒアリング中に**絶対に自分のサービスを売り込まないこと**。売り込みが入った瞬間に、相手のモードが「お世辞モード」に切り替わり、その後の発言の信頼性が大きく落ちます。商談ではなく取材だと割り切ってください。

## 集めたフィードバックを4分類して優先順位を決める

10人ヒアリングをすると、相応のボリュームのフィードバックが手元に集まります。ここで多くの個人開発者がやりがちな失敗が、**「全部対応しようとして全部中途半端になる」**というもの。フィードバックは集めるよりも、捨てる方がはるかに難しい仕事です。

### 4分類マトリクス — 重要度 × 頻度の2軸

ShiftBで受講生に教えているのは、フィードバックを2軸で4象限に切る方法です。「重要度（解決したらユーザー価値が大きく変わるか）」と「頻度（何人から同じ声が出たか）」の2軸でマッピングします。

![フィードバック4分類マトリクス：重要度×頻度の2軸で優先順位を決める](https://shiftb.dev/images/articles/indie-dev-pmf-validation-feedback-matrix.png)

| 象限 | 重要度 | 頻度 | 判断 | 例 |
| --- | --- | --- | --- | --- |
| ① 即対応 | 高 | 高（3人以上） | 今週中に直す | コア機能のバグ・離脱原因のUI |
| ② 観察 | 高 | 低（1〜2人） | 今後同じ声が出るか追跡 | 特定セグメントだけの強い要望 |
| ③ あとで | 低 | 高（3人以上） | バックログに置く | 表示の好み・トーンの揺れ |
| ④ 捨てる | 低 | 低（1〜2人） | 記録だけして忘れる | 1人の特殊事情・個人的な好み |

個人開発でリソースを集中すべきなのは**①と②だけ**です。③は1スプリント先まで凍結、④は記録するだけで実装しない。これを決めるだけで、開発の指向性が劇的に整います。

### 受講生Aさんの議事録自動化ツールでの分類例

ShiftBで議事録自動化ツールを開発した受講生Aさん（28歳・元営業職）の事例で、4分類の実践イメージを共有します。Aさんはリリースから2週間ほどかけて10名前後にヒアリングを実施し、出てきた数十件のフィードバックを4分類マトリクスに落とし込んでいきました。

- **① 即対応：**「30分以上の音声で処理が止まる」「Slack連携で改行が崩れる」など、コア機能の品質に直結する問題。すべて翌週の1スプリントで修正。
- **② 観察：**「営業の同行議事録に欲しい話者ラベル機能」など、強い要望だがまだ1〜2人。次のヒアリングで再頻出するか追跡対象とした。
- **③ あとで：**「ダークモード対応」「フォント変更」など、好みの問題。後日まとめて対応するバックログへ。
- **④ 捨てる：**「特定の方言の精度を上げてほしい」「自分の業界用語の辞書を全件登録できるように」など、個別性が強すぎる要望。記録のみ。

Aさんの場合、①に分類された一握りのコア課題を1〜2週間で潰したことで、再訪率の手応えが目に見えて変わったと振り返っていました。**全フィードバックのうちわずかな割合に集中したことが、定着率を動かす引き金**になったのです。

### 「捨てる勇気」が必要な3パターン

4分類で判断に迷ったとき、特に**「捨てる」と決めるべき3つの典型パターン**を覚えておくと判断スピードが上がります。

1. **1人だけが熱狂的に語る要望**：強烈なフィードバックほど印象に残るが、N=1は基本的にプロダクトの方向性を歪める。10人中1人にしか刺さらない機能を作ると、9人にとって複雑なだけのプロダクトになる。
2. **「あったらいいな」レベルの要望**：本人が現在その問題を回避するために何のコストも払っていない要望は、実装してもユーザーは喜ばない。Q4（投資経験）でゼロ回答だった要望は基本的に④。
3. **ターゲット外のユーザーからの要望**：そもそも自分のサービスのコアターゲットではない人の声に応えると、ターゲットがブレる。「誰のためのサービスか」を最初に固めて、それ以外の声は丁寧に④に回す。

僕自身、過去にグルメ系サービスを開発したとき、影響力のあるインフルエンサーの意見を取り入れすぎてコア機能が薄まり、UIが複雑化、結果としてメンテナンス負担だけが増えてサービスを終了した経験があります。フィードバックを取れば取るほど、捨てる判断の重要性は増していきます。

## PMF検証の実行サイクル — 4週間スプリント

ここまでの内容を、実際にどう日程に落とすか。ShiftBで受講生に勧めているのが**「4週間スプリント」**です。1スプリントで1サイクル回し、達成度を見て次のスプリントの方向を決めます。期限を切らないと、検証は無限に伸びます。

![PMF検証の4週間スプリント：Week1集める→Week2聞く→Week3直す優先順位→Week4修正と再計測](https://shiftb.dev/images/articles/indie-dev-pmf-validation-4week-sprint.png)

### Week 1：10人を集める

最初の1週間は、ヒアリング対象10人をリストアップして打診する週です。完璧なリストより、まず動き出すことの方が重要です。

- **すでに使っているユーザー：**登録ユーザーから能動的に話してくれそうな人を5人選ぶ
- **X（Twitter）DM：**ターゲット属性のフォロワーに「30分話を聞かせてほしい」と打診
- **Discord/Slackコミュニティ：**ShiftBコミュニティのような開発者コミュニティで募集
- **友人の友人：**身内ではなく「身内の身内」がベストバランス（しがらみが少なく、ある程度本音が出る）

打診時の文面では、必ず**「サービスの宣伝ではなく、業務や課題を聞きたい」**と明示すること。「うちのサービスを試してください」モードの打診は商談になりやすく、Mom Testの鉄則を破る原因になります。

### Week 2：インタビューと数値計測を並行

2週目は、Week1で約束を取り付けた10人と実際に話す週です。1日2人ずつのペースで進めると、5日で完走できます。インタビューと並行で、必ず以下の数値も計測しておきます。

- Day1・Day7・Day30のリテンションカーブ
- 離脱が最も多い画面・ステップ（GA4のファネル）
- Sean Ellis 40%ルールのアンケート（既存ユーザーに送付）
- 有料転換率（該当する場合）

定量データと定性データを同時に集めるのがポイントです。インタビューで聞いた「ここでつまずいた」がGA4のファネルでも観測されているなら、それは間違いなく直すべきポイント。逆に、声には上がっているけれどデータには出ていない離脱は、ヒアリング対象の偏りを疑う必要があります。

### Week 3：4分類して直す優先順位を決める

3週目はインタビューが一段落し、フィードバックを4分類マトリクスに落とし込む週です。1人で抱え込まず、ShiftBコミュニティのような第三者の目を入れると、捨てる判断が圧倒的に楽になります。

- 全フィードバックを書き出す（NotionやSpreadsheetでOK）
- 2軸でマトリクスに配置する
- ①と②に入ったものだけを「Week4でやること」リストに転記
- ③と④は別シートに退避（あとで見返したくなるが見ない）

### Week 4：修正と再計測

最後の週は、Week3で決めた①の項目を実装し、リリースし、再計測する週です。理想は週の前半で実装、後半で計測という配分。再計測の目的は2つ。

1. 修正したポイントの数値が改善したか（ファネル離脱の減少）
2. 新しいユーザーで再度ヒアリングしたとき、同じ問題が再発しないか

この4週間のサイクルを**3〜4回（=3〜4ヶ月）繰り返す**と、ほぼ確実にPMF達成かピボット判定の結論に到達します。決して「半年経ってもよくわからない」状態にはなりません。期限とプロセスがあれば、結論は必ず出ます。

### ぶべがVibelyで「3機能だけに絞った」経緯

この4週間スプリントの考え方は、僕がVibelyを社内ツールから派生させたときの実体験から組み上げたものです。Vibelyは元々ShiftB社内で1年以上使い込み、数十のオンラインスクール運営者にヒアリングを重ねた上で、SaaS化に踏み切りました。

当初は10個以上の機能アイデアがありましたが、ヒアリングを重ねた結果**「教材管理」「受講生のブログ投稿」「進捗管理」の3つだけ**に絞り込みました。これは「①即対応」と「②観察」だけを残し、「③あとで」「④捨てる」を徹底的に切り落とした結果です。MVPの段階で機能を並列に増やさず、コア機能を磨く判断ができたのが、build in publicでの事前登録50件以上、複数のオンラインスクール導入につながった一番の要因だったと感じています。

逆に、PMF検証フェーズで「全部やろう」とした過去のプロジェクト（家庭教師マッチング・グルメ系サービスなど）は、ことごとく頓挫しました。3回SaaSに失敗してから今のVibelyに辿り着いた経験から言えば、捨てる勇気こそが個人開発のPMFを決めるレバーです。

## PMF検証でやりがちな7つの失敗パターン

ShiftBで受講生の個人開発を伴走する中で、PMF検証フェーズの失敗には強烈な再現性があることがわかってきました。以下の7パターンに当てはまっていないか、自分のプロダクトを照らし合わせてみてください。

### 失敗1：身内にしか聞かない

家族・友人・職場の同僚は、ほぼ全員がお世辞を返します。「いいね」と言われても「お金を払うか？」「明日も使うか？」は別問題。Mom Testの教えを思い出してください。最初の10人のうち、最低でも7人は**身内の身内（=知人の知人）レベル以上の遠さの相手**にすべきです。

### 失敗2：意見を聞いて行動を聞かない

「あったら使いますか？」は最も無意味な質問です。多くの人は「あったら使う」と言いますが、実際にお金や時間を払うかは別。**過去の具体行動**だけが信頼できる情報です。「最後にこの問題で困ったのはいつ？」「いまどうやって解決していますか？」「お金を払ったことはありますか？」の3つを必ず聞くこと。

### 失敗3：機能要望をそのまま実装する

ヒアリングで「◯◯機能が欲しい」と言われると、嬉しくて即実装したくなりますが、これは罠です。要望の裏にあるのは**「解決したい本当の課題」**であって、提案された機能ではありません。要望が出たら必ず「なぜそれが欲しいんですか？」「それがあると、いま何ができないことができるようになりますか？」と深掘りする。同じ課題に対して、もっと小さく解決できる別解が見つかることが多いです。

### 失敗4：N=1の声に振り回される

強烈なフィードバックほど印象に残りますが、N=1は基本的にプロダクトの方向性を歪めます。1人だけが熱狂的に語る要望に応えた結果、他の9人にとっては複雑なだけのプロダクトになる。4分類マトリクスの④（捨てる）にしっかり振り分ける勇気が必要です。

### 失敗5：集客で問題を解決しようとする

「使われない＝認知が足りない」と判断して、広告やSEOにリソースを投下する誘惑は強いです。しかしリテンションが10%以下のプロダクトに集客しても、穴の空いたバケツに水を注ぐだけ。**Day7リテンションが20%を超えるまで、集客は最低限に絞る**べきです。先に直す、伸ばすのは後。順番を間違えるとサーバ代が無駄に増えます。

### 失敗6：定量だけ・定性だけに偏る

GA4のダッシュボードだけを見て判断する人と、ヒアリングだけに時間をかける人、どちらも片手落ちです。定量データは「どこで離脱しているか」は教えてくれますが「なぜ離脱しているか」は教えてくれません。逆にヒアリングは「なぜ」は教えてくれますが、対象の偏りを補正できません。両方を必ず併用することがPMF検証の鉄則です。

### 失敗7：期限を切らずに検証を続ける

4週間スプリントの一番の存在意義は、**「結論を出す期限を強制すること」**です。期限を切らないと、人は「もう少し、もう少し」と検証を引き延ばし、半年経っても結論が出ない。3〜4スプリント（=3〜4ヶ月）回してもPMFのサインが出なければ、それは「ピボットすべき」というシグナル。撤退判断もPMF検証の重要な成果物です。

### 失敗パターンチェックリスト

最後に、自分のPMF検証が罠にハマっていないかを確認するチェックリストを置いておきます。

- ヒアリング対象の7割以上が身内の身内（以上の距離）になっているか
- 過去の具体行動を聞く質問（Q1〜Q4）が必ず入っているか
- 機能要望を「なぜ？」で1段以上深掘りしているか
- N=1の強い声を、勇気を持って④に振り分けられているか
- Day7リテンションが20%を超える前に集客に投資していないか
- 定量（GA4）と定性（ヒアリング）を両方見ているか
- 3〜4ヶ月で結論を出すと自分に約束しているか

このチェックで2つ以上「ノー」がある場合、PMFが見えない原因はプロダクトではなく検証プロセスの設計です。プロセスを直せば、見えなかったものが見えるようになります。とはいえ、これを1人で完璧に回し切るのは正直かなり難しい——というのが、受講生を伴走してきての偽らざる実感です。

## PMF達成後にやること — 次の一歩

4週間スプリントを3〜4回繰り返し、Day7リテンションが安定して30%を超え、Sean Ellis 40%ルールも近い水準に到達したら、次のフェーズに進む合図です。PMF達成後にやるべきことは、PMF前とは性質が大きく変わります。

### 1. リテンションの最適化

PMF達成は「終わり」ではなく「成長の前提条件が揃っただけ」です。次にやるべきは、コアユーザーの体験をさらに磨き、リテンションを30%→50%へと押し上げること。とくに重要なのが**オンボーディング設計**と**解約率（チャーン）対策**です。最初の3分でユーザーをコア体験に到達させる導線、解約直前のユーザーへのオファー、休眠ユーザーへの再活性化メールなど、伸ばしどころは無数にあります。

### 2. 価格設定の調整

PMF未達のうちは「無料で配って試してもらう」が基本ですが、PMFが見え始めたら必ず**価格を取る**フェーズに入ります。無料で提供し続けるのは運営の安定性を破壊します。価格はサービスを存続させるための燃料であり、ユーザーが本当に価値を感じているかの最強のテストでもあります。低めの価格で始めて、有料転換率と解約率の動きを見ながら半年ごとに見直していくのが安全です。

### 3. 集客チャネルの拡大

PMF達成後はじめて、集客に大きくレバレッジを効かせて意味があるフェーズに入ります。SEO、有料広告、コミュニティパートナーシップ、紹介プログラムなど、チャネルを並列に試して、CACが回収できるものに絞り込んでいきます。PMF前に集客を強化するのは穴の空いたバケツに水を注ぐ行為ですが、PMF後は「集めれば集めるほどLTVが積み上がる」状態。順番を守ることで、同じ施策でも効果が10倍以上違います。

### 4. プライシング戦略・リテンション・オンボーディングの参考記事

PMF達成後の各テーマについては、ShiftBでそれぞれ専用の記事を用意しています。次の一歩を踏み出すときの参考にしてください。

- [個人開発のオンボーディング設計完全ガイド](https://shiftb.dev/articles/indie-dev-onboarding-design)：最初の3分でユーザーを離脱させない6ステップ
- [個人開発のリテンション・解約対策完全ガイド](https://shiftb.dev/articles/indie-dev-retention-churn)：サブスク継続率を上げる7つの実装パターン
- [個人開発のプライシング戦略入門](https://shiftb.dev/articles/indie-dev-pricing-strategy)：価格を取る判断と価格設定の実践
- [個人開発のグロースハック入門](https://shiftb.dev/articles/indie-dev-growth-hack)：0→1,000ユーザー達成ガイド
- [個人開発のリリース戦略](https://shiftb.dev/articles/indie-dev-launch-strategy)：成功するローンチ完全ガイド（PMF検証の前段）

## よくある質問（FAQ）

### Q1. PMFが達成できているか、自分で正確に判定する自信がありません。どうすれば？

判定に絶対的な正解はないので、複数のサインを合わせて判断するしかありません。本記事の3サイン（リテンションカーブの横ばい・Sean Ellis 40%・口コミの自然発生）のうち、2つ以上が達成されていれば「PMFに近い」、3つすべてなら「PMF達成」と暫定的に判定して問題ありません。第三者の目を入れたい場合は、開発者コミュニティで定期的にデータをシェアして客観的なフィードバックをもらうと、自分だけでは見えていなかった指標の歪みが浮かび上がります。

### Q2. ヒアリング対象の10人を集められません。どうしたらいいですか？

最初の10人を集めるのは、開発そのものより難しいことがあります。コツは、いきなり「インタビューさせてください」とお願いするのではなく、普段からSNSやコミュニティで自分のサービスのターゲットと交流する関係性を作っておくこと。X（Twitter）でターゲット属性の人をフォローして反応する、ShiftBやインディーハッカーズのようなコミュニティに参加する、関連するMeetupに足を運ぶ、といった日常的な関係構築が効きます。一度ゼロから10人集めようとすると大変ですが、普段からの種まきがあれば、声をかければ5〜7人はすぐに集まります。

### Q3. リテンションを正確に計測する仕組みがまだありません。最低限何があればいいですか？

最低限、Google Analytics 4（GA4）と、自社プロダクトのデータベースで「ユーザーIDごとの最終アクセス日時」が取れていれば、Day1・Day7・Day30のリテンションは算出可能です。プロダクトに登録機能があるなら、SQLで「初回登録日と直近アクセス日の差」を集計するだけで十分。BigQueryやMetabaseのようなツールがなくても、Spreadsheetで月次に手動集計でも問題ありません。最初は完璧な計測基盤よりも、最低限のデータで毎週ループを回すことが優先です。

### Q4. PMFを目指すフェーズで、機能追加とバグ修正どちらを優先すべきですか？

基本的にバグ修正が先です。コア機能のバグは、ユーザーがコアバリューに到達する前の障害物。これがある限り、新機能を追加してもユーザーには届きません。バグが「即対応」と判定された場合、ほぼ例外なく今週中に修正を入れる優先度になります。新機能は4分類マトリクスで②に入ったものだけを、コア体験を強化する目的に絞って追加するイメージです。「全部直す」と「全部入れる」を両立しようとすると、結局どちらも中途半端になります。

### Q5. PMF検証中、SNSやマーケティングはどこまでやるべきですか？

PMF未達フェーズでは、マーケティングはヒアリング対象を集めるための最小限に絞るのが賢明です。具体的には、X（Twitter）で開発の進捗をbuild in publicで発信し、ターゲット属性の人と関係を作る程度。広告予算を投下したり、本格的なSEOコンテンツに時間を割くのは、リテンションが安定して20%を超えてからで十分間に合います。集客は伸ばす力が強いぶん、PMF前にやると未達の事実を覆い隠してしまう副作用があるので注意してください。

### Q6. 4週間スプリントを3回回しても、PMFのサインが見えませんでした。どう判断すべきですか？

その場合、ピボットを真剣に検討すべきタイミングです。ピボットといっても、プロダクトをゼロから作り直すという意味ではなく、ターゲット顧客・コアバリュー・課金モデルのどれかを大きく変える決断のこと。3スプリント回した蓄積として、「どの層の誰には刺さりかけていたか」「どの代替手段に勝ちかけていたか」のデータが手元にあるはずです。それを起点に、ターゲットを2割狭めて再検証する、課金モデルを買い切りからサブスクに変える、などの方向転換を試します。完全な撤退判断もPMF検証の正当な成果のひとつです。

### Q7. 1人で全部やるのが難しいです。どこから手をつければいいですか？

最も効果が大きいのは「最初の10人ヒアリング」です。技術的な実装より、ヒアリングの方が個人開発者は苦手意識を持ちやすいので、ここに最初の1週間を全力で投下するのが結果的に最短ルートです。1人で抱え込まず、ShiftBのようなコミュニティでヒアリング結果を共有し、第三者の目を入れて4分類するのもおすすめ。同じデータを見ても、自分1人では「捨てる」と判断できなかったものが、他者の視点を入れると驚くほどスッパリ切れることがあります。

## まとめ — PMF検証は「速く失敗して速く学ぶ」ためのプロセス

個人開発のPMF検証は、見落とされがちですが、リリース後の生死を分ける最も重要なフェーズです。本記事の要点を改めて整理します。

- **個人開発のPMFは法人と違う：**市場が小さくてもいい、自分も顧客でいい、3〜6ヶ月で見える
- **未達を見抜く3サイン：**リテンションが横ばいにならない／Sean Ellis 40%未満／口コミが自然発生しない
- **最初の10ユーザーから聞く7質問テンプレ：**過去の具体行動を聞き、未来の仮定や意見は聞かない
- **フィードバックは4分類で捨てる：**重要度×頻度の2軸、①と②だけにリソースを集中する
- **4週間スプリントで結論を強制：**Week1集める→Week2聞く→Week3決める→Week4直す
- **失敗パターンを避ける：**身内バイアス・意見ベース・集客で誤魔化す・期限を切らない、を回避
- **PMF後は順番を守る：**リテンション最適化→価格→集客拡大、の順で投資する

PMF検証は「正解を当てに行く」プロセスではなく、**「速く失敗して速く学ぶ」**プロセスです。3〜4ヶ月のサイクルで結論を出し、達成ならその先のグロース、未達ならピボット、どちらに転んでも次のステップが明確になります。リリース直後の濃霧を抜け出す具体的な道筋を、まずは今週の最初の1人ヒアリングから始めてみてください。