公開後30日の育て方 — 個人開発プロダクトを改善サイクルに乗せる

初めてのプロダクトを公開したあと、多くの個人開発者が「次に何をすればいいか分からない」状態で止まります。この講義では、公開直後の30日間に何を見て、何を集め、どう直し、どう続けるかを全5章で整理します。

成果や利用者数を約束する内容ではありません。扱うのは、どんなプロダクトでも回せる「改善の手順」です。カリキュラム第11週・第12週の内容を、公開後の運用に絞って深掘りします。

公開直後に整えておくべき「見る仕組み」から確認します。

公開した瞬間に分かること・分からないこと

公開すると、審査を通ったこと、ストアに表示されたことは分かります。しかし、誰がどう使い、どこで止まったかは、仕組みを用意しないと一切見えません。公開初日の仕事は、この「見えない部分」を見えるようにすることです。

最初に置く3つの計器

まずは次の3つで十分です。

• 利用の有無（起動・主要機能の完了）が分かる最小限の記録
• エラーや強制終了を捕まえる仕組み
• 利用者が連絡できる窓口（問い合わせフォームやメール）

細かな分析は後回しで構いません。「使われているか」「壊れていないか」「声が届くか」の3点が先です。

公開直後に見る指標を決めておく

数字は見始めると際限がありません。最初の30日は「主要な操作を最後まで完了した割合」と「エラーの件数」の2つに絞ると、判断がぶれません。指標を先に決めてから公開すると、初週の混乱が減ります。

自分でも毎日使う

もっとも安価で確実な計測は、開発者自身が毎日使うことです。自分が使わなくなった機能は、他の人も使いません。使いながら気づいたことは、そのままバックログの候補になります。

第1章のまとめ

公開は計測の始まり。利用の有無、エラー、連絡窓口の3つを用意し、見る指標を2つに絞る。自分でも毎日使う。

改善の材料は、利用者の行動と言葉です。集め方の型を整理します。

複数の経路から集める

ストアのレビュー、問い合わせ、SNSでの言及、利用ログ。1つの経路に偏ると、声の大きい人の意見だけが残ります。経路を複数にして、行動の記録と言葉の両方を見ることで、偏りが減ります。

声をそのまま信じない、行動と突き合わせる

「この機能が欲しい」という声は、実際には別の困りごとの表現であることがよくあります。要望が来たら、その人がどこで止まっていたかを行動の記録と突き合わせ、本当の課題を言語化してから対応を決めます。

低評価は最も情報が濃い

厳しいレビューは読むのがつらいものですが、改善の手がかりとしては最も密度が高い情報です。感情ではなく事実の部分だけを抜き出し、再現できるかを確認して記録します。返信は丁寧に、約束は「検討する」までに留めます。

小さな聞き取りを自分で回す

数人でよいので、実際に使ってもらう場面を見せてもらうと、レビューでは分からない詰まりが見つかります。操作を指示せず、黙って観察して記録する。AIエージェントに記録の要約や分類を任せると、整理の手間が減ります。

第2章のまとめ

複数経路で集め、行動と言葉を突き合わせ、低評価から事実を抜き出し、小さな観察を自分で回す。

集めた材料を、着手できる順番に並べる方法です。

1件1行で書く

バックログは「誰が・どの場面で・何に困っているか」を1行で書きます。解決策は書かず、課題だけを書くのがコツです。解決策を先に決めると、より良い方法を見落とします。

影響と労力の2軸で並べる

各項目に「影響（困っている人数や深刻さ）」と「労力（実装と検証にかかる時間）」を大まかに付けます。影響が大きく労力が小さいものから着手し、影響が小さく労力が大きいものは思い切って保留にします。精密さより、並べて判断できることが大切です。

不具合と改善を分けて管理する

壊れているものは、改善よりも先に直します。不具合は「再現手順・期待結果・実際の結果」の3点をそろえてから着手すると、AIエージェントへの依頼もそのまま書けます。

やらないことを決める

バックログは増える一方です。「今のスコープではやらない」と明記した項目を持っておくと、要望が来るたびに迷わなくなります。第4週で学んだスコープの考え方は、公開後にこそ効いてきます。

第3章のまとめ

課題を1行で書き、影響と労力で並べ、不具合を先に直し、やらないことを決める。

バックログを実際の変更に変える、週ごとの回し方です。

週に1回、小さく出す

大きな更新を月に1回出すより、小さな更新を毎週出すほうが、壊れたときの切り分けが簡単で、利用者にも動いていることが伝わります。1週間で完了できる大きさに課題を切ることが、サイクルを回す前提です。

依頼文に受け入れ基準を入れる

AIエージェントへの依頼は、バックログの1行に「こうなったら完了」という観測できる条件を足して書きます。受け入れ基準があると、生成された変更を自分で検証でき、テストの追加も依頼しやすくなります。

回帰テストを毎回通す

改善のたびに既存の機能が壊れていないかを確認します。手動で全部を確認するのは続かないので、主要な流れをテストにしておき、変更のたびに実行します。テストの整備そのものもエージェントに任せられます。

公開前の小さな検品

更新を出す前に、実際の端末で主要な操作を1周し、説明文やスクリーンショットが実態と合っているかを確認します。第10週で作った出品チェックリストを、更新のたびに短縮版として使い回します。

第4章のまとめ

週1回の小さなリリース、受け入れ基準つきの依頼、回帰テスト、公開前の検品。この4つで、改善が習慣になります。

最後に、30日で終わらせず、次のプロダクトにつながる続け方を整理します。

記録を残す

毎週、やったこと・分かったこと・次にやることを数行で書き残します。記録があると、迷ったときに判断の根拠を振り返れますし、第12週のポートフォリオ整理にもそのまま使えます。

止まったときの再開手順

どんなに順調でも、忙しさで手が止まる週があります。再開の手順（記録を読む、バックログの先頭を1つだけやる）を決めておくと、止まった期間が短くなります。完璧な再開より、小さな再開を優先します。

公開して終わりにしないための問い

30日を過ぎたら、次の3つを自分に問いかけます。誰が使い続けているか。どこで離脱しているか。この仕組みを別の課題にも使えるか。答えが次のプロダクトの企画になります。

人とAIの役割分担を見直す

運用を続けると、AIエージェントに任せてよい作業と、人が判断すべき場面がはっきりしてきます。設計・優先順位・公開の判断は人、実装・調査・テスト整備の多くはエージェント。この分担を自分の言葉で書いておくと、次のプロダクトの立ち上げが速くなります。

第5章のまとめ

記録し、再開手順を持ち、問いを立て、役割分担を言葉にする。運用は次の企画の準備でもあります。

この講義で扱った仕様と受け入れ基準の考え方は、特別講義「仕様駆動開発マスター講義」と、カリキュラム第10週・第11週の出品準備の内容につながっています。あわせてご覧ください。

実際に手を動かしながら学びたい方は、全12週のシラバスで学習の全体像を確認できます（無料で読めます。成果や収益をお約束するものではありません）。

講義で扱ったテーマを、公式ドキュメントや公的機関の資料で確かめたいときの入口です。

• Search Console の概要（Search Console ヘルプ）：公開したページが検索でどう見られているかを確かめる公式ツール
• Why You Only Need to Test with 5 Users（Nielsen Norman Group）：少人数のユーザーテストを繰り返す考え方の出典
• Projects について（GitHub Docs）：改善バックログを管理するときの公式ドキュメント

この特別講義は無料で視聴できる総集編です。関連する内容を実際に手を動かしながら学びたい方は、全12週のシラバスで学習の全体像を確認できます（無料で読めます。成果や収益をお約束するものではありません）。先行案内はこちら。