このプロダクトは、ほぼ完全に一人で作りました。作業したのは平日の夜、週末、そして正直あまり数えたくないほどの休日です。長いあいだ、自分の中では「Web上に置かれている個人プロジェクト」という感覚が残っていました。
その感覚が一気に変わったのが、決済を有効にしたときです。コードが突然高度になったわけではありません。変わったのは、プロダクトに対する自分の責任です。誰かが実際にお金を払えるようになると、壊れたフローを単なる「あとで直すedge case」として扱いにくくなります。オンボーディング、モデレーション、リテンション、信頼性は将来の課題ではなく、その時点でプロダクトが提供している価値の一部になります。
今回のローンチで一番強く学んだのは、機能の多い個人開発プロジェクトを「作ること」と、実際のプロダクトを「運用すること」は別の仕事だということでした。
ソロ開発では、時間より「注意力」がボトルネックになった
このプロダクトを作っている間、私はSNSからほとんど消えていました。ローンチ戦略ではありません。プロダクトの判断、実装、edge case、フローのテスト、リリース準備が、同じ限られた時間を取り合っていただけです。
ソロ開発について、今はこの点を以前よりよく理解しています。ボトルネックは、必ずしもコードを書く速度ではありません。機能が増えるほど、状態、遷移、失敗パターンも増えます。そのすべてにどれだけ注意を向けられるかが難しくなります。
ビルドが成功しただけでは、その答えにはなりません。決済が一度成功しただけでも同じです。
決済を始めると、バグの意味が変わった
決済前は、多少の粗さを「あとで直すもの」と考える余地がありました。決済を有効にしてからは、その考え方が自分の中で通用しなくなりました。有料プロダクトにバグがあってはいけない、という意味ではありません。それは現実的ではない。ただ、既知の問題を放置するコストは、誰かが実際にお金を払った瞬間に変わります。
オンボーディングやモデレーションも同じです。開発中は「メイン機能を支える周辺システム」に見えやすい。しかし本番では、ユーザーが直接触れる以上、それ自体が体験の一部です。リテンションも同様で、最初のセッションが良かったからといって、また戻ってくる理由まで作れているとは限りません。
決済が、このプロダクトの完成を証明したわけではありません。むしろ「完成」という言葉の裏に、どれだけ仕事が残っていたかを見せてくれました。
ローンチ後に得られる情報は種類が違う
リリース後には、見栄えのしない仕事が始まりました。公開後に初めて見えるバグ、壊れたフロー、ユーザーが来て初めて現実になるモデレーションの問題、そして良い第一印象を作るよりずっと難しいリテンションの課題です。
ただし、そうしたシグナルを過大解釈しないようにもしています。リリース後にバグが出たからといって、即座にアーキテクチャが悪いとは言えません。リテンションが弱いからといって、それだけでproduct-market fitを診断できるわけでもありません。モデレーションの問題が一つ起きたことは、システム全体が危険だという証明ではありません。症状は調べる場所を教えてくれますが、原因まで自動的に教えてくれるわけではない。
変わったのは、得られる証拠の質です。ローンチ前にテストできるのは、基本的に「ユーザーはこう使うはずだ」と自分が想定したケースです。ローンチ後は、実際にどう使われたかに向き合うことになります。リリースは不確実性が消える瞬間ではなく、重要な不確実性の一部が初めて観測可能になる瞬間です。
今の自分が回しているローンチ後のループ
今は、ローンチの見栄えを整えることより、その後の仕事に興味があります。決済から得た学び、壊れたフロー、モデレーションの課題、ユーザー行動、リテンションの意外な結果、そしてプロダクトを少しずつ信頼できるものにする小さな修正です。
- 実際のフローを見る。 自分が設計した経路を、ユーザーもそのまま通るとは決めつけない。
- 症状と原因を分ける。 あるステップで失敗したことは「どこで問題が起きたか」を示しても、「なぜ起きたか」までは証明しない。
- 信頼に関わる失敗を優先する。 決済、アクセス、オンボーディング、モデレーションは、見た目の粗さより失敗時のコストが高い。
- 確認できた最小の問題から直す。 推測をもとにシステム全体を作り直すより、確認できた摩擦を一つ消したい。
- 修正後にユーザー体験をもう一度確認する。 コード上は正しい変更でも、ユーザー側の問題を解決していないことはある。
これは普遍的なフレームワークではありません。このプロダクトを「作る」段階から「運用する」段階へ移って、自分にとって一番筋が通っていると感じた進め方です。
ローンチは「正しさの根拠」が切り替わる地点だった
今、自分が一番大事だと思っている区別は、プロダクトを作ったことと、プロダクトを運用できることです。開発では「設計した通りにシステムが動くか」を問います。運用では、実際の人が使う、誤解する、離れる、戻る、お金を払う、想定外の経路に入る。そのとき何が起きるかを問うことになります。
だから、ローンチをゴールだとはもう考えていません。ローンチ前の根拠の多くは、自分の仮説とテストです。ローンチ後は、実際の行動、失敗、継続利用を通して、プロダクト側から答えが返ってきます。