カラオケBanBanアプリに「予約ボタン」を1つ追加するのに、14ヶ月かかった話
こんにちは。 GENDAでプロダクトマネージャー（PdM）をしている船坂です。
2026年3月から、カラオケBanBanのアプリに予約機能がつきました。「イマカラ予約」という名称で展開しています。
アプリのトップに「予約」ボタンが1つ増えた、それだけの話です。
ただ、このボタン1つにたどり着くまでに約14ヶ月かかりました。その裏話を書きます。
なぜ予約機能を作ったのか
これまで、カラオケBanBanアプリでは会員証やクーポン、店舗検索などが主な提供機能でした。
店舗検索機能を以前追加した際に、来店前の起動を獲得できるようになり、アクティブユーザー数を増やすことに成功しました。（詳しくはこちらの記事をご覧ください）
アプリの次のステップとして、アクティブユーザーを店舗来店につなげる機能が重要なフェーズになっていました。
課題感としては、既存の予約システムは電話での予約がメインとなっており、電話を避けるユーザーは予約を利用せず、結果店頭でお待たせしてしまったりお断りするケースが発生していました。また、電話予約はスタッフの対応コストが重いという問題もありました。
そういった背景から、アプリ予約機能の実装を判断しています。
まず開発に10ヶ月、さらにテストに4ヶ月
先に時系列を書くと、開発着手が2025年1月。そこから約10ヶ月かけてシステムを構築し、2025年10月末から30店舗ほどで先行テストを開始。さらに約4ヶ月のテスト期間を経て、2026年3月にようやく全店に出した形です。トータル14ヶ月。
「予約機能に14ヶ月？」と思いますよね。私も最初はそう思っていました。美容院やホテルのWeb予約と同じ要領でいけるだろう、と。
全然いけませんでした。
そもそも「空き状況」が見えない
美容院やホテルの予約は、クラウド上に予約データがあるから成り立っています。アプリからそのデータを見にいけば、空いているかどうかがわかる。当たり前の話です。
カラオケBanBanはそうなっていませんでした。
「あの部屋、今空いているかどうか」という情報は、各店舗に置いてあるローカルPOS——要は店内のPCの中にしかありません。インターネットからは見えない。物理的に断絶しています。
ユーザーがアプリで「今日の19時、空いてるかな」と思っても、その答えは全国の各店舗のPCの中にバラバラに存在していて、外からは知りようがない。これが長年アプリ予約を実現できなかった根本の理由です。
既存のPOSはそのまま、データだけ吸い上げる
じゃあ全店舗のPOSをクラウド対応に入れ替えればいいかというと、数百店舗を一斉にリプレイスするのは現実的ではありません。コストもさることながら、入れ替え期間中に店舗の業務が止まるリスクが大きすぎます。
そこで、既存のPOSには手を入れず、部屋の空き状況だけをクラウドに吸い上げる方針にしました。
オフラインとオンライン、2つの世界の同期
これが言うほど簡単ではありませんでした。
まず、店舗のネットワーク環境が必ずしも安定していません。通信が途切れることもある中で、部屋のステータスをリアルタイムに近い精度でクラウドに反映し続ける必要があります。
さらに厄介だったのが、電話予約との同期や店頭でのウォークイン受付との競合です。
電話予約や店頭での入室が入るのは、店舗スタッフがPOSを直接操作して部屋を押さえるオフラインの世界。アプリ予約はクラウド経由のオンラインの世界。この2つが同じ部屋を同時に取りにいく可能性があります。今回は詳細は省きますが、アプリ予約と同時期に開発していたセルフ受付機からの入室も同時にコントロールする必要があり、実際は更に複雑になっていました。
片方の世界だけで完結するなら難しくありません。ただ、オフラインとオンラインを矛盾なくつなぎ続けるとなると、話が変わります。部屋の確保時にPOSと連携してロックをかける仕組みを作り、ダブルブッキングを防ぐ。地味ですが、非常に重要な仕事でした。
実際、テスト初期には通信の遅延が原因で、電話予約とアプリ予約がほぼ同時に入り、同じ部屋がダブルブッキングされるケースが発生しました。ロックのタイミングや同期頻度を都度都度詰めていく、という地味な作業を繰り返して潰しています。
料金計算という魔窟
部屋の空きが見えるようになりました。次の問題は「で、いくらなの？」です。
「料金はお店でご確認ください」で済ませることもできましたが、自分がユーザーだったら金額がわからない予約はしたくない。ここはちゃんとやりたいと考えました。
ところが、カラオケの料金体系はとにかく複雑です。
会員種別（一般・学生・シニアなど）
曜日・時間帯（平日昼と土曜夜では全然違う）
コース（フリータイム、30分単位、飲み放題付き...）
人数の内訳（大人2名＋学生1名のような混合パターン）
店舗ごとの例外ルール（料金表が店舗によって異なる）
これらが掛け合わさって最終的な金額が決まります。しかもこのロジックは、各店舗のPOSの中でしか動いていませんでした。外から参照する手段がなかったのです。
やったのは、このPOSの料金計算ロジックをクラウド上に作り直すこと。店舗ごとの料金マスタをクラウドに同期し、条件を入力すれば概算料金が返ってくるAPIを新しく構築しました。税込計算や飲み放題プランの自動付与なども含めて、POS側の挙動をできるだけ忠実に再現しています。
POS側の計算結果と突き合わせて検証する作業が一番骨が折れました。条件の組み合わせが膨大で、「この店舗のこの曜日のこの時間帯にこの会員種別で入ると金額が合わない」というケースを1件ずつ潰していく日々です。
これにより、予約の確認画面で概算料金が表示されるようになりました。金額を確認してから予約を確定できる。予約の完了率に直結する部分だと考えています。
※現在、機能上では予約時に概算料金が表示できるようになっていますが、時期によっては料金が非公開となるケースも存在します。
予約して、来店して、部屋に入るまで
予約が取れるだけでは、体験としては半分です。お店に着いてからのチェックインまでスムーズにつなげて、ようやく「予約してよかった」になります。
カラオケBanBanではセルフチェックイン端末を導入している店舗があり、この端末と予約データを連携させました。予約済みのお客さまが端末で予約IDを読み取ればチェックイン完了、という流れです。
ここでも細かい調整が山ほどありました。たとえば、予約時間より10分早く来た方の入室時刻をどう扱うか。逆に遅刻した場合、どこまで予約を保持するか（一定時間を超えたらウォークイン扱いにする、など）。「実際の店舗で何が起きるか」を想定して、ひとつずつ潰していく作業です。
30店舗で4ヶ月やってわかったこと
先行テストの4ヶ月間は、システムの検証と同じくらい「現場のオペレーション」に時間を使いました。
やってみてわかったのは、システムが正しく動くことと、お客さまの体験が成立することはイコールではないということです。
予約通知が来たときにスタッフがどう動くか。予約された部屋を事前に清掃しておくフローをどう組み込むか。ピーク時間帯に予約のお客さまと飛び込みのお客さまが重なったとき、受付でどう回すか。コードでは解決できない問題がたくさんありました。ここは開発チームだけでは答えが出せない領域で、店舗スタッフと一緒に「どう運用するか」を考える時間が不可欠でした。
予約機能をリリースしてみて
機能リリース後、すでにたくさんのユーザーに予約機能を利用いただき、良いデータが取れています。
リリース直後から爆発的にアプリ予約利用数が伸び、すでに予約者の3人に1人はアプリ予約経由に
一度アプリ予約を利用したユーザーは、ほぼ全員(96%)アプリ予約を利用し続ける
アプリ予約は電話予約よりも6ptキャンセル率が低い
おわりに
アプリにボタンが1つ増えた。ユーザーから見ればそれだけのことだと思います。
ただ、このプロジェクトを通じて強く感じたのは、物理店舗を持つサービスのDXは「システムを作って終わり」にはならないということです。お客さまが触るのはアプリの画面ですが、その裏側では、店舗のPC、ネットワーク、スタッフの動き方、あらゆるレイヤーをまたぐ仕事が動いています。
GENDAにはカラオケBanBanだけでなく、GiGOをはじめとしたアミューズメント施設やF&Bの店舗など、全国に千を超えるリアル店舗があります。「デジタルとリアルの接点をどう設計するか」という問いは、まだまだ手付かずの領域ばかりです。
まずは「カラオケBanBanってアプリから予約できるんだ」と思っていただけたら嬉しいです。
読んでいただきありがとうございました。
イマカラ予約について詳しくはこちら！
GENDAでは一緒に働くメンバーを募集中です！
関連ジョブ（Product Manager）
