0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

個人開発サービスを公開した直後にやるべきことと、やめるべきこと

0
Last updated at Posted at 2026-05-17

連載: マイクロSaaS: #1 なぜ米国法人 | #2 Stripe Atlas設立 | #3 年間維持費 | #4 フランチャイズ税 | #5 アイデアの見つけ方 | #6 MVP 1週間 | #7 月$1で運用 | #8 公開後の時期

サービスを公開すると、最初に起きるのは「何も起きない」である。これは多くの個人開発者が通る道で、自分も例外ではなかった。今回は、この沈黙の期間に何をやって、何をやらなかったかを書く。

公開直後の沈黙にどう向き合うか

ある程度の覚悟は持ってデプロイボタンを押すのだが、それでも目立った反応が返ってこない期間はそれなりに堪える。良いものを作ったという自負がある分、現実とのギャップが効いてくる。

ただ、この沈黙は普通である。検索エンジンに認識されてインデックスが進み、何らかの導線で人が辿り着き始めるまでには、数週間から数ヶ月かかる。それまでの間、何をするかが分かれ目になる。

目的を持たないコーディングをやめる

最初にやめたことの一つが、目的を持たない LP の手入れである。フォントを変えたり、ヒーローセクションの構成を入れ替えたり、配色を試したり、1日が溶けることが何度かあった。

そのときの自分の動機を後から振り返ると、「売上が伸びていない」という焦りに対して、コーディングという慣れた行為で気を紛らわせていただけだった。LP を弄ることと売上の増大の間に、明確な筋道があったわけではない。

目的を持ったコーディングとは、たとえばこういう手順を踏むものを指す。

  1. GA4 や GSC のデータを見て、どこで離脱しているかを特定する
  2. 検索意図と LP のメッセージのズレを言語化する
  3. 「最初の3秒で何を伝えるか」のような明確な改善目的を立てる
  4. その目的を達成するための最小の変更を入れる
  5. 数値で結果を確認する

逆に、「なんとなくダサい気がするので変えた」「他のサービスの LP を見てそれっぽくした」は目的のないコーディングである。時間を投じても効果が出にくいので、別の活動に回した方がよい。

機能追加より、流入経路の改善を優先する

サービスにアクセスが少ない時期に最も陥りやすい誤解が、「アプリの機能がしょぼいから売れない」というものである。

実際の原因はそうではないことが多い。多くの場合、機能不足ではなく、サービスの存在自体が知られていないことが理由である。 検索結果に出てこない、SNS で話題になっていない、誰からも紹介されていない。この状態でいくら機能を足しても、誰も気づかない。

優位性が本物か検証されていないうちに機能を作り込むのは、リスクが大きい。「Twitter よりすごいソーシャルアプリを作った」と思って半年かけて作り込んだ後で、コアな優位性が実は既存サービスにもあった、と判明した場合、その上に積み上げた全てが無駄になる。

機能追加は、ユーザーが実際に触り始めた後で、フィードバックを基にやれば十分である。

公開直後にやるべきは、流入経路を太くするための地味な仕事である。

  • エラーや警告の修正
  • ページ表示速度の改善
  • SEO 用のメタデータ整備(canonical URL、構造化データ、OGP タグ等)
  • サイトマップと robots.txt の整備
  • 構造化データ(FAQ や HowTo)の実装

これらは直接ユーザー数を増やすものではないが、検索エンジンが「このサイトはちゃんとしている」と判断するための土台になる。特に構造化データはリッチスニペット表示の前提条件で、CTR に効いてくる。

広告費を投じるという選択もあるが、自分はランニングコストを最小化したまま事業を回す方針なので今は使っていない。優位性が消える前に勝負を決めたい場合や、ある程度売上が立ってから ROI を確認しつつ投じる場面では、有効な手段だと思う。

数字を毎日見て、他人と比較するのをやめる

個人開発者のブログや X を眺めていると、「公開1ヶ月で MRR $1,000」「ProductHunt で1位」のような成功報告が目に入ってくる。

これは、あまり気にする必要がない。そういう記事を自分が目にしている時点で、その人は既に発信の経路を持っており、その経路があったからこそ早期に流入が得られた、というだけのことが多い。フォロワー100万人の X アカウントから「こんなアプリ作りました」と投稿すれば、初日から大量のアクセスが集まる。それは個人の発信力の話であって、プロダクトそのものの強さとは別の話である。

他人と比較するのをやめて、自分のサービスの数字だけを見るようにした。先週より良くなっているか、先月より良くなっているか。その比較だけで十分である。

ちなみに、こういう「公開1ヶ月で MRR $1,000」系の記事がなぜ多くの人に読まれるかというと、驚きに満ちているからである。普通の人が普通にやって普通に得られる結果なら、誰もわざわざ書かないし読まない。「1日100食食べるコツ」が読まれるのと同じ構造である。

それから、立ち上げ期に GSC や GA の数字を毎日眺めるのも生産的ではない。「伸びないかな」と思って画面を見ても、数字は見るたびに変わるものではないし、見ても次の打ち手につながらない。

ChatGPT に「このアプリ伸びますかね」と相談したこともあったが、当然ながら誰にも分からない。判断できるなら誰も苦労しない。こういう無駄なことをライバルがやっている間に、次のアプリを作っておく方が、結果として優位性につながりやすい。

植物を育てるように、待つ

公開後のサービスは、植物や農作物に近いと思うことにしている。MVP の実装まで漕ぎ着けるのが田植え。そこから半年〜1年かけて、ちょこちょこ世話をすると、実ったり実らなかったりする。植えたばかりの苗を毎日いじくり回しても、成長が早まるわけではない。

筋トレや学習にも同じ性質がある。やればすぐに結果が出ることは、誰でもやる。誰でもやることは他人との優位性にならない。逆に、努力が結果になるまで時間がかかり、しかも必ず報われるとは限らない活動は、面倒なので大抵の人は続けない。だからこそ、続けた人だけが持てる優位性になる。

まとめ

やるべきこと

  • データ(GA4、GSC)を見て、目的を持ったコーディングをする
  • 流入経路の改善(SEO メタデータ、構造化データ、ページ速度、エラー修正)に時間を使う
  • 次のアプリを作る

やめるべきこと

  • 目的のない LP の弄り回し
  • GA4 の数字を毎日見て一喜一憂する
  • 他人の成功報告と自分を比較する
  • ChatGPT に「伸びますかね」と聞く
  • ユーザーが来る前に想像で機能を追加する

運用しているサービス

自分が今このやり方で運用しているサービスを並べておく。

  • incnumber.com — 米国法人向けの電話番号維持サービス。月 $7 で、OpenPhone(現Quo)Starter $19/月の3分の1強。SMS はメールに転送、電話は自動でテキスト誘導するので英語を話す必要がない。
  • faxchat.app — 米国・国際向けのオンライン FAX。Pro プラン月 $12(送信 200 + 受信 300 ページ)は eFax 月額 $19.95 の約6割。サブスクが嫌なら登録不要・1回 $1.50 + $0.30/ページの都度課金も使える。
  • quickfaxjp.com — 日本国内向けのオンライン FAX 送信サービス。月額なし、1枚 ¥300 から、登録不要。コンビニまで行かずスマホからそのまま送れる。

どれも自宅サーバー1台で動いていて、追加コストはアプリごとのドメイン代だけである。


連載: マイクロSaaS: #1 なぜ米国法人 | #2 Stripe Atlas設立 | #3 年間維持費 | #4 フランチャイズ税 | #5 アイデアの見つけ方 | #6 MVP 1週間 | #7 月$1で運用 | #8 公開後の時期

0
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?