MenyGo — 5つの役割が互いを止めないための設計 MenyGo

5つの役割が互いを止めないための設計

クライアント

MenyGo — QRモバイルオーダー・決済・デリバリーシステム / 明治神宮球場

会社: Tabi Life株式会社 · 2024年開発 – 2025年本稼働 – 2026年拡張

担当範囲: UI・UXデザイン(主担当)/2025年改善サイクルにおけるプロダクトマネジメント

※本案件の一部データはクライアントの意向により非公開としています。

1. 課題

球場では、需要がごく短時間に集中する。2025年シーズンでは注文の48%が試合開始のタイミングに発生した。観客は列に並ぶために席を離れない。飲み物ひとつのためにアプリをインストールする人もいない。決済は、試合中にやり直す機会がないため、一度で成立しなければならない。

時間帯ごとの注文分布

2. ユーザー

5つの役割が、同じピークの中を、それぞれ異なるリズムで動く。

ロール役割
観客自席のQRコードを読み取り、ブラウザ上で注文・決済する。ダウンロードも会員登録も不要
キッチンカー注文を受け、調理し、メニュー・出店可否・1日の対応可能数を管理する
配達スタッフ注文を担当し、客席まで届ける
運営管理球場と運営会社。物流、配達スタッフの管理、運用と売上の把握
プラットフォーム管理Tabi Life。キッチンカーと配達スタッフの登録、権限管理、決済ゲートウェイとの連携

観客は秒単位で、キッチンカーは調理時間で、配達スタッフは移動距離で、運営はシフトで、プラットフォームはシーズン単位で時間を計っている。

管理画面 運営ダッシュボード 観客の注文画面

3. 判断

課題は5つのインターフェースを作ることではなく、全員が同時に動く状況で、ある役割が別の役割を止めてしまわないようにすることだった。個々の設計判断は、それぞれ詰まりの起きる箇所をひとつずつ切り離している。

詰まる箇所判断
観客が自分の席を離れてしまう自席からQRで注文。アプリも会員登録も不要
1件の注文が配達スタッフ待ちで滞る配達スタッフは注文をまとめて担当することも、店舗ごとに分けて担当することもできる
2人の配達スタッフが同じ注文を取る担当した時点で即座にシステム上へ反映される
キッチンカーの処理が飽和する商品ごとの1日あたり販売上限と、メニュー全体の一括ON/OFF
調理待ちと受取待ちが混ざる「受取準備完了」をワンタップで切り替え、2つの列を分離
QRからの注文と受取 キッチンカーの受注画面 受取準備完了までのフロー

4. 実装

2025年 — シーズン中のPoC。 3回の改善サイクルを実施した:それまで存在しなかった破損商品の処理フロー、グッズ販売、キッチンカー向けネイティブアプリ、安定性の向上。座席のカバー率は同一シーズン内で+770%に拡大した。1回目のサイクルは私の入社前であり、2回目と3回目にデザイナー兼PMとして参加した。

2026年 — 拡張。 今後の試合に向けた予約注文、複数のキッチンカーからの商品を一度の注文でまとめて購入、運営会社側に集約したメニュー管理画面、2段階のアップセル設計。

予約注文 メニュー管理画面 まとめ注文とアップセル

5. 成果

指標MenyGo 2025業界水準
注文のキャンセル率0.36%2〜6%
破損した注文0.06%1〜2%
システムのバグ0.30%
オンライン決済の不具合0.36%
運用トラブル総合率約1.7%10〜15%

シーズン中に報告された問題のうち、85%がシーズン内に解決した。

出典: 国土交通省 · McKinsey · Capgemini · Bloomberg/WSJ · Deliveroo UK 2023年品質監査 · Uber Engineering · ParcelLab。なお、球場は移動距離が短く、席が固定され、交通の影響を受けない限定的な環境であり、この条件は都市部のデリバリーと比べて指標に有利に働く。本結果は、管理された環境におけるPoCとして提示している。

考え方

同時に動く役割を、互いに待たせないこと。 Roles that operate at the same time should never have to wait for one another.