「自社サービスやお店のアプリを作りたい。せっかくなら、機能はできるだけ盛り込みたい」——そんな発注をご検討中の方に向けて書いています。
専門用語はできるだけ翻訳し、「どんな課題に、私たちがどう判断して、どう解決したか」を中心にお伝えします。アプリ・SaaS開発に興味のあるエンジニアの方にも、読み物として楽しんでいただける内容です。
題材は、私たちが自社で開発・運営している、コンカフェ（コンセプトカフェ）／メイドカフェ専門のサービス 「コンカフェGo」 です。そして、この記事の主役は新しい機能ではありません。「作らない、と決めた判断」です。
📝 3行まとめ
① アプリは「機能を足すほど良い」ものではなく、足すほど焦点がぼやけ、コストも保守も重くなります。
② 私たちは自社サービス「コンカフェGo」を、新規集客でも予約でもなく“常連化”の一点に絞りました。
③ なぜそう判断したか、そしてそれを低コストで実装する技術選定までを、理由ごとご紹介します。
「アプリを作れば集客できる」の落とし穴
店舗向けにアプリやサービスを作るとき、最初に出てくるご要望は、だいたい同じです。「新しいお客さんを増やしたい」。マップ検索、ランキング、クーポン、SNS連携……「集客に効きそうな機能」を、つい全部入れたくなります。
でも、現場の実態を一緒に見ると、見えてくることがあります。コンカフェは、一度の来店で完結する業態ではありません。世界観・推しのキャストとの会話・イベントの積み重ねによって、お客様の「また行きたい」が育っていく業態です。新規を10人集めても、次につながらなければ、お店はずっと新規を集め続けることになります。キャストも、毎回ゼロから関係を作り直すことになります。
これは、バケツに水を足し続けているのに、底の穴を放置している状態です。私たちはまず、「水を足す機能（＝集客）」より先に、「穴をふさぐ機能（＝常連化・再来店）」を作るべきだと考えました。コンカフェGoの設計は、すべてこの一点から始まっています。
コンカフェGoとは ― 「来た人に、もう一度」に特化したサービス
コンカフェGoは、コンカフェ・メイドカフェに特化したサービスで、2つの顔を持っています。
- お客さん側（iOS / Android で公開中の検索アプリ） … お店やキャストを探し、気になるキャストを「推す」（フォローする）。推しが出勤するとプッシュ通知が届き、通うほどスタンプが貯まる。
- 店舗側（管理ツール） … 出勤表を入れるだけで、推してくれているファンへ出勤通知が届く。来店を記録して「常連／休眠」を把握し、お客様の状態に合わせてお知らせを届けられる。
この2つを貫くテーマが、新規集客ではなく「来てくれた人に、もう一度来てもらう（常連化）」です。ここに振り切ったことが、このサービスの一番の特徴であり、いちばん難しかった意思決定でもありました。次章から、その「振り切る」ために何を“作らなかった”かをお話しします。
判断①：新規集客は“作らない”と決めた
「集客アプリを作りたい」という出発点に対して、私たちが提案したのは、意外に思われるかもしれませんが 「新規集客は、いまお店が使っているSNS（X など）に任せましょう」 でした。
理由は、道具ごとに得意分野が違うからです。
- SNSは、新規の接点・拡散が得意。フォロワーの外にも情報が広がります。
- 一方でSNSは“流れて消える”。タイムラインやアルゴリズム任せで、本当に来てほしい常連にこそ、投稿が埋もれて届かないことがあります。
コンカフェGoが担うのは、その逆側。「すでに一度つながった人へ、確実に届ける」ことです。だから役割を分けました——新規はSNS、常連化はコンカフェGo。さらに、SNSを敵に回すのではなく噛み合わせるために、X投稿文を自動生成する機能もつけて、SNS運用と併用しやすくしています。
💡 発注者の方へ：「全部を1つのアプリに詰める」より、「いま使っている道具と役割分担する」ほうが、開発コストは下がり、現場も回ります。私たちはまず「これは作らず、既存の◯◯に任せましょう」という線引きの提案から入ります。
判断②：人気の「予約機能」を、あえて載せなかった
店舗系アプリで、ほぼ必ずご要望に挙がるのが 「予約機能」 です。一見、鉄板。でもコンカフェGoには載せませんでした。
判断の理由は3つです。
- 予約は、見た目以上に重い仕組みです。席・時間・キャンセル・当日変更・ダブルブッキング防止……作り込むほど開発費と保守の負担が膨らみます。
- コンカフェの来店は“予約必須”ばかりではなく、「推しの出勤を見て、その日に行く」といった衝動的な来店が多い業態です。
- そして何より、私たちが解きたい課題（常連化）の中心ではない。
「鉄板だから載せる」ではなく、「このサービスの目的（常連化）に効くか」で判断しました。結果、機能はぐっとシンプルになり、店舗が毎日やる操作は、基本「出勤表の入力」と「来店記録用QRの掲示」だけ——というところまで削れました。忙しい店舗オーナーやキャストが、毎日無理なく続けられることを最優先にした結果です。
💡 発注者の方へ：機能は、多いほど良いわけではありません。多いほど、作るのも・使うのも・保守するのも重くなります。「目的に効く機能だけを残す」削り込みこそ、私たちが最初に提供する価値だと考えています。
「常連化」を、具体的にどう機能にしたか
方針が決まれば、作るものはシンプルになります。やることは一つ。再来店の“きっかけ”を、お客様ごとに、忘れられる前に届ける。これだけに集中しました。
- 推し（フォロー） … 退店後も接点が切れません。「次に来る理由」を届ける相手が、お店に貯まっていきます。
- 出勤プッシュ通知 … 「推しが今夜18時から出勤します」。SNSで流れて終わりではなく、“今日行く理由”を直接、手元に届けます。
- スタンプ／ポイント … 「あと1回で達成」。次の来店動機を“見える化”します。
- 状態に合わせたお知らせ配信 … 「初回」「最近来た人」「しばらく来ていない人（休眠）」で、届ける内容を変えます。新規には世界観を、常連には推し出勤を。同じ告知を全員に送らないのがポイントです。
- 初回来店を起点にしたステップ配信 … 初めて来てくれた人を放置せず、当日〜30日のフォローを自動で順番に届けます。
派手な機能はひとつもありません。でも、お店の売上を実際に支えているのは、こちら側でした。アプリの操作感やアニメーションも、「毎日つい開きたくなる」気持ちよさを目指して作り込んでいます。
技術の裏側 ― なぜFirebaseで「軽く・速く」作ったか
ここからは少しだけ技術の話を。とはいえ大事なのは技術用語ではなく、「なぜその選択が、コストとスピードに効くのか」だと思うので、その視点で書きます。
コンカフェGoのバックエンド（データの保管・通知・集計を担う“サーバー側”）は、Firebase（Googleが提供するクラウド基盤）の上に作っています。最初から、フル自作のサーバーは組みませんでした。
- 会員登録・データベース・プッシュ通知という「どのアプリでも必要な土台」は、自前で作らず借りる。これだけで初期の開発期間と費用を大きく圧縮できます。
- 「推しているファンにだけ出勤通知を送る」「来店を記録してスタンプを加算する」といった、このサービスの価値そのものにあたる部分だけ、サーバー側の小さなプログラム（Cloud Functions）で作り込む。
これは技術自慢ではなく、お金とスピードの提案です。当たるか分からないサービスを、最初から重く作りすぎない。まず軽く・速く出して、伸びる部分が見えてから作り込む——この順番をおすすめしています。しかもコンカフェGoは、通知をたくさん送っても“通数”で料金が跳ね上がらない構成にしてあるので、お店が増えても運用コストが読みやすい。決済まわりは Stripe に任せ、こちらも自前実装の事故リスクを避けています。
💡 発注者の方へ：「最初から完璧な自社基盤」は、多くの場合オーバースペックです。私たちは「まず小さく出して、当たった部分に投資する」順番を、技術選定の段階からご提案します。
プライバシーを“設計”で守る
常連を“見える化”するうえで、絶対に外せない論点がありました。「お客様の情報を、店舗にどこまで渡すか」です。コンカフェという業態は特に、プライバシーへの配慮が、そのまま信頼に直結します。
私たちの設計判断はこうです。来店は“匿名のまま”記録する。 店内のQRを読むと来店はカウントされますが、店舗側に表示されるのは「初回が何人」「常連が何人」「最近来ていない人が何人」といった集計値だけ。誰が誰か、という個人を特定する情報は、店舗には出しません。
「便利さ」と「安心」は、トレードオフに見えて、設計しだいで両立できます。必要な“示唆”だけを取り出し、リスクの高い個人情報は最初から持たない。これは、お客様の信頼を預かるあらゆるサービスに共通する勘所です。
💡 発注者の方へ：「データを集める」と「個人を特定する」は、分けて設計できます。私たちは、必要な示唆だけを取り出し、リスクの高い個人情報は最初から持たない設計を標準にしています。
私たちが提供できること
コンカフェGoの開発・運営を通じて、私たちはこんなことが得意になりました。
- 「何を作らないか」から決める要件定義（目的に効く機能だけに絞り込む）
- OMOの設計（来店前・来店中・来店後を、ひとつの体験としてつなぐ）／店舗向けアプリ・SaaS
- Firebaseを使った、低コスト・短期で立ち上げるバックエンド構築
- プッシュ通知・セグメント配信・スタンプ／ポイントなどのリピート施策の実装
- 個人情報を持ちすぎない、プライバシー配慮の設計
「アプリで集客したい」「店舗の業務をアプリ・SaaSで効率化したい」「でも何から作ればいいか分からない」——そのご相談の段階こそ歓迎です。まず“作らないもの”を一緒に決めるところから、お手伝いします。“全部入りで重いアプリ”ではなく、“目的に効く、続けられるアプリ”を一緒に作りましょう。
