個人開発のアイデア検証(書く前に勝負をつける)

一言まとめ

「半年作って誰も使わない」を避けるための、コードを書く前の検証手順。問題の存在確認、既存代替の確認、「今いくら使っているか」の確認、スモークテスト、手動 MVP の順に通し、5 名中 2 名以上が前向きで 1 名が先払いでも欲しいなら作る。

作成 · 更新 · #indie-dev#validation#mom-test#mvp
目次 7 sections
  1. 01 アイデアの源
  2. 02 検証の階段(書く前に通す)
  3. 03 やってはいけない検証
  4. 04 検証後のスコープ
  5. 05 価格の決め方
  6. 06 関連
  7. 07 更新履歴

調査時点: 2026-04。

アイデアの源#

  • 自分の痒み(Scratch your own itch): ユーザーインタビュー不要で、自分が顧客。最も強い。
  • 観察: 知人・SNS・フォーラムで「同じ愚痴を 3 人以上が言っている」題材。
  • 既存サービスの不満: Reddit / X / G2 / Capterra のレビュー欄。
  • 検索ボリューム: Google Trends / Ubersuggest / Ahrefs Free で「課題系キーワード」の検索数。
  • 狩場: 海外は Indie Hackers、Hacker News、Reddit(r/SaaS)、Product Hunt、Acquire.com の売却済み案件一覧。日本は Zenn、note、X の #個人開発、個人開発系 Discord。

検証の階段(書く前に通す)#

  1. 問題の存在確認: 5 人に「最近この件で困った?」を聞く。誘導しない(The Mom Test 流)。
  2. 既存代替の確認: 「今どうやって解決している?」。「Excel と気合」が最大の競合。
  3. 支払意思の確認: 「月いくら払う?」ではなく「今これに月いくら使っている?」を聞く。
  4. スモークテスト: LP 1 ページ + 事前登録フォーム + 広告 1 万円分。CTR と CV 率で判断する。
  5. Manual MVP(仮説の検証に必要な最小限の機能だけを備えた製品): 自動化せず手動で価値を提供して 3 顧客が取れるか。
  6. Concierge MVP: 自分が裏で全部手作業。スケールしないが「課金される商品か」が分かる。

判断基準: 5 名に紹介して 2 名以上が前向き、かつ 1 名が「先払いでも欲しい」なら作る価値がある。3 名以下なら題材を変える。

やってはいけない検証#

  • 友人・家族に聞く(社交辞令しか返らない)
  • 「あったら使いますか?」と聞く(誰でも YES と言う)
  • アンケート N=100(質問設計を間違えるとノイズだけ集まる)
  • 自分でビルドした後に検証する(サンクコストで判断が歪む)

検証後のスコープ#

  • 1 機能の SaaS が個人開発の最適解。Linear や Notion を真似ない。
  • 「やらないこと」を 10 個書く。後の機能追加要望を弾ける。
  • MVP は「これがないと売れない」機能の最小集合。3 週間で出せない MVP は MVP ではない。

価格の決め方#

  • 3 プラン提示で真ん中を選ばせる(例: $9 / $29 / $99)。
  • 無料プランは サポート工数が爆発し、有料転換率は通常 1〜3%。Free Trial(14 日)の方が個人開発向き。
  • 年契約 20% OFF でキャッシュフロー改善と解約率低下。
  • Flat(定額)は予測しやすく個人開発向き。Usage-based は価値と請求が連動するが Stripe Metering が要り複雑。
  • 自分が思う価格の 2〜3 倍が正解であることが多い。$5 で売る理由は買い手の財布を理解していないだけ、というのが先人の経験則。
  • 値上げは 6 か月ごとに検討し、既存顧客は据え置く(grandfather)。

関連#

更新履歴#

  • 2026-04-18: 初版(ローカル調査ノート)
  • 2026-10-17: Wiki へ移植、概念ページとして再構成

同じトピック — 個人開発