飲食チェーンの「提供時間」を解明する —— BigQuery MLで挑んだ提供時間のモデル化

「提供時間が遅れるのはあのメニューのせいじゃないのか？」

この記事では、飲食店における「勘と経験」の領域であった調理提供時間を、Google BigQuery MLを用いて科学的にモデル化したプロジェクトについて解説しています。
単なる予測精度の追求ではなく、現場が納得し、行動を変えるための「公平な評価尺度」をいかに構築したのか。その実録をお届けします。

第1章：ことの始め —— 「完璧なデータ」が招いた組織の硬直

1.1 理想的なデータの裏にある「数字の暴力」

今回の舞台は、全伝票の98%以上で提供打刻が行われているという、分析者にとっては理想的な環境のレストランチェーンでした。しかし、現場ではこの「完璧なデータ」が、皮肉にも組織の分断を深めていました。

このレストランの平均提供時間は、毎月の平均で前年よりおよそ+2分と悪化傾向にありました。
特に年末年始などの繁忙期には提供時間が非常に長く、前年同日と比較しても大幅な遅延が発生していました 。
管理部は「目標提供時間」という正論で現場を問い詰め、現場の営業部は「早ければいいわけじゃない」「メニューの工程が複雑すぎる」と防衛本能で応戦する。

正確なデータは、互いを攻撃するための「数字の暴力」と化していたのです。

1.2 営業部からの「犯人探し」のオーダー

そんな状態の中、弊社コンサルタントあてに営業部からあるデータ集計の依頼がありました。

「特定のメニューが入ることで、その後の伝票が遅れるのではないか。これをデータで明らかにしてほしい」

実際、特定商品の注文後15分間に発生した伝票を分析すると、厚切りステーキや大皿メニューなどの重量級メニューが入った直後、後続の提供時間が大幅に伸びる傾向が確認されました。
営業部、店舗では当然ながら現場改善に真摯に向き合っていました。しかし一方で、「現場の努力だけではどうしようもない原因」を探していたのです。

1.3 私たちの応え：なぜ「犯人探し」で終わらせなかったのか

営業部の依頼に応え、「メニューAが提供遅延の犯人です」と結論づけるのは容易でした。しかし、コンサルタントとして私たちが抱いたのは「それでは何も解決しない」という危機感でした。

もしメニューを犯人にすれば、店舗は「このメニューがあるから遅れて当然だ」という免罪符を得てしまいます。
一方で、本部は「そのメニューを売るな」という極端な議論に走るか、現場の苦労を無視して「もっと早く出せ」と強いるしかなくなります。
何より、同じメニューを提供していても、平然と回せている「優秀な店舗」と遅延の発生する「課題店舗」が存在するという事実に、誰も向き合えなくなってしまいます。

私たちが目指したのは、「メニューの重さ（不可避なハンデ）」を正しく数値化し、それを差し引いた上で、純粋な「店舗の運営力」だけをあぶり出すことでした。
特定の誰かを責めるためではなく、厨房というブラックボックスの中にある「物理的な構造」を全員で共有できる『共通言語』に変換する。
私たちは単なる集計を超えた「物理モデル」の構築へと舵を切りました。

第2章：モデルの検討と構築 —— 「厨房の提供時間モデル」を定義する

私たちは、営業部の「犯人探し」の要望に応えながらも、それだけにとどまらない、厨房の「物理的な負荷」を洗い出し、モデルに組み込むことにしました。

2.1 モデル検討のためのGemini壁打ち

解析にあたっては「何が提供時間を決めるのか」の仮説を立てる必要があります。
私たちのコンサルタントは店舗での実務経験に基づく「肌感」を持っていますが、これをデータとして明確に定義しないことには客観的な説明はできません。

そこでGeminiを壁打ち相手に、コンサルタントの肌感を伝え、全体を俯瞰して抜けている要素がないか確認し、かつそれぞれの要素をどのようにデータで表現できるかを検討しました。

Gemini壁打ちの結果、具体的には以下の要素が検討すべき候補として挙げられました。

• その伝票のメニュー要因： メイン料理の品数、調理手順の多いメニューの有無、担当ポジションの多くなる組み合わせ（サラダとデザートの同時注文等）の有無。
• 混雑要因： 注文時点での客数・伝票数とこれらに対応するスタッフ数。
• 設備要因： 特殊な店舗設備の有無、店舗面積。
• 人的要因： 店長の熟練度、パートアルバイトの熟練度(学生バイト比率、パートアルバイトの勤続年数等)、チームワークの良さ。

ここで最も重要だったのは、要因を「物理的制約」と「運用的要素」に明確に分け、物理的制約はモデルに採用し、運用的要素はモデルから除外するという設計思想を描いたことでした。

2.2 「あえてモデルに入れない変数」の意図

Geminiとの検討の結果、要因を「物理的制約」と「運用的要素」に明確に分け、物理的制約はモデルに採用し、運用的要素はモデルから除外するという設計思想を固めました。

• 物理的制約（モデルに採用）：伝票客数、特定メニューの有無、スタッフ1人あたりの未提供伝票数、特殊設備の有無。
• 運用的要素（モデルから除外）：店長・スタッフの熟練度、チームワーク。

あえて人的要因を学習させないことで、「この設備で、この注文内容なら、標準的には○分で出せるはずだ」という『公平な物差し（理論値）』を定義しました。
店舗の「運営力」をあぶり出すという私たちの目的に照らして、例えば、「新任店長だから遅い」といった現場の言い訳をモデルが肯定してしまうリスクを排除したのです。

この物差しからはみ出した、実測値と理論値の差異である「残差（Residual）」こそが、店舗の純粋なオペレーション実力であると定義しました。

2.3 BigQuery MLによる「解釈性」の担保

アルゴリズムにはあえてシンプルな「線形回帰（Linear regression）」を選択しました。高精度なブラックボックスよりも、現場の店長に「サラダが入ると○分延びる」と、係数（Weight）をそのままアドバイスに翻訳できる透明性を優先しました。

こうして伝票別の提供時間(実測値)と各変数のデータを揃え、BigQuery MLに投入した結果、得られたモデルは次のようなものでした。

第3章：モデルの評価 —— 「精度」よりも「公平性」を証明せよ

各変数のP値等を見ながら投入データの調整を繰り返し、提供時間の変動の約半分を説明できる精度（R² ≈ 0.5）に達しました。しかし、このプロジェクトの成否は統計指標ではなく、現場の「納得感」にかかっていました。

3.1 店舗間の「ハンデ」を等しく評価できているか

現場が最も懸念したのは、「限定メニューのある店や特殊設備を使う店が、不当に低評価にされないか」という点です。
私たちは各店舗の「理論値」と「実測値」の差異（残差）を比較しました。

• A店（優秀店）：理論値と実測値がほぼ一致。モデルが定義した「物理法則」の通りに、極めて効率的に回せている。
• B店（課題店）：標準的な設備・メニューでありながら実績値が理論値を大幅に上回り、全店で最大のプラス乖離（遅延）を記録。

「A店では回せているのに、なぜB店では遅れるのか」という問いを立てられたことこそが、モデルの公平性が証明された証拠です。設備やメニューという「外部要因」を抜き去り、現場の「実力差」が初めて白日の下にさらされました。

第4章：実装と展開 —— 現場へ届ける「ラストワンマイル」

高度な統計解析を「誰でも、いつでも使える状態」にするため、Looker Studioのダッシュボードにこのモデルを統合しました。

4.1 現場との対話を変える「新しい言語」

このLooker Studioダッシュボードでは日々の実績提供時間と理論提供時間を詳細に確認することができます。

ダッシュボードでは「残差」という言葉を避け、「理論値との差異」という言葉を使用しました。これにより、エリアマネージャーと店長の会話は劇的に変わりました。

• Before：「あの店は限定メニューがあるから遅いのも仕方ない」という漠然とした諦め。
• After：「限定メニューの負荷（1分）はデータで加味されています。その上で5分遅れているのは、シフト体制や準備に課題があるのではないですか？」

4.2 頑張っている店舗に「光」を当てる

この仕組みは、単なる「ダメ出し」の道具ではありません。
ある店では、席数の多さや団体客の多さなど物理的ハンデがありながら提供時間を短く維持できている「影の功労店」であることがわかり、店長と従業員の頑張りを正しく称賛するための根拠が得られたのです。

結びに代えて：AI時代の「翻訳者」として

AIが「答え」を出す時代。だからこそ、その答えを現場の「納得感」と「行動」に変える「翻訳者」としての役割が重要になります。

厨房で流れる汗と焼き場の熱気、ピークタイムの殺気立った空気感。
これらを理解した上で数式を組み、再び現場を勇気づける言葉へと戻す。
それこそが、テクノロジーを「武器」に変える唯一の方法なのだと、私たちは信じています。

自走へのハードルはまだ高く、私たちは今も定期的な分析と報告を通じて伴走を続けています。
しかし、重回帰分析の難解な数式は脇に置き、共通言語を手に入れた現場は、以前よりも確実に前を向いています。

NauticalStarは、これからも「データを愛し、それ以上に現場を愛する」伴走者であり続けます。