連載: マイクロSaaS: #1 なぜ米国法人 | #2 Stripe Atlas設立 | #3 年間維持費 | #4 フランチャイズ税 | #5 アイデアの見つけ方 | #6 MVP 1週間 | #7 月$1で運用 | #8 公開後の時期
爆速でMVPを作って公開するまでの流れと気をつけていること
前回、アイデアの見つけ方について書いた。今回は、アイデアが決まった後、実際に動くものを作って公開するまでの流れについて書く。
技術スタックは固定する
アプリごとに技術スタックを変えるのは時間の無駄である。自分の場合、ほとんどすべてのサービスで同じ構成を使っている。フロントエンドのフレームワーク、CSSライブラリ、決済、エラー監視、デプロイ先が全部共通なので、新しいサービスを作るときにゼロから調べることがない。
前のプロジェクトのコードをコピーして、サービス固有の部分だけ書き換えれば骨組みはすぐにできる。認証、決済、エラー監視の組み込みパターンが手に馴染んでいるので、2回目以降のサービスは初回よりもかなり速く作れるようになった。
自分が作ったアプリは、例えば以下の通りである。
LPや認証、ダッシュボードなど、共通の基盤がほとんど似通っていることがわかるだろう。共通の基盤が8割で、その上にアプリごとの機能を2割くらいの労力でトッピングするような感覚である。一度作ってしまえば、2つめ3つめのアプリはかなり楽に作れる。
最初に作るもの
最初に作るのは、LPとコア機能である。アプリをデプロイする価値があるのは、以下の2つの条件を両方満たしている場合のみだと考えている。
- 既存の競合に対する少なくとも1点の優位性があり、それをLPという形式で伝えることができる
- アプリを実現できる技術が実際に存在する
この段階では、自分が作ろうとしているものが、この2つの条件を満たしていることを確かめる。
LPを作ることで、優位性が実際に存在するのか、そしてそれがウェブアプリのLPという形式で効果的に伝えられるのかがわかる。「使えば良さがわかるアプリ」は、実際には誰にも使われない。LPを見て「使いたい」と思わなければ、誰も使ってくれない。なので、優位性が実際に存在して、かつ、それがLPでアピールできることを、LPを作ることで検証する必要がある。
一方で、優位性をアピールできたとしても、それが実際に実現可能なものであるかのチェックも必要である。頭の中で考えていると「まあ、ここをこうすればできるだろう」とナイーブに考えがちだが、実際に作ろうとしたらできなかったということがある。具体的には、「競合より安く提供できると思っていたが、実際の原価は想定より高く不可能だった」「ChatGPTが存在すると言っていたAPIは実は企業向けで、個人開発者は使えなかった」「調べてみると法律的なリスクが大きかった」といったケースである。
これまでの感覚としては、10あるアイデアのうち8つはこの段階で単なる妄想であったことがわかる。そういうものをいつまでも頭の中でこねくり回していても時間の無駄なので、さっさとLPが作れるか、コアな優位性が実現可能かをチェックする方がいい。
何を後回しにするか
1週間で公開するためには、やらないことを決めるのが大事である。判断基準はシンプルで、後から追加するのに莫大な手間がかかるなら今すぐやる、今やっても後からやっても変わらないなら後回しにする、というものである。
| 項目 | 判断 | 理由 |
|---|---|---|
| 決済・サブスク機能 | 今すぐやる | DB設計やユーザー管理に深く関わる。後から追加すると大幅な書き直しが必要 |
| エラー監視（Sentry） | 今すぐやる | 最初から入れておかないと何が起きているかわからない |
| 管理画面 | 後回し | DBを直接見ればいい。今やっても後からやっても実装の手間は変わらない |
| メール通知 | 後回し | なくてもサービスは成立する。ステータスページで確認してもらえばいい |
| 多言語対応 | 後回し | 日本向けなら日本語だけで十分。実際に英語版を作って後から削除した経験がある |
| 完璧なエラーハンドリング | 後回し | 主要なエラーだけ処理する。実際にユーザーが遭遇したエラーをSentryで検知してから直す方が効率的 |
収益化の方法と広告の方法は最初から考える
自分の場合、マイクロSaaS事業をやる究極の目的は、収益を上げることである。学習の喜びや社会貢献、ものづくりの喜びといったものも付随するが、最大の目的は稼ぐことである。なので、社会の役に立つが稼げないアプリは、現時点では作らないことにしている。
この基本に立ち返ると、優位性がありLPでアピールできるとしても、儲からなければやらない。
例えば、Twitterの刺激的な演出に疲れた人向けに、文通のように穏やかに人と人がインタラクションできるアプリを作ろうと思い立ったとする。優位性は明確だし、LPで表現もできるだろうし、実装もできそうである。しかし、このアプリでどうやって収益を上げるのか。無料なら少数の人が使ってくれるかもしれないが、穏やかな体験を謳っているのに広告を入れればユーザーは離れるだろう。有料会員でお金を払ってくれる人も多くはなさそうである。
実現できそうだとわかっても、以下の2つにYESと答えられないなら、やるべきではないと考えている。
- 収益化できるか？（広告収入、フリーミアム、サブスクリプション、買い切りなど）
- 潜在的なユーザーに安価にリーチできるか？（SEOで検索流入が見込めるか、など）
例えばquickfaxjp.comの場合、収益化は都度課金（1回ごとにStripe決済）、リーチは「コンビニ FAX」「オンライン FAX」といったキーワードでのSEO集客、と最初から明確だった。この2つが見えていたから開発に踏み切れた。
公開してからが本番
MVPを作ったらすぐに公開するというのが非常に大切である。アプリのデプロイが1つあたり年に2,000円でできるこの仕組みにおいては、最も重要なのはお金ではなくて自分自身の時間である。会社員をやりながら副業でやっている自分のような人は特にそうで、調査によって発見できる優位性には限りがあり、優位性が有効な時間にも限りがある。1つ1つのアプリに過度にこだわると、その間に手に入れられたかもしれない他の優位性を発見する機会を失っていることになる。
さらに、公開してからGoogleにインデックスされ、ユーザーが流入してくるまでには少なくとも3〜6ヶ月はかかる。SEOの世界では、新規ドメインが検索結果で上位に表示されるまでにこれくらいの期間が必要だと言われており、自分の経験もそれに近い。
たまに「公開1週間で収益化できた話」のような記事がバズっていることがあるが、気にしなくていい。ああいう記事がバズるのは、それだけ珍しくて驚きがあるからである。つまり、ほとんどのアプリは開始直後にバズったりはしない。
それがわかっていても、作っている最中は頭がおかしくなって、「これで億万長者だ」とか「こんなすごいアプリ、バズるに違いない」などと考えるようになってくる。というか、それくらいおかしくなっていないと、アプリを作るなんて面倒な作業を完遂できない。さっさと手放して、全然人が流入しない状態を目の当たりにして、まずはしっかり落ち込んで、冷静になる。それから、SentryやGA4、GSCのメトリクスを頼りに、徐々に改善を重ねてユーザーエンゲージメントを高めていく。1年くらいやって、伸びていれば事業を継続するし、伸びていなければ撤退するか、ほとんど放置でもう数ヶ月様子を見るか、という判断をする。
公開してから最初のユーザーが来るまでの期間は、サービスによってまちまちだが、数週間から数ヶ月はかかると思った方がいい。この間に必要なのは忍耐と、ランニングコストが低いことの安心感である。#1で書いた「損をしない設計」はここで効いてくる。公開と同時に人気を博すると思っていたアプリに全く人が流入しない上に、毎月数万円が維持費で消えていたら、事業をさっさと畳んでもう二度とやりたくなくなってしまうだろう。投資の原則と同じで、一回一回の勝負にこだわらず、とにかく勝ち目のある戦いをできるだけたくさんやるということが、長期的に成功するコツだと信じている。
運用しているサービス
このフローで実際に作って公開したマイクロSaaSは以下の通り。
- 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台で動かしていて、追加コストはアプリごとのドメイン代だけである。共通の基盤を使い回しているので、2つめ3つめのアプリほど構築は速くなる。
連載: マイクロSaaS: #1 なぜ米国法人 | #2 Stripe Atlas設立 | #3 年間維持費 | #4 フランチャイズ税 | #5 アイデアの見つけ方 | #6 MVP 1週間 | #7 月$1で運用 | #8 公開後の時期