公開したら終わりじゃない。ユーザーを増やし、育て、続けるための公開後ガイド

このガイドは、公開ボタンを押した後の日々を扱う。「開発期」ガイドで内製・外注の判断をつけ、開発会社との契約を交わし、利用規約・特定商取引法に基づく表記などの法務整備を終え、すでにサービスを世に出した人が読者だ。もう開発の話は蒸し返さない。目の前にあるのは「公開できたサービスをどう育てるか」という、開発とはまったく別の種類の仕事だ。

公開直後は、多くの人が拍子抜けする。渾身の力で作ったサービスに、初日はアクセスが数件しかない。知人がSNSのリンクを踏んでくれた分も含めて一桁、ということはむしろ普通で、SNSでの告知だけで初日に集まるアクセスは、フォロワー数百人規模の個人アカウントであれば数件〜十数件にとどまることが多い。厳密な統計調査があるわけではなく、あくまで個人開発者の体験談やSNS上の報告から見えてくる目安に過ぎないが、それでも「初日は一桁でも異常ではない」という感覚を持っておくだけで、公開翌朝にアクセス解析を開いて愕然とする回数は減らせるはずだ。個人開発者の体験談を追っていくと、初日一桁だったアクセスが、地道な発信と口コミを重ねた3ヶ月後には数十人〜100人規模のユーザーに育っていた、という報告は珍しくない。初日の数字と3ヶ月後の数字はほとんど相関しないというのが、多くの体験談に共通する感覚だ。過去に挑戦して伸びなかった経験がある人ほど、この最初の数字に一喜一憂しやすい。だがそれは失敗ではなく、これから先の数ヶ月で当たり前に起きることだ。このガイドは、公開直後の告知から、ユーザーの声の集め方、運用費の管理、機能の育て方、そして「続けるかやめるか」という誰もが必ず直面する判断まで、公開後に起きる現実を時系列に沿って手順化する。副業として週末に取り組む会社員も、専門知識をツール化した士業・医療職も、実店舗を構える地域事業者も、それぞれの立場でつまずくポイントが違う。このガイドでは、その違いを踏まえた上で、今日1つだけやることが決まる粒度まで具体的に落とし込む。

このガイドの全体地図

• STEP1：公開直後にやること（STEP1-1〜1-4）
• STEP2：声を集める仕組みを作る（STEP2-1〜2-3）
• STEP3：運用費と収益を確認する（STEP3-1〜3-3）
• STEP4：機能を育てる（STEP4-1〜4-3）
• STEP5：振り返り、続ける・やめるを判断する（STEP5-1〜5-5）
• STEP6：発信を続け、ファンを増やす（STEP6-1〜6-2）

STEP1：公開直後にやること

公開した瞬間、サービスは「作るもの」から「育てるもの」に変わる。だが多くの人は、公開した安心感からしばらく手が止まってしまう。ここで手を止めないための最初の4つのステップを確認する。会社員として副業でサービスを作った人はSTEP1-1・1-3・1-4を中心に読み進め、専門職や店舗経営者などすでに顧客基盤がある人はSTEP1-2を中心に読んでほしい。

STEP1-1：最初のユーザーをどこから集めるか

公開しただけでは誰も気づいてくれない。SNSで告知しても検索エンジンに載るまでには時間がかかるし、広告を出す予算も最初は限られている。だからこそ、「どこに、どんな順番でアプローチするか」を最初に決めておく必要がある。

やること：

1. 自分が今すぐ声をかけられる相手（知人・元同僚・SNSのフォロワー・既存の顧客）をリストアップする
2. その中で「このサービスの課題を実際に抱えていそうな人」を5〜10人に絞り込む
3. 一斉告知ではなく、1人ずつ「実は今こういうサービスを作った」と個別に伝える

詳しくは → 公開直後、最初のユーザーをどこから集めるか

完了の目安： 声をかける相手のリストが5人以上でき、実際に1人以上に個別連絡を送った状態。

STEP1-2：既存ネットワークへの告知方法（ペルソナB・C向け）

会社員としてゼロからユーザーを探している方は、この項目は丸ごと読み飛ばしてSTEP1-3に進んでよい。 士業や医療職としてすでに顧客基盤を持っている人、店舗を構えて地域に顧客がいる人は、ゼロからユーザーを探す必要がない。すでにある信頼関係を、新しいサービスの入り口として使えるかどうかがここでの分かれ目になる。

【専門職（ペルソナB）の場合】

たとえば行政書士がこれまでの業務ノウハウをツール化した場合、既存の顧問先に直接案内できるのは大きな強みだ。実際、相続関係の書類作成を専門にしていたある行政書士が、必要書類を自動判定するチェックツールを作り、顧問先に「実はこういうものを作ったので、よければ使ってみてください」と一言添えて案内したところ、10件の顧問先のうち3件がすぐに試してくれ、そのうち1件は「他の相続人にも見せたい」と言って別の家族にまで広がった、という進み方がある。法務上の配慮さえ押さえておけば、専門職の既存ネットワークへの案内は、店舗経営者の口コミと同じくらい自然に広がる余地がある。

ただしここで、業法上の広告規制や、既存の契約・守秘義務との整合性は必ず確認が必要になる。「顧問先の情報を使って新サービスを紹介してよいか」は、実は2つの異なる論点が重なっている。1つは守秘義務・専門職団体の広告規制、もう1つは個人情報保護法上の「利用目的の範囲内か」という論点だ。顧問契約を結んだ時点で想定していた利用目的（税務相談、法務相談など)の範囲を超えて、新サービスの営業目的で顧問先の連絡先を使うことは、個人情報保護法上の目的外利用にあたる可能性がある。実務上の逃げ道としては、第三者に情報を渡すわけではなく本人に直接連絡するだけであれば、目的外利用そのものを避けられなくても、「新しいサービスを作ったのでご案内してもよいか」と個別に確認を取り、相手が断れる形で伝えれば、実質的には同意を得た上での案内に近い形になる、という整理ができる。「せっかくの顧客リストだから」と安易に一斉送信するのではなく、一言確認を挟むことが安全な進め方になる。

専門職団体の広告ルールについても、業種によって性質がまったく異なる点に注意したい。医療職であれば医師法や医療広告ガイドラインが誇大広告や患者の体験談の扱いを厳しく制限しており、税理士・社労士であればそれぞれの業法が、成功報酬の表示や資格を持たない業務の代行と誤解されるような表現を規制している。業種は違っても、専門職の広告規制で共通して問題になりやすいのは「誇大広告」「効果・成功の保証」「資格外業務との誤認を招く表現」の3類型であることが多い。この3つに触れていないかをまず自分でチェックし、それでも判断がつかない場合は照会先に直接確認するのが確実だ。照会先は業種によって呼び方も制度化の度合いも異なる。弁護士であれば所属弁護士会の照会制度、行政書士・税理士・社労士であれば所属する都道府県会や本部の相談窓口、医師・歯科医師であれば都道府県医師会や医療広告規制に関する相談窓口が主な照会先になる。「たぶん大丈夫だろう」で自己判断して進めるより、自分の業種の窓口に1本連絡を入れる方が結果的に早い。

【店舗経営者（ペルソナC）の場合】

常連客への声かけに加えて、地域の同業者コミュニティ（商店会・業種別の勉強会・地域のFacebookグループなど）を経由した広がり方も現実的だ。自分の店で使い始めた業務改善ツールを「実はこんなものを作った」と同業の店主に見せることで、次の店舗への展開のきっかけになることも多い。

具体例として、飲食店の予約管理を効率化するツールを作った店主のケースを見てみる。作った当初は自分の店の電話予約をスマホのメモ代わりに使っていただけだったが、月1回の商店会の集まりで、隣の店主に「実はこんなの使ってる」とスマホ画面をそのまま見せたのがきっかけだった。その場で「うちでも使ってみたい」と言われ、翌週に実際に予約を入れる場面を10分ほど横で見てもらいながら使い方を説明したところ、その店主はその日のうちに使い始めた。さらに1ヶ月後、別の店主にも同じように画面を見せる機会があり、合計3店舗に広がった。ポイントは、資料や説明文を用意するのではなく、実際に動いている画面をその場で見せ、その場で使い方を一緒に確認したことだった。声をかける相手は、取引先や仕入れ業者を介した紹介でも構わない。

やること：

1. 既存の顧客・患者・常連客のリストの中で、告知してよい相手（守秘義務や個人情報の扱いに抵触しない範囲）を洗い出す
2. 専門職の場合は、告知が顧問契約時の利用目的の範囲内かを確認し、範囲外なら「案内してよいか」を個別に一言添えて伝える(本人への直接連絡であれば同意に近い形で進めやすい)
3. 専門職の場合は、所属する士業団体・協会の広告規制を会則・倫理規程で確認し(誇大広告・効果の保証・資格外業務との誤認の3類型に特に注意)、不明点は自分の業種の窓口(弁護士会照会制度、士業団体の相談窓口、医師会の相談窓口など)に照会する
4. 店舗の場合は、同業者コミュニティ・商店会など、横のつながりを使った紹介ルートを検討し、画面を実際に見せてその場で使い方を確認してもらう機会を作る

詳しくは → 専門職・店舗経営者が、既存の顧客・同業者ネットワークに告知する方法

完了の目安： 告知してよい既存ネットワークの範囲が明確になり、規制・守秘義務上の懸念点を確認し終えた状態。

STEP1-3：SNSでの告知の仕方（ペルソナA向け）

会社員として本業を持ちながら週末にサービスを作ってきた人にとって、SNSは最も手軽で、かつ最も反応が読みにくい告知チャネルだ。フォロワーが少ない状態から始めるからこそ、「何を、どんな順番で発信するか」の設計が結果を左右する。

過去に別のアイデアに挑戦して思うようにいかなかった経験がある人ほど、「今度こそ」という気負いから、いきなり完成度の高い告知文を作ろうとしてしまう。だが実際に読まれるのは、作った理由や苦労した過程が伝わる、飾らない投稿であることが多い。この気負いを手放す一番手っ取り早い方法は、完璧な告知文を1人で仕上げようとするのをやめることだ。書きかけの下書きの段階で、家族や友人など身近な1人に見せてしまう。「これで伝わる?」と聞いてしまえば、推敲に費やす時間も、完璧主義に陥る隙も自然と減っていく。過去に挫折した経験がある人ほど、「今度は誰にも見せずに完璧なものを公開したい」という誘惑にかられがちだが、それこそが以前と同じ失敗パターンを繰り返す入り口になりやすい。

身近な1人に見せた後、反応をどう読むかにも目安がある。「面白そう」「使ってみたい」と具体的な感想が返ってきたら、その言葉自体を告知文にそのまま活かせないか考える。相手が使ってくれた言葉は、たいてい自分では思いつかない角度からの表現になっている。逆に「へえ」「なるほど」といった反応が薄い場合、原因の多くは「なぜ作ったか」のエピソードが抜けていて機能説明だけになっていることにある。その場合は機能の説明を削り、自分が困っていた具体的な場面を1つだけ足してみる。それでも反応が変わらないなら、文章の問題ではなく「そもそも相手がそのテーマに関心がない」可能性もあるので、見せる相手を替えて再度試すのも手だ。反応が薄かったことを「文章が下手だった」と自分を責める材料にせず、次の1人に見せるための情報として淡々と扱うのがコツになる。

やること：

1. 「なぜこのサービスを作ったか」を1つのエピソードとして言語化する
2. 開発中の画面キャプチャや試行錯誤の過程を、公開前から小出しに投稿しておく（公開後に急に告知しても文脈が伝わりにくい）
3. 公開の投稿には、使い方が一目でわかる画像か短い動画を添える
4. 告知文の下書きができた時点で、公開前に身近な1人に見せて感想をもらう（完璧に仕上げてから見せようとしない）
5. 反応が具体的なら相手の言葉を告知文に取り入れ、反応が薄いなら機能説明を削って「なぜ作ったか」のエピソードを増やす

詳しくは → 公開の告知、SNSでどう発信すれば読んでもらえるか

完了の目安： 公開告知の投稿文と添付画像が準備でき、実際に1回以上投稿した状態。

STEP1-4：ユーザー0人から1人目を獲得する打ち手

「誰か使ってくれるだろう」と待っているだけでは、ユーザーは増えない。0人から1人目を獲得するまでが最も精神的にきつい区間であり、ここを乗り越える具体的な打ち手を持っておく必要がある。

最初の1人は、機能が完璧だから使い始めるのではない。「作った人が誰なのか」「なぜ困っている自分に声をかけてくれたのか」という文脈込みで使い始めることがほとんどだ。オンボーディングの設計が多少粗くても、最初のユーザーには個別に使い方を案内するくらいの気持ちで臨んでよい。

なお、ここでの「再度声をかける」は、相手との関係性によって強さを調整する必要がある。SNSのフォロワーや元同僚であれば、2〜3日後に別の角度から軽く声をかけ直しても失礼にはあたりにくい。副業で焦っている状態だと、この2〜3日という間隔さえもどかしく感じるかもしれないが、ここは我慢のしどころだ。一方で、顧問先や患者、取引先のように上下関係や信頼関係がすでにある相手の場合は、「忘れられている」リスクより「しつこいと思われる」リスクの方が現実的に大きい。この場合は間隔を1〜2週間に広げ、催促ではなく近況報告のような柔らかい形で触れるくらいがちょうどよい。カジュアルな相手への「2〜3日」と、信頼関係を重んじる相手への「1〜2週間」という差は、心理的な焦りの大きさではなく、声をかけ直すことで失うものの大きさで決まっていると考えるとわかりやすい。フォロワーとの関係が多少ぎこちなくなっても実害は小さいが、顧問先との関係がこじれれば本業に影響する。焦りを感じたら、待っている間に次の声かけ候補への連絡やSTEP1-1のリストの見直しなど、手を動かせる別の作業に切り替えるとよい。

やること：

1. リストアップした声かけ候補に、上から順に個別メッセージを送る
2. 返信がなければ、カジュアルな相手には2〜3日後、信頼関係を重んじる相手には1〜2週間後を目安に、別の角度から再度声をかける
3. 待っている間は、次の声かけ候補への連絡や声かけリストの見直しなど、手を動かせる作業に時間を使う
4. 1人使い始めてくれたら、使い方でつまずいていないかを直接確認する

詳しくは → ユーザー0人から1人目を獲得するまでの、具体的な打ち手

完了の目安： 自分以外の1人が、実際にサービスを使い始めた状態。

STEP2：声を集める仕組みを作る

最初のユーザーが増え始めたら、次にやるべきは「なんとなく使われている」状態から「なぜ使われているか、どこでつまずいているか」がわかる状態に変えることだ。声を集める仕組みは、後から追加しようとすると機会損失が大きい。

STEP2-1：声を集める仕組みが必要な理由

自分で使っていて気づかない不便さは、必ず存在する。作り手は「これくらい説明しなくてもわかるだろう」と思い込みがちだが、初めて触るユーザーにとってはそうではない。声を集める仕組みがなければ、ユーザーが離れていく理由も、逆に気に入ってくれている理由もわからないまま時間だけが過ぎる。

ユーザーインタビューという言葉を使うと大げさに聞こえるかもしれないが、実際には10分程度の電話や、テキストでのやり取りで十分に価値のある声が拾える。重要なのは「使ってくれてありがとう」で終わらせず、具体的な使用感を聞く場を意図的に作ることだ。

やること：

1. 公開後2週間以内に、声を集める手段を最低1つ用意する
2. 最初のユーザーには、使い始めて数日経ったタイミングで個別に感想を聞く
3. 集めた声は、思いつきでメモせず、後から見返せる場所に一元化する

詳しくは → ユーザーの声を集める仕組み、公開後すぐに作るべき理由

完了の目安： 声を集める手段が1つ以上稼働しており、実際に声が1件以上集まっている状態。

STEP2-2：フォーム・DM等の手段の選び方

声を集める手段にはいくつかの選択肢があり、どれが正解ということはない。サービスの性質とユーザー層に合わせて選ぶ必要がある。

【一般ユーザー向け(会社員・個人ユーザー層)の場合】 チャットツールに慣れた会社員向けのサービスならアプリ内アンケートやDMでも抵抗なく回答してもらえる。回答項目を5問以内に絞り、そのうち1問は自由記述、残りは選択式にしておくと回答率が落ちにくい。質問文の例としては、「使いにくかった機能はどこですか」「一番よく使う機能は何ですか」「もし友人に勧めるとしたら何と説明しますか」といった、答えやすく具体的な問いにしておくと自由記述でも埋まりやすい。返信方針も、まず全件に「ありがとうございます」の定型文を即時に返し、改善につながりそうな声にだけ後日個別で「実装を検討しています」と追いかける、という二段構えにしておくと、少人数でも運用が破綻しにくい。手段を1つに絞る必要はなく、ITの専門用語に疎い層が使うサービスであれば、電話や対面での聞き取りの方が本音を引き出しやすいこともあるため、ユーザー層に応じて複数用意しておくのが現実的だ。

【専門職・医療職の場合】 顧客・患者の声を集める場合は、もう一段階配慮が必要になる。アンケートの回答項目に、症例や個別の相談内容そのものを書かせる設計は、守秘義務・個人情報保護の観点から避けたい。「使い勝手はどうだったか」「機能のどこで迷ったか」といった、サービスの使用感に限定した質問設計にとどめ、業務上知り得た個別の相談内容には触れさせない。加えて、フィードバックフォームの設計次第では、回答内容が病歴や身体状況に触れる「要配慮個人情報」を収集する経路になりうる点にも注意したい。要配慮個人情報を取得する場合は原則として本人の同意(オプトイン)が必要になるが、フォームで「使用感のみ回答してください」と質問範囲を明示していたにもかかわらず、回答者が自発的に病歴等を書いてしまった場合は、意図して取得したわけではないため、その情報を漫然と保持し続けないことが重要になる。具体的な型としては、(1)そうした情報が書かれているのに気づいたら速やかにその記載部分を削除する、(2)アンケートの利用目的(サービス改善)を達成したら元の回答データ自体も保有し続けない、(3)万一残ってしまった場合の閲覧者を社内で1〜2名に限定する、の3点を運用ルールとして先に決めておくと安全だ。これは専門職に限らず、ITリテラシーが高くない層に対しても同様で、何を答えればいいか分からないまま個人的な事情まで書いてしまうケースがあるため、質問文で聞きたい範囲を明確に絞ることが重要になる。

やること：

1. ユーザー層のITリテラシーに合わせて、フォーム・DM・電話・対面のうち使う手段を選ぶ
2. フォームを使う場合は、回答項目を5問以内(自由記述1問+選択式中心)に絞り、離脱を防ぐ(質問文の例：「使いにくかった機能はどこですか」「一番よく使う機能は何ですか」)
3. 専門職・医療職の場合は、回答項目が守秘義務や個人情報保護に抵触しないか(症例・個別相談内容や要配慮個人情報を書かせていないか)を事前に確認し、意図せず該当情報が書かれた場合は速やかに削除・目的達成後は保有しないという方針を決めておく
4. 集めた声にどう返信するか(全件への即時のお礼と、改善につながる声への個別フォローの二段構え)をあらかじめ決めておく

詳しくは → フォーム・DM・アプリ内アンケート、声を集める手段の選び方

完了の目安： ユーザー層に合った声集めの手段が決まり、実際に運用を開始している状態。

STEP2-3：厳しい意見の受け止め方

声を集め始めると、必ず厳しい意見や低評価に直面する時期が来る。ここで心が折れてしまう人は少なくないが、厳しい意見こそ改善のための最も価値のある材料であることが多い。

特に、時間とお金をかけて自分のアイデアに再挑戦している人ほど、否定的な意見を人格への攻撃のように受け取ってしまいがちだ。だが厳しい意見の多くは「使ってみたが期待とズレていた」という事実の指摘であり、サービスそのものへの評価であって、作った人への評価ではない。この切り分けができるかどうかが、次の一歩を踏み出せるかを左右する。

やること：

1. 厳しい意見を受け取ったら、その場で反論・言い訳をせず、まず「ありがとうございます」とだけ返す
2. 一晩置いてから、意見の中に改善のヒントがないかを冷静に読み返す
3. 感情的な反応と、事実に基づく指摘を分けてメモする

詳しくは → 厳しい意見・低評価をどう受け止め、改善に変えるか

完了の目安： 厳しい意見を受け取った経験が1件以上あり、それを改善のメモとして言語化できている状態。

STEP3：運用費と収益を確認する

ユーザーが増え始めると同時に、見落としがちなのが運用費の話だ。開発が終わった後も、サービスはお金がかかり続ける存在であり、ここを放置すると気づかないうちに赤字が膨らむ。

STEP3-1：公開後の運用費の実態

開発期には見積もりの中に含まれていた運用費が、公開後は毎月の実費として発生し続ける。クラウドホスティングの利用料、ドメインの更新費、外部APIの従量課金など、項目は複数にまたがる。多くの人は、これらを最初のうちは「誤差の範囲」として気にしないが、ユーザーが増えるほど無視できない金額になっていく。

副業規模で個人開発したサービスの場合、公開直後でユーザーがまだ数十人程度であれば、ホスティング費とドメイン費を合わせて月数千円〜1万円台に収まることが多い。外部APIを従量課金で使っている機能があると、ユーザーが増えるにつれてこの部分だけ急に伸びる場合があるので、そこだけは個別に金額を確認しておきたい。特に跳ねやすいのが、画像生成AIやチャットボットなどのAI系APIを組み込んだ機能だ。呼び出し1回あたりは数円〜数十円程度でも、ユーザー1人が1日に何度も使う機能だと、ユーザー数が10人から100人に増えただけで月額が数千円から数万円規模へ一段階跳ね上がることがある。対して、メール送信APIや地図表示APIのような「1ユーザーあたりの呼び出し回数が少ない」機能は、同じ従量課金でもユーザー数が増えてもなだらかにしか増えない傾向がある。自分のサービスにAI系・生成系のAPIが組み込まれているかどうかを最初に確認し、該当する場合はそこだけ重点的に金額を追う、という優先順位のつけ方をしておくと、非エンジニアでも増加ペースの見当がつけやすい。会社員として副業でやっている場合、「月にいくらまでなら赤字でも続けられるか」を先に決めておくと、運用費の数字を見ても慌てずに済む。目安としては、まず1万円前後を許容ラインとして仮決めし、実際の請求額と照らして自分の感覚に合わせて調整していくのが現実的だ。

開発を外注していて、どのサービスのどの画面を見ればいいか分からない場合は、自分で管理画面を探し回る前に、開発会社に「毎月の運用費の一覧と、それぞれの内訳を教えてください」と一言聞いてしまうのが早い。ホスティング費・ドメイン費・外部APIの従量課金・保守費が別々の契約になっていることも多く、開発会社側で全体を把握していれば、月ごとの合計額をまとめて教えてもらえるはずだ。実際に聞くと、小規模な個人向けサービスであればホスティングとドメインだけで月数千円、保守費用を別途契約している場合はそこに数万円が上乗せされる、という内訳が返ってくることが多い。数字が漠然としているうちは不安が先に立つが、内訳が具体的な項目と金額に分解された瞬間に、次に何を削るべきかが見えてくる。専門職としてサービスを提供している場合は、この運用費に加えて、顧問弁護士・社労士への相談料や賠償責任保険、個人情報保護関連のコンプライアンス費用が別枠でかかっているケースもある。賠償責任保険の相場は業種によって数倍〜十倍近く差が出ることがあり、たとえば社労士向けの団体保険と医療系専門職向けの賠償責任保険とでは前提となるリスクの大きさが違うため、単純に「年数万円〜十数万円」という幅だけを鵜呑みにせず、まずは自分が所属する業種団体が案内している団体保険の窓口を確認するのが実務的な近道になる。顧問弁護士への都度相談は1回数万円というのが一般的な相場感になる。開発期に整えた法務体制は、公開後も維持費として発生し続けることを忘れないでおきたい。

やること：

1. 現在発生している運用費の項目をすべて洗い出す（ホスティング・ドメイン・外部API・決済手数料など）
2. 自分のサービスにAI系・生成系のAPIが組み込まれているかを確認し、該当する場合はユーザー数増加に伴う従量課金の伸びを重点的に追う
3. 外注している場合は、開発会社に「毎月の運用費一覧と内訳」を聞き、各項目の請求書またはダッシュボードで実際の月額を把握する
4. 副業規模の場合は、まず「月1万円前後」を仮の許容ラインとして決め、実際の請求額と照らして自分の感覚に合わせて調整する
5. 専門職の場合は、相談料・賠償責任保険(自分の業種団体の団体保険窓口をまず確認)・コンプライアンス費用など、法務関連の継続コストも洗い出す
6. 月額の合計を、家計簿やスプレッドシートで毎月記録する習慣をつける

詳しくは → 公開後の運用費、実際にいくらかかっているか

保守・運用にかかる費用がそもそもどの程度が相場なのかを知っておくと、自分の運用費が高すぎないかの目安になる。保守費用の相場感も参考にしてほしい。

完了の目安： 現在の運用費の月額合計が、金額として把握できている状態。

STEP3-2：ユーザー増加に伴う費用の増え方（ペルソナC向け：他店展開後の費用）

自分の店舗で使うために作ったツールが評判になり、他の店舗にも展開したいという話が出てくることがある。ここで見落とされがちなのが、ユーザー(店舗)が増えるほど運用費も比例して増えるという構造だ。

たとえば1店舗分のデータ量を前提に選んだプランのままでは、3店舗、5店舗と展開した瞬間に、実際の画面で困りごとが起きる。予約が重なる時間帯にアクセスが集中して画面の読み込みが遅くなる、保存できる予約データや顧客データの件数に上限があってエラーが出る、写真や帳票を保存する容量が足りなくなる、といった形で不具合が表面化し、追加費用が発生したり、動作が不安定になったりすることがある。どのくらいの店舗数で危なくなるかは、選んでいるプランやサービスの作りによって大きく変わるため一概には言えないが、目安としては、無料〜最安プランのまま増設していくと3〜5店舗あたりで最初の上限(データ件数や同時アクセス数)に触れ始め、10店舗を超えるあたりからはプラン変更なしで耐えるのはまず難しい、という感覚を持っておくと動きやすい。「10店舗くらいまでは平気だろう」と楽観するのではなく、「5店舗目に近づいたら一度確認する」くらいの前倒しの意識でいるのがちょうどよい。他店舗への展開は嬉しい話である一方、「何店舗まで今の体制で耐えられるか」を先に把握しておかないと、後から慌てることになる。

自分ひとりで試算するのが難しい場合は、まずホスティングサービスの請求書やダッシュボードで「現在のデータ量・アクセス数に対する料金」がどの項目で決まっているかを確認し、それを店舗数倍にした場合の概算を開発会社に聞くのが現実的だ。「3店舗になったら月額はどれくらい変わりますか」という聞き方をすれば、開発会社側も具体的な試算を出しやすい。実際に聞いてみると、Firebase(App Hosting)やVercelのようなホスティングサービスを使っている場合、1店舗分では月数千円だった費用が、3店舗分のデータ量とアクセス数を見込むと1万円台後半〜2万円台に増える、という試算が返ってくるようなケースは珍しくない。どちらのサービスも公式サイトに料金体系のページが公開されているので、開発会社に「うちはどちらを使っていて、料金ページのどのプランに相当しますか」と聞いておくと、次に自分で確認したいときにも迷わない。この数字を先に知っているかどうかで、他店舗への展開話を受けるときの心構えがまったく変わってくる。

やること：

1. 現在のプランが、ユーザー数・店舗数の増加に対してどこまで耐えられるかを、ホスティングの請求書・ダッシュボードで確認する
2. 使っているホスティングサービス名(Firebase・Vercelなど)と、料金ページ上でどのプランに相当するかを開発会社に確認しておく
3. 店舗数が2倍・5倍になった場合の想定費用を、開発会社に問い合わせて試算する
4. 目安として3〜5店舗あたりで最初の上限に触れ始めることを念頭に、5店舗目に近づく前に一度体制を確認する
5. 他店舗への展開を持ちかけられたら、その場で即答せず、費用試算後に返事をする

詳しくは → ユーザーが増えるほど上がっていく費用と、備え方

完了の目安： ユーザー数が現在の2倍になった場合の運用費の見込みが、おおよそでも試算できている状態。

STEP3-3：運用費が収益を超えたときの確認事項

副業や小規模事業として始めたサービスでは、運用費が収益（あるいは自分の許容できる持ち出し額）を超えてしまう瞬間が訪れることがある。これは即座にサービスを畳むべきサインではなく、まず何を確認すべきかを整理するタイミングだ。

KPI（重要業績評価指標）として何を見ているか、収益源は何か、費用のうち削減できる項目はどこかを、感情的にならず順番に点検する必要がある。特に「なんとなく不安」という状態のまま放置すると、判断が遅れて手遅れになりやすい。

やること：

1. 直近3ヶ月分の運用費と収益(または見込み収益)を並べて比較する
2. 費用のうち、使っていない機能・過剰なプランがないかを見直す
3. 収益化の見込みがまだ先なのか、そもそも収益モデルに無理があるのかを切り分ける

詳しくは → 運用費が収益を超えてしまったときに、まず確認すべきこと

完了の目安： 運用費と収益の差分が金額として把握でき、削減できる費用項目の候補が出ている状態。

STEP4：機能を育てる

最初のユーザーの声が集まり、運用費の実態も把握できたら、次はサービスそのものを育てるフェーズに入る。ここで重要なのは「何を追加するか」以上に「何を追加しないか」だ。

STEP4-1：機能追加の優先順位

ユーザーから要望が届き始めると、あれもこれも実装したくなる。だがすべての要望に応えようとすると、開発リソースも運用費も足りなくなる。優先順位をどう決めるかが、公開後の機能開発における最初の関門になる。

開発を外注している場合、要望が来るたびに「実装コストが低いかどうか」を自分だけで判断するのは難しい。ここは無理に見積もらず、要望をある程度まとめた上で開発会社に見積もりを依頼し、コスト感と効果を並べて比較するのが現実的だ。判断のコツは、要望が「今ある画面・データ構造に項目を1つ足すだけで済むか」「画面をまたいでデータ同士を新しく連動させる必要があるか」を見分けることにある。前者は既存のテーブルに列を1つ増やす程度の変更で済むことが多く、後者は複数の機能の裏側にあるデータの持ち方そのものを設計し直す必要が出てくるため、見積もりの金額が一桁単位で変わってくる。

たとえば店舗経営者であれば、同業の店主から個別の要望をもらうことがある。飲食店の予約管理ツールを作った店主のケースでは、他店に展開した直後に「うちはコース料理を出すので、予約人数だけでなくコース内容も一緒にメモしておきたい」という要望が来たことがあった。その場で「できます」と即答せず、いったん持ち帰って開発会社に見積もりを依頼したところ、既存の予約フォームに備考欄を1つ追加するだけで対応できることがわかり、追加費用も数万円程度で済んだ。これは「今ある予約データに項目を1つ足すだけ」で完結する変更だったからだ。逆に「予約と在庫管理を連動させたい」という要望は、予約が入るたびに在庫の数量を自動で増減させ、在庫が足りなくなったら予約自体を制限する、という新しい仕組みをデータの持ち方から作る必要があり、既存の仕組みを大きく作り変える必要があるため、見積もりだけで数十万円規模になることがわかった。そのため、いったん保留にして「まずは備考欄の追加から」と伝えて着地させた。専門職の場合も考え方は同じで、行政書士向けの書類作成支援ツールで「作成した書類に、案件ごとのメモを一言添えたい」という要望であれば備考欄追加と同種の軽微な変更で済むことが多いが、「複数の案件の進捗状況を横断的に一覧管理したい」という要望は、案件データの構造自体を見直す必要が出てくるため高額になりやすい。このように、要望を聞いた場での即答を避け、見積もりを挟んでから返事をする習慣をつけておくと、後で無理な約束をしてしまうことを防げる。

やること：

1. 集まった要望を「多くのユーザーが求めているか」「今のサービスの核となる価値に直結するか」の2軸で並べる
2. 要望が「既存のデータに項目を1つ足すだけか」「複数の機能をまたいでデータ同士を連動させる必要があるか」を見分ける(前者は軽微、後者は高額になりやすい)
3. 外注している場合は、要望をまとめて開発会社に見積もりを依頼し、コストと効果を比較する
4. 実装コストが低く効果が高いものから着手する(例：備考欄の追加のような軽微な変更を優先し、大規模な作り変えが必要な要望はいったん保留にする)
5. 優先順位の判断基準を、要望をくれたユーザーにも簡潔に説明できるようにしておく

詳しくは → 公開後の機能追加、優先順位をどう決めるか

完了の目安： 集まった要望リストに優先順位がつき、次に着手する機能が1つ決まっている状態。

STEP4-2：機能が増えすぎるのを防ぐ

要望に応え続けていると、いつの間にかサービスの画面が複雑になり、最初にサービスを気に入ってくれた理由だった「シンプルさ」が失われてしまうことがある。機能を増やすことと、サービスを良くすることは、必ずしもイコールではない。

特に複数の要望を並行して抱えている状態では、「頼まれたから作る」を繰り返すうちに、誰のための機能かわからないものが増えていく。今回追加する機能が、最初に想定していたユーザー像にとって本当に必要かどうかを都度立ち止まって確認する姿勢が要る。

【店舗経営者向けサービスの場合】 店舗経営者が展開するようなサービスには、通常、法令上残しておかなければならない機能という概念が存在しない。したがって、使われていない機能は素直に削除候補にしてよい。「これがなくても困らないユーザーはどれくらいいるか」を考え、使用頻度が低ければ棚卸しの対象にする、というシンプルな基準だけで判断を進めて構わない。

【専門職・医療職向けサービスの場合】 専門知識をツール化したサービスの場合、使用頻度が低いからといって単純に削除候補にできない機能があることに注意したい。記録の保持や証跡の出力など、法令や監査対応の観点から残しておく必要がある機能は、「使われていないなら削除」という発想とは切り分けて考える必要がある。具体的には、行政書士であれば作成した書類の履歴や相談記録の出力機能、社労士であれば給与計算・手続き代行の処理履歴、医療職であれば問診内容や施術記録に類する入力ログなどが、使用頻度が低くても残しておくべき機能の典型例になる。棚卸しをするときは、まず機能の一覧を「法令・監査対応で残す必要があるもの」と「純粋に使い勝手のための機能」の2つに仕分けしてから、後者の中だけで使用頻度による削除候補を検討する、という2段階の手順を踏むと、誤って必要な記録機能を削ってしまう事故を防げる。

やること：

1. 機能を追加する前に、「これがなくても困らないユーザーはどれくらいいるか」を考える
2. 店舗経営者向けサービスの場合は、使われていない既存機能を定期的に棚卸しし、使用頻度が低いものは素直に削除候補にする
3. 専門職・医療職向けサービスの場合は、まず機能を「法令・監査対応で残す必要があるもの」と「純粋な使い勝手のための機能」に仕分けし、後者だけを使用頻度で棚卸しする
4. 迷ったときは「追加しない」を初期設定にする

詳しくは → 「あれもこれも」で機能が増えすぎるのを防ぐ考え方

継続して機能を追加していくべきか、それとも今の形を維持すべきかで迷ったときは、サービスを育てるか判断する基準も判断材料の1つになる。

完了の目安： 直近の機能追加の要望について、「やらない」判断を1件以上下せている状態。

STEP4-3：MVPから育ったサービスへのロードマップ

最初に公開したのは、必要最小限の機能だけを備えたMVP（実用最小限の製品）だったはずだ。ここから「育ったサービス」へと機能を拡張していくには、思いつきではなく順番が要る。

いきなり大きな機能をまとめて実装するのではなく、ユーザーの利用が安定している部分から段階的に広げていくのが基本的な考え方になる。たとえば個人向けの家計管理サービスであれば、まず「記録する」機能が安定して使われていることを確認したうえで、次に「振り返る(グラフ表示)」機能を足し、その次に「共有する(家族との連携)」機能へ広げる、というように、利用が定着した機能の隣接領域から手を伸ばしていくのが典型的な順番だ。

この「記録する→振り返る→共有する」という順番は、家計管理に限らず、会社員が副業で作りがちな他ジャンルにも当てはめやすい。たとえば店舗の予約管理ツールであれば、まず「予約を受け付ける」機能が安定して使われることを確認したうえで、次に「予約状況を振り返る(稼働率や曜日ごとの傾向をグラフで見る)」機能を足し、その次に「常連客と共有する(予約履歴をもとにしたお知らせ配信)」機能へ広げる、という順番になりやすい。同業者同士のマッチング型サービスであれば、まず「登録する・探す」機能が定着したことを確認し、次に「やり取りを振り返る(過去の連絡履歴を一覧できる)」機能を足し、その次に「評価を共有する(お互いのレビューを見られる)」機能へ広げる、という流れが典型的だ。コミュニティ系のサービスであれば、「投稿する」が定着してから「振り返る(過去の投稿をまとめて見る)」、その次に「外部に共有する(SNSへのシェア機能)」という順番になることが多い。ジャンルが変わっても、「記録・蓄積する機能」→「本人が振り返る機能」→「他者と共有する機能」という3段階の骨格はおおむね共通しているため、自分のサービスがどのジャンルに近いかを考えれば、次に何を拡張すべきかの見通しが立てやすくなる。どの順番で何を拡張していくかの見通しがあると、要望への対応もぶれにくくなる。

やること：

1. 現在のMVPが「安定して使われている中核機能」と「まだ様子見の機能」のどちらに支えられているかを整理する
2. 自分のサービスが「記録・蓄積する」→「本人が振り返る」→「他者と共有する」のどの段階にいるかを当てはめ、次に拡張する機能領域を1つに絞ってロードマップとして書き出す(中核機能の隣接領域を優先する)
3. ロードマップは固定せず、STEP2で集めた声をもとに3ヶ月に1度は見直す

詳しくは → MVPから「育ったサービス」へ、機能を拡張していく順番

完了の目安： 今後3ヶ月で拡張する機能領域が、優先順位つきで書き出せている状態。

STEP5：振り返り、続ける・やめるを判断する

公開から一定期間が経つと、必ず「このまま続けるべきか」を考える瞬間が訪れる。ここを曖昧にしたまま走り続けると、判断が遅れて撤退のタイミングを逃したり、逆に伸びる可能性を早々に諦めてしまったりする。

STEP5-1：公開から3ヶ月の振り返り

公開から3ヶ月というのは、最初の勢いが落ち着き、サービスの実態が見え始めるタイミングだ。感覚だけで「なんとなく伸びている/伸びていない」と判断せず、具体的な指標をもとに振り返る必要がある。

やること：

1. ユーザー数、継続利用の状況、集まった声の傾向を3ヶ月分並べて見返す
2. 公開当初に想定していた仮説と、実際に起きたことのギャップを書き出す
3. ギャップの中から、次の3ヶ月で検証すべき問いを1つ選ぶ

詳しくは → 公開から3ヶ月、振り返っておきたい指標と気づき

完了の目安： 3ヶ月分の指標が一覧でき、次に検証すべき問いが1つ言語化できている状態。

STEP5-2：「刺さっている」サインの確認

本格的に広告費や時間をかけて伸ばしていく前に、そもそも今の形がユーザーに「刺さっている」のかどうかを確認しておく必要がある。ここを見誤ると、刺さっていないものにアクセルを踏んでしまうことになる。

PMF（プロダクトマーケットフィット）という言葉で語られることもあるこの状態は、派手な数字である必要はない。少人数でも「これがないと困る」と言ってくれるユーザーがいるか、継続して使われているかといった地に足のついたサインを見る方が実態に近い。

やること：

1. 継続して使ってくれているユーザーに、「もしこのサービスがなくなったら困るか」を率直に聞く
2. 使われ方が想定通りか、想定外の使われ方をしているかを確認する
3. 刺さっているサインが弱い場合は、拡大よりも先に改善に時間を使う判断をする

詳しくは → 本格的に伸ばす前に確認したい「刺さっている」サイン

完了の目安： 「刺さっている」と言えるサインがあるかないか、根拠を持って答えられる状態。

STEP5-3：公開前に知っておきたかったこと（ペルソナA向け：過去の自分への振り返り）

過去に一度挑戦して思うようにいかなかった経験を持つ人にとって、公開後のこの時期は「今回はどう違ったか」を振り返る貴重な機会になる。当時の自分に何を伝えたかったかを言語化することは、次に活きる財産になる。

副業として週末に時間を切り出しながら進めてきた人ほど、公開して初めて気づくことが多い。よくあるパターンをいくつか挙げると、まず「もっと早く声を聞けばよかった」がある。完成度を上げることに時間を使いすぎて、実際に使う人の反応を聞くタイミングが公開直前まで遅れてしまい、直してほしい部分が公開後にまとめて出てくる、というものだ。次に「機能を絞りきれていなかった」がある。あったら便利そうな機能を最初から詰め込んでしまい、結果的にどの機能も中途半端になり、公開後に「結局よく使われているのは1つか2つの機能だけだった」と気づくパターンだ。3つ目によくあるのが「値付けを後回しにしていた」というものだ。無料で使ってもらうことばかり考えて、いつ・いくらで課金するかを決めないまま公開してしまい、ユーザーが増えてから値付けの話をするタイミングを逃してしまう。これらはいずれも、公開前には気づきにくく、公開して初めて輪郭がはっきりする種類の気づきだ。これは反省というより、次のサイクルをより短く、より的確に回すための材料だと捉えるとよい。

やること：

1. 公開前の自分が「わかっていなかった」と感じることを3つ書き出す(例：声を聞くタイミングが遅かった、機能を絞りきれていなかった、値付けを後回しにしていた、など)
2. その気づきのうち、今すぐ他の判断に活かせるものがないかを確認する
3. 過去に挫折した経験がある場合は、当時とどこが違ったから公開まで辿り着けたのかを言語化する

詳しくは → 公開前に知っておきたかったことを、公開後の視点で振り返る

完了の目安： 公開前の自分に伝えたいことが、3つ以上言葉にできている状態。

STEP5-4：続けるかやめるかの判断基準

「続けるかやめるか」は、追い詰められてから考えるものではない。うまくいっているときも、いっていないときも判断できるよう、あらかじめ基準を決めておく必要がある。

基準を先に決めておかないと、赤字が膨らんでからも「もう少しだけ」を繰り返してしまったり、逆にわずかな停滞で焦って撤退してしまったりする。目安の一例として、副業として個人開発を続けている場合、「公開3ヶ月時点で自分以外の継続ユーザーが5人未満、かつ増加の兆しも見えない」なら方向転換を検討し、「10人以上が継続して使っており、うち数人から具体的な改善要望が来ている」なら、まだ伸びる余地があると見て改善を続けながら粘る、という数値目安を持っておくと判断がぶれにくい。もちろんこの5人・10人という数字はサービスの性質によって変わるので絶対的な基準ではないが、「なんとなく続ける」を避けるための仮の線引きとして自分なりの数字を先に決めておくこと自体に意味がある。ピボットという選択肢も含めて、続ける・変える・やめるの3つの道を並べて考えられる状態を作っておきたい。方向転換と一言でいっても中身はさまざまで、たとえばターゲット層を「会社員全般」から「特定の業種の会社員」に絞り込む、月額課金から都度課金に価格モデルを変える、機能を半分に削って「もっと狭く、もっと深く」使ってもらう対象を変える、といった軌道修正がありうる。続ける・やめるの2択で考えると視野が狭くなりがちだが、こうした具体的な変え方の引き出しを持っておくと、行き詰まったときの選択肢が増える。

やること：

1. 「この状態になったら見直す」という基準を、期間または金額で具体的に決める(例：公開3ヶ月時点で継続ユーザーが5人未満なら方向転換を検討する、といった数値目安)
2. 続ける場合・方向転換する場合・やめる場合の3パターンをあらかじめ想像しておく（方向転換の例：ターゲット層を絞る、価格モデルを変える、機能を絞り込む）
3. 基準を紙やメモに書き出し、感情に流されないよう定期的に見返す

詳しくは → 続けるか、やめるか。判断基準をいつ決めておくべきか

完了の目安： 続ける・やめるを判断する基準が、具体的な数字か期間で決まっている状態。

STEP5-5：サービスを畳むときの伝え方

やめると決めた場合、そこで放置してしまうのが一番よくない終わり方だ。すでにお金を払ってくれているユーザーや、日常的に使ってくれているユーザーがいる以上、終わり方にも一定の手順と誠実さが求められる。

【専門職の場合】 専門職として顧客の業務に関わるツールを提供していた場合、サービス終了によって相手の業務に支障が出ないよう、データの取り出し方法や移行期間の確保など、契約・信頼関係の観点からの配慮が必要になる。単なるデータ移行だけでは済まないこともあり、契約書に解除条項や損害賠償条項を定めていた場合はその内容の確認が必要になる。特に典型的に問題になりやすいのは、解除条項では「解除の予告期間(1ヶ月前通知など)を守らずに突然停止した場合」、損害賠償条項では「サービス停止によって顧客側の業務に具体的な損害(機会損失や代替システム導入コスト)が生じたと主張された場合」の2つだ。契約書に予告期間の定めがある場合は、まずその期間を守れるかを最優先で確認し、定めがない場合でも慣行として1〜3ヶ月程度の猶予を持たせるのが無難とされている。加えて、業法上一定期間データを残しておかなければならない義務が絡む場合もある。士業側の具体例で言えば、行政書士であれば作成した書類の控えを一定期間保存する義務、税理士であれば帳簿書類を7年間保存する義務など、業種ごとに定められた保存年限がある。サービスを止めた後も、法令上の保存義務だけは別に果たし続ける必要があることを、終了の計画段階で必ず確認しておきたい。

【店舗経営者の場合】 店舗経営者が同業の他店にツールを配って回っていた場合は、士業のような契約関係というより、顔の見える関係性の中でのやめ方が求められる。書面での通知よりも先に、直接会って「実はこういう理由でサービスを終える」と伝える方が、日頃の関係性に合っていることが多い。無料で配っていたツールをやめる場合、「運用費がかさんで続けられなくなった」という事情は隠さずに正直に伝えて構わない。同業者同士であれば、運用費がかかること自体は感覚として理解してもらいやすく、むしろ理由を濁す方が不信感につながりやすい。実務的にやっておきたいのは、各店舗が入力した顧客リストや予約履歴をCSV形式でエクスポートし、サービス終了の連絡と同時に渡すことだ。相手が次に使うツールが決まっていなくても、データさえ手元にあれば紙の台�帳に戻すこともできるし、後から別のツールに取り込むこともできる。可能であれば、代わりに使えそうな無料ツールや、同程度の機能を持つ他のサービスを1つ2つ紹介できると、相手側の業務への影響を最小限にでき、「やめっぱなし」という印象を避けられる。商店会の集まりや、普段からツールの話をしていた場でひと声かけておくと、あとから「聞いていない」という気まずさを避けやすい。

やること：

1. サービス終了を決めたら、できるだけ早く、かつ十分な猶予を持ってユーザーに告知する
2. 有料ユーザーがいる場合は、返金・データ移行・代替手段の案内を用意する
3. 専門職の場合は、契約書の解除条項(予告期間の定めを最優先で確認)・損害賠償条項(業務への具体的損害を主張されるケースを想定)、業法上のデータ保存義務の有無を確認する(例：税理士の帳簿書類7年保存など業種ごとの年限を確認する)
4. 店舗の場合は、書面より先に対面や普段の場で直接伝え、運用費がかさんだ等の理由は正直に共有し、顧客リストや予約履歴をCSV等の形式でエクスポートして渡し、可能であれば代替ツールも紹介する
5. 終了理由を、言い訳ではなく事実として簡潔に伝える文面を用意する

詳しくは → サービスをやめると決めたとき、ユーザーへの伝え方と手順

完了の目安： サービス終了時の告知文面と、ユーザーへの対応手順(返金・データ移行等)の方針が決まっている状態。

STEP6：発信を続け、ファンを増やす

続けると決めた場合も、やめると決めた場合も、あるいはまだ判断がついていない場合も、発信を止めてしまうとそこで得られたはずの機会を逃す。最後のSTEPでは、公開後も無理なく続けられる発信の型を確認する。

STEP6-1：無理のないSNS運用の型

公開直後は勢いで発信できても、本業を持ちながら続けていくうちに、更新が途絶えがちになる。継続できる発信の型を最初から「頑張らなくても回る形」で設計しておくことが、長く続けるコツになる。

やること：

1. 毎回ゼロから考えるのではなく、繰り返し使える投稿のパターン(進捗報告・小さな気づき・ユーザーの声の紹介など)を2〜3種類決める
2. 投稿の頻度を、無理なく続けられる最低ラインに設定する(週1回など)
3. ネタが尽きたときのために、日々の開発・運用の中で気づいたことをメモしておく習慣をつける

詳しくは → 公開後も発信を続けるための、無理のないSNS運用の型

完了の目安： 繰り返し使える投稿パターンが決まり、無理のない更新頻度で1ヶ月続けられている状態。

STEP6-2：ユーザーに口コミしてもらう工夫

発信を続ける最終的な目的の1つは、自分だけでなくユーザー自身が口コミしてくれる状態を作ることだ。使ってくれているユーザーがいるにもかかわらず、口コミの仕組みを何も用意していないケースは意外と多い。

店舗であれば、常連客に「よかったら他のお店の方にも教えてください」と直接伝えるだけでも十分な効果がある。専門職であれば、顧客満足度が高いタイミングで紹介を依頼するのが自然だ。個人ユーザー向けであれば、SNSでシェアしたくなるような小さな仕掛けを用意することも有効になる。たとえば、continueした日数を可視化する進捗バー、1ヶ月の記録をまとめて振り返れるグラフ画面、達成した実績をそのままSNSに投稿できる画像を自動生成する機能などは、いずれも「見せたくなる」きっかけを作る具体的な仕掛けだ。難しい実装をしなくても、「今月は◯回記録しました」という一言を共有ボタンから投稿できるだけでも、口コミの種になる。

やること：

1. 満足度が高いと感じるユーザーに、直接「知り合いに紹介してもらえないか」を尋ねてみる
2. 紹介・シェアしやすい導線(共有ボタン、紹介文のひな形など)をサービス内に用意する
3. 個人ユーザー向けなら、進捗の可視化やSNSシェア用の画像自動生成など、見せたくなる小さな仕掛けを検討する
4. 口コミしてくれたユーザーには、感謝を言葉で伝える

詳しくは → 使ってくれているユーザーに、口コミしてもらうための工夫

完了の目安： 口コミ・紹介をお願いした経験が1件以上あり、紹介しやすくする工夫を1つ以上サービスに反映できている状態。

公開後期の完了条件

印刷して使える形式のチェックリストとして、公開後の育て方チェックリストも用意しています。

• 最初のユーザーが1人以上ついており、声を集める仕組みが実際に稼働している
• 毎月の運用費の実態を金額として把握し、収益(または見込み)との差分を確認できている
• 機能追加の優先順位づけの基準を持ち、「追加しない」判断も下せるようになっている
• 公開から3ヶ月の振り返りを行い、「刺さっている」サインの有無を根拠を持って説明できる
• 続けるか、方向転換するか、やめるかの判断基準を、感情ではなく事前に決めた基準として持っている
• 無理なく続けられる発信の型があり、ユーザーからの口コミ・紹介が生まれる仕組みが1つ以上ある

次のステップへ

このガイドが、構想期・準備期・開発期・公開後期と続いてきた4段階シリーズの最終回になる。次に固定の「次のガイド」はない。アイデアを言葉にするところから始まり、要件を固め、開発会社や自分の手で形にし、規約を整えて公開し、ここまで辿り着いた道のりは、決して一直線ではなかったはずだ。

公開後の現実は、このガイドで扱った通り、一度読んで終わりにできるものではない。声を集め、運用費を確認し、機能を育て、続けるかどうかを見直すサイクルは、サービスが存在する限り繰り返される。だからこそ、このガイドは一度きりの読み物としてではなく、迷ったときに何度でも開き直す「作業台」として手元に置いてほしい。STEP1に戻って初心を思い出す日もあれば、STEP5だけを読み返して次の判断を固める日もあるだろう。それぞれの段階で、あなたのサービスと、あなた自身のペースに合わせて使ってほしい。