課金が先、製品は後——KiteとCodeParrotの失敗を逆算した収益化ファースト開発の5ステップ

Kiteが閉鎖した2022年、創業者はポストモーテムにこう書いた。「50万人の開発者がいたのに、収益化できなかった。個人開発者はツールに金を払わない」。10年近くかけて積み上げたユーザー基盤は、事業継続を支える収益には変換されなかった。

同じ轍を踏んだCodeParrotも、GitHubとの統合で注目を集めながら短命に終わった。Deloitteの2025年AI ROI調査では、AIイニシアチブの75%が期待ROIを達成できていない。技術的には成立しているのに、収益化で詰むケースが圧倒的多数だ。

この記事では、KiteとCodeParrotの失敗を逆算した「収益化ファースト開発プロセス」の手順を説明する。「誰が・いつ・どこから・なぜ払うか」を製品開発の前に設計し、課金が確認できてから実装に入る5ステップだ。対応するケーススタディ「50万人のユーザーが誰も課金しなかったKiteの構造」もあわせて読むと、なぜこの設計が必要かがよりはっきりわかる。

「後から課金を考える」が詰む構造

Kiteの戦略を単純化するとこうなる。良いものを作り、多くの人に使ってもらい、後からマネタイズを考える。フリーミアムモデルを前提にした発想だが、その前提が市場によって成り立たないことがある。

問題は2つある。一つ目は「無料で価値を享受した後に課金を求める」ことの心理的コスト。すでに無料で使えているユーザーにとって、課金は「使い続ける権利を買う」ではなく「今まで無料だったものを奪われる」に近い感覚になる。コンバージョン率は想定を大きく下回りやすい。

二つ目は、「誰に売るか」が後から変えにくいこと。個人開発者向けに設計したUXと機能は、エンタープライズ購買には使えない。個人は払わず、企業には届かない。この両側から詰められたのがKiteの末路だった。

このプロセスを始めるための3つの前提条件

まず、インタビューできるターゲット候補が最低10人いること。友人・フォロワー・知人でも構わない。「解決したい課題を持っていそうな人」に5〜10件アクセスできる状態が必要だ。

次に、「誰のどんな課題を解決するか」が1文で言える状態にあること。この仮説がないとインタビューを設計できない。精度は問わない。「中小企業のエンジニアリングマネージャーがコードレビューに費やす時間を減らす」くらいの解像度で十分だ。

最後に、Stripeで最小限の決済フローを組める環境があること。エンジニアでない場合はGumroadやLemon Squeezyで代替できる。この3つが揃っていれば、次のステップに進める。

収益化を先に設計する5ステップ

ステップ1：「誰が払うか」をひとつに絞る

個人開発者を対象にするか、中小企業のエンジニアリングマネージャーを対象にするかで、価格帯も機能設計も流通経路もすべて変わる。この決定を曖昧にしたまま進むと、後のステップがすべて無意味になる。

判断の基準は「予算の出所」だ。個人は自腹なので、月額10〜30ドルが心理的上限になりやすい。企業購買は予算枠から支出されるため、月額100〜500ドルの許容幅が生まれる。AIコーディングツールの場合、個人開発者は最も課金しにくい購買者だ。Kiteはここで判断を間違えた。

紙一枚に「この人は誰か」「予算はどこから出るか」「意思決定者は本人か上司か」を書く。答えが書けなければ、まだ購買者が決まっていない。

ステップ2：購買意欲インタビューを10件実施する

最も重要なステップで、最もスキップされるステップでもある。インタビューで聞くのは「この機能が欲しいですか」ではなく、「この課題に今いくら払っていますか」だ。支払い実績のある課題にしか、将来の課金は発生しない。

設計はTypeformで事前スクリーニングをして対象ユーザーかどうかを確認し、Calendlyで30分の通話を設定する。通話では「現在どんなツールを使っているか」「月いくらかかっているか」「最も痛い課題は何か」の3点を深掘りする。

10件実施して「今の課題に月1万円以上払っている」という回答が3件以下なら、その市場での有料化は厳しい。数字が出ない場合はピボットを検討する段階だ。

ステップ3：支払い意思を金額で確認する

インタビュー後、「月額○○円で提供したとしたら、今すぐ申し込みますか」と聞く。「いくらなら払いますか」という聞き方では数字が出ない。「月額3,000円、年払い29,800円」という具体的な金額を提示して、反応を確認する。

この段階でウェイトリストへの登録を求めてもいい。口頭での「払います」より、実際に登録するかどうかの方がはるかに信頼できる意思表示だ。

ステップ4：課金フローだけを先に作る

製品の前に、決済フローを先に作る。Stripeで最小限の支払いページを作り、実際に課金できる状態にする。製品は仮のランディングページでいい。「このツールを使いたい人はここから申し込んでください」というページを公開し、実際に課金が発生するかどうかを確かめる。

申し込みから数日以内にプロダクトを渡すか、払い戻しをすれば倫理的な問題はない。確認したいのは「仮説上の購買意欲」ではなく「実際のクレジットカード登録が起きるかどうか」だ。10〜20人のターゲットにランディングページを見せて、1件も課金が発生しなければ、製品を作っても同じ結果になる可能性が高い。

ステップ5：課金が確認できてから機能設計を始める

ステップ4で課金が発生したら、その購買者が「何に対して払ったか」を深掘りする。機能リストを見せたから申し込んだのか、特定の課題が解決されるから申し込んだのか、インタビューで続きを聞く。その答えが、最初にビルドするMVPの範囲になる。

Notionでビジネスモデルキャンバスを作り、「誰が払うか」「なぜ払うか」「いくら払うか」「どこで購入するか」を明文化してから開発に入る。この4列が全部埋まっていれば、Kiteが陥ったシナリオを回避できる確率は大幅に上がる。

ツール選びの3段階

標準的な実装では、Stripe（決済）＋Notion（仮説管理）＋Calendly（インタビュー設定）の3つで足りる。Stripeは最小限の決済ページを10分で作れる。フォーム作成にはTypeformも使いやすく、スクリーニングクエスチョンを設定して対象ユーザーを自動判別できる。

エンジニアでない人には、GumroadかLemon Squeezyを使う選択肢がある。Stripeより設定が簡単で、デジタルプロダクトの販売ページを30分以内に作れる。課金テストの初期段階には十分機能する。

課金設計の参考フレームワークとして、Lenny’s NewsletterやReforgeのB2B SaaS価格設計コンテンツが実用的だ。理論より実例ベースで学べる。

向いている人と向いていない人

最も向いているのは、開発リソースが限られているソロ起業家や小規模チームだ。エンジニアが1〜3人で動くプロジェクトは、方向性のミスが致命的になりやすい。先に課金を確認する投資対効果が最も高い。AIツール・SaaS・開発者向けプロダクトを作ろうとしている人にも強く推奨する。Kiteの失敗が示すように、この市場は技術的完成度と収益化の相関が低い。

向いていないのは、VC資金が潤沢にあってグロース期間を長く設定できるケースだ。FacebookやSlackは最初の数年で課金を後回しにしてユーザーベースを積み上げた。その戦略はキャッシュに余裕がある場合に限られる。また、すでに課金実績のある市場の改良版を作る場合も、競合が課金できているなら差別化次第で同じ購買者を狙えるため、このプロセスを厳密に踏まなくてもいい。

KiteとCodeParrotが示しているのは、技術の問題ではなかったということだ。品質が課題だったなら、50万ユーザーのうち何割かは課金したはずだ。「誰が払うか」を最後まで曖昧にしたことが根本的な失敗だった。収益化を先に設計するのはアイデアを諦めることではない。「このアイデアで誰がいつ払うか」を確認してから作るということだ。

AI編集部コメント