前回、勢いで
「俺は誰かと飯が食いたい！」
というサービスを作りました。ちなみにサービスはこちら⇨俺は誰かと飯が食いたい！
コンセプトはかなり単純です。
「今日、誰かと飯を食いたい」
と思った人が募集を出して、それを見た誰かが参加する。
マッチングアプリほど重くない。
SNSで「誰か飯行こ」と投稿するより、もう少し具体的。
そんな「飯を食う相手を探す」ことだけに特化したサービスです。
そして、ひとまずサービスとして動くところまで作って、リリースしました。
めでたい。
ここからユーザーが来て、募集が増えて、マッチングが発生して……
と思っていたのですが。
リリースしただけでは、人は来ない
当たり前なんですが、
リリースしただけでは誰も来ません。
コードを書いている間は、
- 認証を実装する
- DBを設計する
- UIを作る
- APIを作る
- デプロイする
みたいに、問題がかなり明確です。
エラーが出れば直せばいい。
テストが落ちれば原因を探せばいい。
でもリリース後に出てきた問題は、
「そもそも誰もサービスを知らない」
でした。
しかもこれは、
Error: UserNotFound
みたいに親切にエラーを吐いてくれません。
Google Analyticsを見ても静か。
募集一覧も静か。
通知も静か。
正常に動作しているのに誰もいない。
個人開発で一番怖いタイプの正常系です。
リリース後、まず機能をかなり増やした
とはいえ、最初から集客だけを考えていたわけではありません。
実際にサービスとして運用することを考えると、初期版にはまだ足りないものが大量にありました。
そこでリリース後も、かなり機能を追加しました。
1. 通知基盤
まず手を入れたのが通知です。
募集に参加があった。
マッチングが成立した。
募集内容に変化があった。
こうしたイベントをユーザーが気付かなければ、サービスとして成立しません。
そこで、
- トランザクション通知
- 通知カテゴリ別設定
- 開封計測
- クリック計測
などを追加しました。
単純に「通知を送る」だけではなく、
通知を送った結果、ユーザーが戻ってきたのか
まで見られるようにしました。
2. 「募集するほどではない」を拾うDemand Intent
サービスを作っていて気付いたことがあります。
「誰かと飯を食べたい」
と思っていても、
わざわざ募集を作るほどではない人
が結構いるはずです。
募集を作るには、
「いつ？」
「どこ？」
「何食べる？」
「予算は？」
などを決める必要があります。
これは意外と重い。
そこで、
「この辺で誰かと焼肉行きたい」くらいの需要だけ先に登録できる仕組み
を作りました。
内部的にはDemand Intentとして扱っています。
似た需要が集まれば、
「この条件なら募集にしてみませんか？」
と募集作成につなげられます。
つまり、
なんとなく飯に行きたい
↓
需要として記録
↓
似た人がいる
↓
募集を作る
↓
マッチング
という導線です。
3. 「この募集、成立しそう？」を数値化した
募集を出しても、
誰も参加しなければ意味がありません。
そこで、過去のデータなどから
募集の成立しやすさを推定する仕組み
も追加しました。
まだ巨大なデータセットがあるわけではないので、現状はルールベースです。
時間帯、エリア、募集条件などを材料にして成立可能性を算出します。
将来的にデータが十分集まれば、ここはもっと高度にできると思っています。
ただ、個人開発でいきなり機械学習を始めても、
そもそも学習させるユーザーがいない
という非常に現実的な問題があります。
まずはデータを貯める。
話はそれからです。
4. Time to First Join / Time to Matchを計測
さらに、
募集してから最初の参加者が来るまで何分かかったのか
募集してから成立するまで何分かかったのか
を計測するようにしました。
具体的には、
- Time to First Join
- Time to Match
です。
個人的には、登録者数だけを見るより重要な指標だと思っています。
ユーザーが欲しいのはアカウントではありません。
一緒に飯を食う人です。
登録者が1万人いても、募集して誰も来ないなら意味がない。
逆に登録者が少なくても、募集したら10分で誰か来るならかなり価値があります。
なので、このサービスでは
「どれだけ早く飯相手が見つかるか」
を重要な指標として追うことにしました。
5. 店舗側の機能と収益化も追加
ユーザー同士だけではなく、飲食店側にも参加してもらえる設計にしています。
そこで店舗向けに、
- Businessアカウント
- Business Analytics
- Demand Intelligence
- スポンサー飯
- 空席スポンサー
- エリアスポンサー
などを実装しました。
課金にはStripeを利用しています。
特に面白いと思っているのがDemand Intelligenceです。
ユーザーが
「このエリアで焼肉を食べたい」
「今日この辺で誰かと飲みたい」
といった需要を登録するので、
それを集計すれば店舗側から見ると、
「今どこに食事需要が存在しているのか」
というデータになります。
単なるマッチングサービスではなく、
ユーザーの「飯行きたい」
↓
需要データ
↓
店舗が需要を把握
↓
空席・キャンペーンをぶつける
↓
ユーザーが来店
という構造まで作れないか考えています。
6. Admin Dashboardがどんどん巨大化した
そして、いろいろ計測し始めた結果、
Admin Dashboardもかなり拡張しました。
現在は、
- ユーザー関連指標
- 募集関連指標
- マッチング関連指標
- Time to First Join
- Time to Match
- Business Analytics
- 収益化ファネル
- Demand関連データ
などを見るための管理画面になっています。
個人開発を始めた頃の私は、
管理画面なんて後でいいだろ
と思っていました。
今は完全に逆です。
何か施策を打っても、計測できなければ
「なんか良くなった気がする」
で終わります。
それでは改善できません。
なので、新機能を作るときは
機能を作る
↓
イベントを計測する
↓
Adminで確認できるようにする
までをセットで考えるようになりました。
そして気付いた
ここまでかなり作りました。
テストも増やしました。
E2Eは18件。
Unit Testは67件。
TypeScript、ESLint、Production Buildも通る。
課金もある。
Analyticsもある。
通知もある。
需要分析もある。
成立予測まである。
そして私は管理画面を見ました。
人がいません。
そこでようやく理解しました。
次に実装すべき機能は「集客」だった
エンジニアなので、問題があるとコードを書きたくなります。
ユーザーが募集しない。
→ 募集UIを改善しよう。
マッチングしない。
→ 成立予測を作ろう。
リピートしない。
→ 通知を改善しよう。
全部間違いではありません。
でも、その前に、
そもそもサービスを知っている人が少ない。
という問題がありました。
これはコードベースの中だけ見ていても解決しません。
ということで、ここから
SEOと集客
に手を出し始めます。
SEO、何も分からん
まずGoogle検索から人が来る状態を作ろうとしました。
ここで、
「SEOってtitleとdescription入れればいいんでしょ？」
くらいに考えていた自分が死にます。
実際には、
- title
- description
- canonical
- OGP
- Twitter Card
- sitemap.xml
- robots.txt
- Google Search Console
- Google Site Verification
- 構造化データ
- インデックス状況
- 内部リンク
- コンテンツ
- エリア別ページ
など、やることが大量にあります。
また知らない世界が始まりました。
Search Consoleを設定
まずGoogle Search Consoleを導入。
サイト所有権を確認して、
sitemap.xml
を送信。
さらに、
- TOP
- メディア
- 主要エリアページ
などについてURL検査を行い、Googleからどう見えているか確認するようにしました。
開発者としては、
npm run build
が通れば完成した気分になります。
しかしGoogle側からすると、
「知らんサイトですね」
で終わります。
デプロイ完了と検索エンジンへの掲載は完全に別物でした。
「検索される理由」を作らないといけない
そして最大の問題。
サービスのトップページだけSEO対策しても、
検索流入する理由がほとんどありません。
例えば、
「一人 飯 寂しい」
「東京 飲み友達」
「今日 飲み 相手」
「焼肉 一人 行きづらい」
みたいな検索をした人に対して、
その悩みに答えるページが必要です。
そこで、
メディア機能
を追加することにしました。
サービス開発者自身が、
- 一人飯
- 誰かと食べること
- 飲み相手
- 募集の実験
- サービス開発の裏側
などの記事を書いていきます。
そして自分自身を実験台にした
ここまで作ったので、
当然、自分でも募集してみます。
企画名は、
「アプリ作成者は貧乏飯から回避できるのか！」
です。
サービス上で募集を出して、
誰かが来てくれれば一緒に飯を食べる。
誰も来なかったら……
一人で飯を食べる。
結果。
誰も来ませんでした。
私は一人で卵かけご飯を食べました。
自分で作ったマッチングサービスを使って、
自分で募集して、
誰ともマッチングせず、
一人で卵かけご飯を食べる。
かなり完成度の高い個人開発です。
ただ、これはかなり重要なデータだった
ネタとしては面白いですが、普通に改善点も見えました。
例えば、
- 募集締切は適切だったか
- 募集開始から開催までの時間は十分だったか
- Xでの告知方法は適切だったか
- 募集ページを見た人は何人いたのか
- 見たけど参加しなかった人はどこで離脱したのか
- 初見ユーザーが参加する心理的ハードルは高くないか
などです。
コードを書いているだけでは分からなかった問題が、
実際に自分がユーザーになることで大量に出てきました。
そして、この失敗自体もメディア記事にしました。
SEO用の記事を書くために架空のコンテンツを量産するのではなく、
サービス上で実験する → 結果を記事にする → 記事からサービスに人を呼ぶ
というループを作ろうとしています。
「開発」と「集客」を分けるのをやめた
今回一番考え方が変わったのはここです。
以前は、
開発
↓
完成
↓
リリース
↓
集客
だと思っていました。
今は、
実装
↓
公開
↓
計測
↓
集客
↓
ユーザー行動を見る
↓
改善
↓
記事にする
↓
また集客
↓
実装
だと思っています。
つまり、
集客もプロダクト開発の一部でした。
個人開発、コードを書いている時間だけが開発ではなかった
最初は、
「誰かと飯を食えるサービスを作ろう」
というだけでした。
そこから、
認証を作って、
募集を作って、
通知を作って、
Analyticsを作って、
Stripeを入れて、
店舗機能を作って、
SEOをやって、
Search Consoleを触って、
記事を書いて、
自分で募集して、
誰も来なくて、
卵かけご飯を食べました。
現在地はここです。
でも、個人的にはリリース前より今の方が面白いです。
リリース前は、
「作れるかどうか」
が問題でした。
リリース後は、
「これを本当に使われるサービスにできるか」
が問題になりました。
コードを書けば解決する問題だけではなくなっています。
だからこそ、ここからが個人開発の本番なのかもしれません。
次は、
「実際にどうやって0→1人目のユーザーを獲得するのか」
を試していきます。
卵かけご飯から脱出できたら、また書きます。
ちなみにサービスはこちら⇨俺は誰かと飯が食いたい！