こんにちは、モバイル開発部の磯崎です。
先日、2025年9月に「BanBan NAVI」という「カラオケBanBan」向けのiPad用の店舗業務DXアプリをリリースし、全店舗への展開を実施しました。
本記事では、これまで私が取り組んできたBanBan NAVIの開発において、特徴的だったポイントを紹介します。
BanBan NAVIとは
GENDAのグループ企業であるシン・コーポレーションは、全国に約400店舗の「カラオケBanBan」を展開しています。昨年には顧客向けアプリの内製化が行われ、「BanBanアプリ」がリニューアルされました。
そして、「BanBanアプリ」の内製化に伴い、セルフ予約端末の導入やアプリへの予約機能追加など、さまざまなプロジェクトが進行しています。「BanBan NAVI」もその一つで、全店舗に設置されるiPadで利用される、店舗スタッフ・店長・複数店舗を統括するスーパーバイザー（SV）向けの業務DXアプリとして開発が始まりました。私は、アプリ導入が決定し、技術選定を行う段階から本プロジェクトにアサインされました。技術選定については後の章で触れます。
BanBan NAVIは、日々の業務をデジタル化し、現場の店舗運営をサポートすることを目標に、以下を重視して開発を進めています。
- 「紙」「Excel」「口頭」などに分散していた情報を一元管理する
- 店舗の営業状況をリアルタイムに遠隔から確認し、施策や指示を円滑化する
初期リリースでは、スタッフが日々の業務内容・共有事項を記録する業務報告機能、レジ・入金まわりの点検報告機能、そしてマニュアル閲覧機能など、現場スタッフの“日常の動き”に寄り添った機能を搭載し、BanBan NAVIを店舗オペレーションに自然に馴染ませることを重視しました。
なお、GENDAのnoteでも本プロジェクトに関するインタビュー記事があるので、こちらもご覧いただければ幸いです。
プロジェクト体制と私の役割
本プロジェクトにおいて、私はPdMと技術のリード役の両方の役割を担うことが求められました。
アサイン当初は、カラオケBanBanを運営するシン・コーポレーションの内部事情を知らなかったり、関係者とも面識がまだない状態でした。さらに、私自身のこれまでの経験がフロントエンド領域がメインだったこともあり、店舗業務へ深く入り込みつつ、技術的にも広い範囲をカバーしなければならないという点もあり、新しい挑戦への期待感と同時に不安も感じていました。
しかし、今振り返ってみると、本プロジェクトは以下の理由から、リスクを恐れず裁量を持って進められる環境だったと感じています。
- アプリの利用範囲がtoCではなく店舗内に閉じており、バグによる業務影響が最小限で収まる
→ 影響範囲が限定されており、思い切った開発ができる - ユーザー規模が端末約400台、従業員ベースでも約5,000人ほどであり、toCサービスと比較すると規模の変化が予測しやすい
→ その数を踏まえた上で多くのサービスを無料枠で試せるため、スピード感のある技術導入が可能 - PdMおよび技術のリード役として上流（ヒアリング・要件定義・設計）から下流（実装）までの全工程を担当
→ 要件と技術の両面を理解しているため、開発サイクルを高速で回せる - 少数精鋭チーム（私、PM、デザイナー、業務委託エンジニア、インターン）
→ 伝言ゲームが発生せず、仕様の意図が正しく実装に反映される - GENDAとシン・コーポレーションの皆さんの、優しく頼りになるサポート
→ プロダクトマネジメントや技術的な設計・実装についても、相談できる方々の伴走サポートが支えになった
技術選定
フロントエンド：Flutter
選定理由
日々の店舗での利用を前提に、まずはiPadアプリとしてネイティブレベルのUXを提供したいと考えていました。
さらに、複数店舗を管理する社員向けに店舗外からもアクセスできるようにすることを見据え、クロスプラットフォーム対応でWebにもスムーズに展開できるFlutterを採用しました。
設計方針
アーキテクチャは、BanBanアプリでも採用されている、TCA（The Composable Architecture）をベースにした構成で、状態管理や依存関係を明確にしています。
また、UIはiPad最適化を意識し、タッチ操作や一覧性を重視しています。
本プロジェクトで採用したアーキテクチャ
バックエンド：Go
選定理由
BanBanアプリやその管理画面などでもGoが使われており、開発者が両方のシステムを担当する際のコンテキストスイッチを最小限にできる点が大きな理由です。
また、シンプルで高速なAPI開発が可能で、リアルタイム性の高い店舗業務にも向いています。
設計方針
アーキテクチャは、Clean Architecture（クリーンアーキテクチャ）を採用しています。Handler/Usecase/Entity/Adapterの各レイヤーを明確に分離し、ビジネスロジックが外部依存（DB、Firebase等）に影響されない設計としています。
また、データベースアクセスにはCQRS（読み取り/書き込み分離）パターンを導入し、将来的なスケーラビリティを確保しています。
本プロジェクトで採用したアーキテクチャ
インフラ：AWS
GENDAではAWSを標準の技術スタックとして採用しており、今回のプロジェクトでも統一しています。BanBanアプリもAWS上で動作しているため、データ連携・運用保守の一貫性を確保できます。
インフラ（認証・Web基盤）：Firebase
FlutterはFlutterFire（Firebase公式プラグイン群）との親和性が高いことから、認証・アカウント管理（Firebase Authentication）やWeb対応（Firebase Hosting）のために一部Firebaseを導入しました。これにより、iPad・Web両対応のアプリ基盤を初期からシームレスに設計できます。今後はPush通知（Firebase Cloud Messaging）なども見据えています。
開発期間
以下のプロセスを経て、約3ヶ月で要件定義からアプリの全国店舗展開までを完了させました。
1ヶ月目（6月）：ヒアリング・要件定義・ワイヤーフレーム作成
カラオケBanBanの店舗にiPadが導入されるタイミングで、業務日報と店舗MTGの議事録をアプリに実装するというミッションを受け、プロジェクトがスタートしました。
まずは、過去の店舗見学ドキュメントを読み込み、実際に店舗へ赴いて店長やSVの方々に業務の実情を見せていただきながら、課題をヒアリングしました。また、本部に提出されている業務日誌のスキャンデータを100枚ほど確認し、現場で行われている記録業務の全体像を把握しました。
その過程で、店舗MTGの議事録はアプリで実装する必然性が薄いと判断し、今回は対象外としました。一方で、業務日誌については、現場の運用負荷を大きく下げられる手応えがあったため、DXアプリとして「使いやすい形」に落とし込む方針に決定しました。
既存の業務日誌は、重要度の異なる多様な項目が混在していたため、まず関係者へのヒアリングを行い、アプリ上で「入力すべき情報」「閲覧すべき情報」を整理・取捨選択しました。
その上で、何度も改善を重ねながらワイヤーフレームを作成し、Figma上で画面を設計しました。そして、現場の方々から適宜レビューをもらいながら、レイアウトや体験をブラッシュアップしていきました。
ワイヤーフレームはデザイナーによってリファインされ、段階を追ってUIが洗練されていきました。
以下は業務報告一覧画面の例です。
現在では、この画面にさらに機能が追加され、よりリッチな構成になっています。
構想フェーズ（一次ワイヤー）
設計フェーズ（二次ワイヤー）
デザインフェーズ（UI完成）
2〜3ヶ月目（7〜8月）：設計・実装・PoC・全国店舗へ展開
完成したワイヤーフレームをもとに、テーブル設計やAPI設計をドキュメントにまとめ、すぐに実装フェーズへ移行しました。実装については、Claude Codeを活用したバイブコーディングでテンポよく進めていきました。
フロントエンド（アプリ）側の開発は主に私が担当し、インフラやバックエンドについては既存の仕組み（BanBanアプリなど）を活用する構成だったため、一部のみ実装を担当する形になりました。
当初は8月初旬にテスト店舗へ配布（PoC）する予定でしたが、進行が遅れてしまったため、ガントチャートを作成し、進捗が遅れたら即アラートを出す“背水の陣”の進行管理で巻き返しを図りました。
テスト店舗へのリリース後は、現場からいただいたフィードバックを取り込みつつ修正を実施し、8月末には全国の店舗に向けてiPadへカスタムアプリ+MDM配布で展開することができました。
BanBan NAVIの技術的な特徴
BanBan NAVIは社内向けシステムのため、いくつか技術的な特徴があります。
カスタムアプリ
アプリはカスタムアプリ配布で展開しました。
簡単に説明すると、社内向けのアプリを外部には見えないように、App Store経由でMDMや引換コードなどを用いて社用端末にアプリをインストールする配布方法です。
今年のiOSDC Japan 2025では、このテーマで登壇もしています。
アカウント方式
カラオケBanBanの店舗・社員に関わるアカウント体系は、DXプロジェクトにおける「アカウント設計の考え方」の一つの解として整理できます。
アカウントの方針としては、アルバイトスタッフを含めてすべての個人に対してアカウント付与を行う、あるいはそもそもアカウントを作らないなどの選択肢がありました。しかし、アカウントのIDをメールアドレスとすることを踏まえ、以下の環境から「店舗共通アカウント」と「個人アカウント」に分けて運用することに決めました。
カラオケBanBanにおける店舗・従業員のメール運用環境
- 店舗単位で専用の店舗PC用メールアドレスが付与されている
- 正社員には個別のメールアドレスが割り当てられている
- アルバイトスタッフには個人用のメールアドレスは支給されていない
現場運用の負荷を最小化できる（アルバイトスタッフの出入りが多くても管理がシンプル）こと、職責に応じたアクセス権限を柔軟に管理できる（店長・SV・本部）こと、そしてセキュリティと利便性を両立したアカウント体系を構築できることから、今回のようなカラオケ店舗のDXアプリケーションにおけるアカウント体系としてこの方式によるメリットは大きいと考えています。
店舗共通アカウントと個人アカウントの役割分担は以下の通りです。
店舗共通アカウント
- 基本的に店舗ごとに1つずつ発行され、店舗業務に必要な最低限の情報・機能にアクセスできる
- 店長を含むすべての店舗スタッフが、iPadでこのアカウントを使用
店舗オペレーション（現場業務）に特化した、最低権限のアカウントと言えます。
個人アカウント
- 店長・SV・本部社員に発行され、役職に応じて権限を管理（閲覧範囲・編集範囲の差別化）
- 後述のWeb版でこちらのアカウントを使用
- アカウントに紐づいた店舗に応じて店舗横断のデータ閲覧
個人の職責に応じた、可変的なアクセス権限を管理できるアカウントと言えます。
iOSアプリとWeb版
BanBan NAVIはiOSアプリとWeb版の2つのアクセス方法に対応しています。しかし、同じアプリであっても、それぞれで「利用者」「利用場所」「ユースケース」が異なります。
| 項目 | iOSアプリ（店舗オペレーション向け） | Web版（マネジメント向け） |
|---|---|---|
| 主な利用者 | ・アルバイト ・店長 → 店舗共通アカウント |
・SV ・兼任店長 ・本部スタッフ → 個人アカウント |
| 利用場所 | 店舗内（店舗に固定） | ゆくゆくは店舗外からもアクセス可能に |
| 主な用途 | ・業務内容入力 ・点検作業記録 ・店舗スタッフへの共有事項登録 など、入力作業が中心 |
・複数店舗の営業状況確認 ・報告内容チェック など、閲覧・分析が中心 |
終わりに
現在は、店舗ごとのルーム稼働状況を確認できる機能や、売上分析機能などを鋭意開発しています。今後は、既にBanBan NAVIに搭載したい機能案を多くいただいており、さらなる機能拡充を進めていきます。
BanBan NAVIを通じて、店舗業務に関わるすべての方がより幸せになれるよう、これからも尽力していきます！
Discussion