実績の一覧に戻る
本業2026年5月〜現在
大型音楽フェスのモバイルオーダー
会場の飲食エリアの行列をなくすため、
事前注文と受取時刻の予約ができる仕組みを
企画から実装まで担当。
担当した工程
- 企画（担当）
- 要件定義（担当）
- 基本設計（担当）
- 詳細設計（担当）
- 実装（担当）
- テスト（担当）
- 構築・導入（担当）
- 運用・保守（担当外）
どんな状況だったか
来場約8,000人を想定した大型音楽フェスで、
飲食エリアの行列が課題になっていました。
人の集まる時間帯に列が伸び、買うのをあきらめる来場者が出ます。
出店者の側も、どれだけ仕込めばよいかの見通しが立ちません。
本当の問題は何だったか
表面の要望は「スマホで注文できるようにしたい」です。
ただ、注文をスマホにしても、受け取りに人が集中すれば、
行列の場所が変わるだけです。
本当に解くべきなのは、受け取りの時間を分散させることと、
出店者が注文の量を前もって見通せるようにすることでした。
どう判断したか
受け取りの方式
- 選んだ案
- 受取時刻を15分単位の枠で予約してもらい、
空いている枠をおすすめとして表示する - 選ばなかった案
- できた順に呼び出す到着順の方式
- 理由
- 枠で予約してもらうと、受け取りの時間が分散し、
出店者も枠ごとの注文数を見て仕込めるためです。
画面の更新方法
- 選んだ案
- スタッフの画面は即時に更新し、
来場者の画面は15秒ごとに最新の状態を取りにいく - 選ばなかった案
- すべての画面を即時更新にする
- 理由
- 来場者全員を即時更新でつなぐと、同時接続の上限と費用が問題になります。
画面更新に数秒の遅れがあってもクリティカルにはならないと判断しました。
障害への備え
- 選んだ案
- システムが止まったときに従来の運用へ切り替える手順と、
切り替えの判断基準を先に決めておく - 選ばなかった案
- システムの冗長化だけで備える
- 理由
- イベント当日は、止まった原因を調べる時間がありません。
総合的に判断し、現場が迷わず動けることを優先しました。
何をしたか
- 来場者向けの注文画面、スタッフ向けの注文処理画面、
主催者向けの管理画面の3つで構成した - 注文の滞留量をもとに混雑を予測し、
直近の実績と予測の差で補正するアルゴリズムを実装した - 決済の二重実行を防ぐ仕組みを見直し、店頭の決済端末との併用も設計した
- 公開前の点検で、権限チェックやデータアクセス制御の不備を洗い出して是正した
- スマホでの操作性を見直し、アクセシビリティの評価を86から96に上げた
- 仕様書のほか、法務・経理・情報システムの
各部門が判断に使える資料をまとめ、調整を進めた
結果と、次に変えること
年末の本番に向けて準備を進めています。
使用技術
- TypeScript
- Next.js
- React
- Supabase
- Vercel
- Square
- Web Push
- Vitest
似た状況でお困りでしたら
まだ形になっていない段階のご相談も歓迎です。
内容を拝見し、お手伝いできるかどうかを含めてお返事します。