「作ったのに、誰にもお金をもらっていない」
Tomoya先に答えます。
個人開発の最初の収益化は、機能を増やすことではなく、
課題1つに絞ったオファー、最小の課金導線、1対1で最初の有料ユーザーを取ることです。
読む時間は約10分です。
ポイントは次の3つです
- 何を売るかは「少数が強く欲しい」課題1つに絞る（Paul Graham「How to Get Startup Ideas」）。
- 最小の課金導線は、ボタン→Checkout Session→Stripeホストの支払いページ（Stripe Checkout quickstart）。
- 最初の有料ユーザーは、待たずに手動で集める。Collison installationの発想で、初期は非スケールでよい（「Do Things that Don’t Scale」）。
分かりやすく言うと
最初の課金は「店を大きくする工事」ではなく、「レジを1台置くこと」です。
棚を増やす前に、誰かが払える場所を作ります。
何を売るか。オファーの絞り方
Paul Grahamの「How to Get Startup Ideas」は、
スタートアップアイデアを机上で考えるな、問題を探せ、と書きます。
理想は、自分自身が欲しい・自分で作れる・まだあまり気づかれていない、の重なりです。
ここで個人開発に効くのは「井戸（well）」の形です。
多くの人が少し欲しがる浅い穴ではなく、少数が強く欲しがる深い井戸を選べ、とあります。
最初のユーザーは「いつか使うかも」ではなく、「荒いv1でも今すぐ使う」人である必要があります。誰が、どれほど切迫して欲しいかを答えられないアイデアは、たぶん弱い、というチェックです。
Tomoya手順は次の3つです。
- 自分が毎週つまずいている課題を1つ書く（製品カテゴリ名ではなく、困っている瞬間の文）。
- 「荒いv1でも今すぐ払う／使う人」を実名で3人まで想像する（匿名の「みんな」は禁止）。
- 売る単位を1つに落とす。例: 「週次の優先メール仕分けBotの月額」や「特定画面のデバッグ相談1回」など、機能カタログにしない。
具体例：「AIで何でもできるBot」は浅い穴側です。
一方「毎朝、未読のうち今日返す3通だけを優先度付きで返す」は、特定の人が荒いv1でも欲しがりやすい井戸側です。
売る文は機能一覧ではなく、その一文の結果です。
| 条件 | 行動 |
| 「便利そう」としか言われない | オファーを狭めるか、別の問題に移る |
| 荒い版でも使う人がいる | その1課題だけで有料化する |
| 機能を足せば売れる気がする | 足す前に、今のv1で誰が払うかを先に聞く |
筆者の感想
私も使ってもらいたいが先行したことで対象があいまいになって結局誰にも使われない状態になることがあります。この場合は、ユーザーからは浅い井戸としか見られておらず、私の問題ではないと解釈され他を探しに離脱、又は記憶にも残らないで消化されていくのが関の山です。
このことを踏まえて万人に受けそうな浅い井戸ではなく、特定の数人にリーチできそうなプロダクトを求めて開発するように心掛けています。
最小の課金導線。Stripe Checkout
オファーが1つ決まっても、支払いページが無いと「最初の1円」は起きません。（Stripe公式の Checkout quickstart は、サイト上のボタンから Stripe がホストする支払いページへ送る最小構成を示します。）
流れは次のとおりです。
- サーバーに Checkout Session を作るエンドポイントを置く。
- Session に line_items（Price ID など）、success_url、mode を渡す。
- 返ってきた `session.url` へ顧客をリダイレクトする。
- 成功後は success ページで確認メッセージを出す。履行（提供開始）は支払い成功を待ってから、と公式も案内します。
個人開発で最初に迷いやすいのは、自前のカード入力画面を作り始めることです。quickstartの骨格は「自前フォーム」ではなく、ホストされた支払いページへのリダイレクトです。見た目の作り込みは、有料1人のあとで十分です。
mode（取引の種類）は公式どおり次の3つです。
| mode | 用途 |
| payment | 一回払い |
| subscription | 継続課金 |
| setup | 将来の支払いに備えたセットアップ |
価格や在庫の機微情報はクライアントに置かずサーバー側で定義する、と quickstart は注意します。
個人開発の最初は、ダッシュボードで Price を1つ作り、ボタン1つで Session を作るところまでで十分です。カスタムUIの自前カードフォームは、後回しで構いません。
最初の有料ユーザーの取り方。1対1と非スケール
導線があっても、待っているだけでは始まりません。
Paul Grahamの「Do Things that Don’t Scale」は、初期は手動でユーザーを集めよ、と繰り返し書きます。
Stripeですら初期は積極的に取りに行った、という文脈です。
YC内の「Collison installation」は、その象徴です。
「ベータ試しますか？」に Yes と言われてリンクを送るのではなく、「ではその場でノートを貸して」とセットアップまでやる、というやり方です。
個人開発に翻訳すると、DMや通話で画面を共有し、その場でアカウント作成と最初の課金（またはトライアル開始）まで伴走する、という意味になります。
数字が小さく見えても、初期の成長は週次の複利で見る、という話も同エッセイにあります。
最初の成功定義を「有料1人」に置く理由はここにあります。
手順は次の3つです。
- オファーに合う知人・同僚・同じ悩みのコミュニティから、候補を5人まで書き出す。
- 「売ります」より先に、「その課題で毎週何に時間を溶かしているか」を聞く。
- Yes が出たら、リンク放置にしない。通話か画面共有で、Checkoutまで一緒に進める（Collison installationの個人開発版）。
同エッセイは、初期の脆さを標準の大企業と比べて自分で切り捨てるな、とも書きます。
有料1人は小さく見えます。それでも、フィードバックが一番濃い時期でもあります。スケールしない手作業は、後で自動化するための筋肉記憶を残すための段階です。
| 条件 | 行動 |
| 反応が薄い | オファー文を狭める。機能追加で逃げない |
| 「あとで見る」で止まる | その場セットアップの時間を取る |
| 1人が払った | その1人の使い方を観察し、次の1人へ同じ手順を繰り返す |
大きなローンチや提携で一気に伸ばそうとするのは、同エッセイが疑う初期戦術です。最初に必要なのは、少数に圧倒的に良い体験を渡すことです。
ここで迷いやすい点
- 副業おすすめ10選を読んでも、自分のオファーは決まらない。
- 月収の未検証数字を成功定義にしない。ここでは有料ユーザー1人。
- ChatGPT Plusや特定IDEの課金を、製品の収益化と混ぜない。
- Checkoutを綺麗にする前に、誰に売るかを空欄のままにしない。
まとめと次の行動
- 売るものは、少数が強く欲しい課題1つ
- 導線は Stripe Checkout のボタン→Session→ホストページ
- 最初の有料は、1対1の非スケールで取りに行く
次の行動は2つです。
Go1: オファーを一文で書く。
Go2: テストモードでもよいので Checkout のボタンを1つ置く。
※本記事は Paul Graham の2本のエッセイと Stripe Checkout quickstart に基づきます。手数料・税・日本向け最低価格の公的統計は本稿の根拠に含めていません。
コメント