Ramen Joeはリスボンの一店舗から始まった。現在は5店舗、App Storeで公開中のiOSアプリ、Google Playで公開中のAndroidアプリ、Apple WalletとGoogle Walletに対応したロイヤリティプログラム、そしてグループ全体の業務を回すバックオフィスを持つ。すべてが一つのプラットフォーム上で動いている。
この記事では、そのプラットフォームが何を解決したのか、既製のSaaSを買う代わりに構築することで何を支払ったのか、そして同じことを試みる飲食グループの多くがどこで判断を誤るのかを扱う。
エグゼクティブサマリー
2店舗を超える飲食グループには、初期段階で誰も正しく見積もらない技術的な問題が3つある。店舗ごとに分断された予約。店舗間で顧客を追いかけないロイヤリティプログラム。ローカルファイルとWhatsAppの会話に散らばる業務データ。
Ramen Joeは業務を一つのシステムに統合した。共有予約、単一顧客、ロイヤリティ、デジタルメニュー、スタッフ管理、そして集約された分析基盤。実務的な結果として、リスボンでスタンプを押した顧客はポルトで同じ残高を確認でき、チームは同じバックオフィスから5店舗を管理し、新しい店舗を追加することもできる。
この選択のコストは軽くない。ただし選ばなかった場合のコストは後になって現れる。解約率、スタッフの二重作業、そして根拠のない出店判断という形で。
事業側の課題
一店舗の飲食店がグループになると、単店で機能していたソフトウェアは壊れ始める。ソフトウェアが悪いのではない。もう存在しない前提のために設計されていただけだ。
典型的な症状はこうだ。各店舗が独自の予約モジュールを持ち、多くはGoogleか特定のSaaSに紐づいている。ロイヤリティ顧客のデータは店舗ごとのデータベースに入っているか、もっと悪い場合は紙のノートにある。グループ全体で常連客が何人いるのかを問うと、答えはない。あるのは推測だけだ。
重要な点はここにある。一店舗ならCRMは店長だ。常連の顔を覚え、奥の席が好きな客を知り、日曜に家族を連れてくる客を把握している。5店舗になると、その分散した記憶は機能しなくなる。そして顧客はそれに気づく。
なぜこれが重要か
飲食業におけるロイヤリティは運用上の細部ではない。ビジネスモデルの背骨だ。新規顧客獲得コストは、既存顧客を戻すコストの何倍にもなる。これはほぼすべての業種で真であり、飲食業も例外ではない。
ロイヤリティプログラムが店舗間で顧客を追いかけないなら、来店のたびに初回として扱っているのと同じことになる。実際は違う。顧客は覚えている。覚えていないのはシステムのほうだ。
二つ目の視点は運用面だ。5店舗のグループは、事業判断に足るだけのデータを生む。どの時間帯が先に埋まるか。どの曜日にキャンペーンが必要か。どの店舗のノーショーが多いか。統一プラットフォームがなければ、そのデータは存在しても誰も読めない。
プラットフォームが果たす役割
Ramen Joeのアーキテクチャは、互いに会話する3つのブロックで構成される。リレーショナルデータベースを持つExpressバックエンド、エンドユーザー向けのNext.jsフロントエンド、そしてサイトの体験をモバイル文脈で再現するネイティブアプリ(iOS SwiftUIとAndroid)だ。
PWAではなくネイティブアプリを選んだ理由は説明に値する。技術的な見栄ではない。具体的な3つの理由に基づくプロダクト判断だった。
- Apple WalletとGoogle Walletはネイティブアプリと綺麗に統合する。ロイヤリティカードは端末のウォレットに直接入り、残高が変われば自動で更新される。
- iOSのプッシュ通知には、Webでは体験を損なわずに回避できない制約がある。
- レストランでスタッフが行うタップスキャンには、素早いオートフォーカスとほぼゼロの遅延が要る。Webはまだこの点で劣る。
予約側では、各店舗のカレンダーと非同期に動作する設計になっている。顧客がリスボンで予約すると、テーブルが押さえられるのはリスボンだけだ。しかし顧客プロファイル、来店履歴、席の好み、これらはすべてグループ全体で共有される。
デジタルメニューと、技術依存のない拡張
プラットフォームは5店舗のデジタルメニューも一元化している。チームは同じバックオフィスで商品、情報、各店舗の設定を管理し、チャネルごとに作業を重複させずにサイトとアプリで一貫した体験を保つ。
マルチロケーション管理は、グループの拡張が新たな技術介入を必要としないように設計された。チーム自身が店舗を登録し、営業時間、連絡先、メニュー、テーブル、予約ルール、その他の運用設定を定義できる。
設定が完了すれば、新店舗は同じデータソースからサイトとモバイルアプリに現れる。店舗を一つ増やすためだけにサイトやアプリを作り直す必要はない。これにより、出店の意思決定から新店舗がデジタルチャネルに登場するまでの時間とコストが縮む。
店舗横断のロイヤリティ:これがすべてを変える
飲食グループでもっともよくある摩擦がここにある。どの店舗も自分のプログラムを持ちたがる。どの店長も自店の常連客を見たがる。そしてマーケティング施策は、一店舗に閉じ込められがちだ。
Ramen Joeは逆を選んだ。一つのプログラム、一つのポイントウォレット、一人の顧客。会計上の含意は自明ではない。リスボンで押されポルトで換金されたスタンプは誰が「支払う」のか。それはシステムの分断ではなく、内部の按分ルールで解決する。
顧客はそんなことを考えなくていい。実際、考えない。一度アプリをインストールし、ウォレットにカードを追加すれば、グループのどの店舗でも同じ体験になる。これがロイヤリティにおけるプロダクトマーケットフィットだ。
スタッフの役割
デジタルロイヤリティは、スタッフが協力して初めて機能する。スタンプを押す作業が、紙のカードに物理的なスタンプを押すより時間がかかるなら、スタッフは無意識に手抜きをする。悪意ではない。ピーク時間の過負荷のせいだ。
Ramen Joeのスキャナはこの制約を前提に設計された。ログインしたスタッフはアプリを開き、カメラを顧客のQRに向けるだけで、2秒以内にスタンプが押される。メニューも、中間確認も、入力も要らない。
スタンプを押す権限は、バックオフィスにアクセスする権限とは分離されている。ホールスタッフはスタンプを押す。店長はレポートを見る。グループ管理者はルールを変える。この分離は業務用SaaSではありふれた設計だが、飲食向けソフトウェアではしばしば無視される。そしてあとになって、ポイントの内部不正がなぜ起きたのかと問われる。
予約:自動化を抑えて、統制を保つ
モダンな予約システムには一つの誘惑がある。すべてを自動化することだ。自動確定、自動リマインダー、変更への自動応答。多くの場合、それはうまく動く。
質を重視する飲食では、そうはいかない。土曜の夜の12人の予約は、誰かがフロアを見ずに自動確定されるべきではない。特定のテーブルの指定は、その店舗を知る人間の目を通すべきだ。直前の例外対応には人間が要る。
Ramen Joeのプラットフォームは、店舗ごとに両方のモードを許容する。標準的な予約は自動処理される。大人数や特別リクエストのある予約は承認待ちキューに入る。そしてTelnyx経由のSMSチャネルが予約の1時間前にリマインダーを送ることで、スパムにならずにノーショーを減らした。
SMSは設計上、短い。名前、時間、店舗。キャンセル用のリンク。それだけだ。想定された予約数から算出し、年間1,500通のSMSを初期見積もりとしてプラン化した。これは技術的な上限ではなく、運用の成長に合わせて容量は調整できる。
iOSとAndroidの同時ローンチ
iOSとAndroidのバージョンは同時に開発された。Androidアプリの公開が後になったのは、Google Playの審査が長引いたためであり、段階的にリリースする方針や特定プラットフォームを優先する判断ではない。
2つのアプリは並行して開発され、同じ価値提案を持っている。予約、ロイヤリティ、そして両プラットフォームで一貫した体験。ストアに現れたタイミングの差は、各マーケットプレイスの承認時間の差にすぎない。
コストははっきりしている。React NativeやFlutterのようなクロスプラットフォームフレームワークではなく、2つのネイティブコードベースを維持することになる。これは意識的なトレードオフだ。得るものは、共通分母が許す範囲ではなく、プラットフォームが要求する振る舞いをするアプリだ。
この種のプロジェクトで起きる失敗
同じようなプラットフォームを構築しようとする飲食グループの多くは、同じ3つの誤りを犯す。名前を付けて整理しておく価値がある。
- アプリから始める。成熟したバックエンドと明確な業務ルールがないまま、アプリは運用の混乱をモバイル画面に写した美しい殻になる。
- 予約とロイヤリティをWordPressプラグインに任せる。一店舗なら動く。5店舗では壊れる。
- プロジェクト単位で作って消える制作会社に発注する。ソフトウェアはローンチで終わらない。そこから始まる。
3つに対する解毒剤は同じだ。ソフトウェアをキャンペーンではなくインフラとして扱う。まずバックエンド、データベース、認証、権限、継続的デプロイという土台に投資し、可視の表面はそのあとに来る。
効いた良い習慣
見た目は些細だが、本番稼働に不釣り合いなほど大きな影響を与えた判断がいくつかある。
一つ目。Gitを唯一の真実の源とする。すべての変更はコミットを通り、すべてのデプロイはGitHub Actionsで自動化される。これによって「僕のマシンでは動く」というカテゴリのバグが消え、本番で何かが壊れても数分で戻せる。継続的デプロイの原則についてはGitHubの公式ドキュメントが参考になる。
二つ目。国際化を本気でやる。サイトはポルトガル語と英語で動作し、翻訳ファイルに文字列を集約している。リスボンの飲食店にはやり過ぎに見えるかもしれないが、観光地では顧客の30%がポルトガル語を話さないと気づけば話は変わる。新しい都市に出るときも、システムが最初から多言語対応しているほうが早い。
三つ目。サンドボックスと本番を明確なルールで分ける。Ramen Joeにはテストデータで本番を模したサンドボックス版がある。あらゆる変更はまずそこを通る。これによって新機能を試すときに本物の予約を壊す確率が下がる。
このモデルが当てはまる領域
Ramen Joeのアーキテクチャはラーメンに固有のものではない。複数店舗を持ち、リピート顧客ベースを持つ小売やホスピタリティのビジネスに広く当てはまる。レストラングループ、カフェチェーン、理容室ネットワーク、複数拠点を持つクリニック、複数店舗のジム。
共通項はこうだ。顧客は一人だが、運用は分散している。ソフトウェアがそれを反映していないなら、ロイヤリティで得るべきものを運用摩擦として支払っていることになる。
要点
- 複数店舗を持つ飲食グループには統一されたプラットフォームが要る。分断された予約は、それを統合するソフトウェアより高くつく。
- 真のマルチロケーション対応とは、新しい店舗、メニュー、運用ルールを、サイトやアプリの技術改修なしで登録できることを意味する。
- 本気で継続利用を狙うなら、店舗横断のロイヤリティは選択肢ではない。顧客はどの店舗で使ったかを気にしていない。
- Wallet、プッシュ通知、素早いカメラが体験の核になるとき、ネイティブアプリは正当化される。
- スタッフは顧客と同じくらいシステムのユーザーだ。フローが旧来のやり方より遅ければ、システムは過負荷で回避される。
- Gitを単一の真実の源に、本番とは分離されたサンドボックスを、そして初日からのi18n。あとの高額なリファクタを避ける基礎の判断だ。
- もっとも高くつく誤りは、バックエンドが成熟する前にアプリから始めることだ。
この段階のグループにとって、自然な次の一歩は機能を増やすことではない。測ることだ。どのスタンプが二回目の来店に変わるか。どの店舗がよく留めるか。どのキャンペーンが実際に針を動かすか。統一プラットフォームはその分析を可能にする。あとは見るかどうかだ。