本部の集計を月30時間なくし、来店予測でフードロスも約10%削減

ラーメンチェーンD社では、約40店舗にPOSは入っていたものの、各店が売上データをExcelにまとめて本部にメールで送り、本部の担当者がそれを1つのExcelに貼り合わせて集計する運用が続いていました。

課題：各店のExcelを本部が手集計していて、数字を後追いだった

データはあっても、店舗ごとに分かれたまま手作業で集めているために活かせていませんでした。

• 約40店舗のPOSの売上は、各店が個別にExcelにまとめて本部にメールしていた
• 本部はそのExcelを貼り合わせて集計するため、全体像が見えるのは早くて翌日以降だった
• UberEatsや出前館のデリバリー売上は別管理で、手数料を引いた実態がつかめていなかった
• 仕込みやシフトは店長の勘に頼っていて、フードロスと人時のムダが出ていた

店舗が増えるほど集計の手間も重くなり、本部が現場を把握しきれない状態でした。

アプローチ：全店を本部のひとつの基盤に集約する

各店のExcel運用をやめ、POSから本部のデータ基盤へ自動で流れる仕組みに置き換えました。

• データ取得：各店のPOS売上は日次でExcelにまとめてCloud Storageへ自動アップロードし、着信をCloud Functionsが検知してBigQueryへロード。UberEatsや出前館、勤怠は各サービスのAPIをCloud Functionsで取得します（いずれもCloud Schedulerで定期実行）。各店のExcelメール送付と本部の手集計をなくしました。
• ストレージ・DWH：取り込んだデータは全店横断でBigQueryに集約。元のExcelはCloud Storageに残し、後からの再処理にも備えています。BigQueryの課金の考え方はBigQueryのコスト最適化で解説しています。
• 変換：dbtで店舗や時間帯、メニューをまたいで比較できるデータモデルに整え、Elementaryで欠損や異常を継続的にチェックしました。
• 予測：整えたデータをBigQuery MLにかけ、店舗別・時間帯別の来店を予測。仕込み量やシフトの目安を出せるようにしました。
• 基盤・運用：全体の処理はCloud Composer（Airflow）で動かし、構成はTerraform、dbtはGitHub Actionsで管理。データの所在はDataplexで追えるようにしています。
• 可視化と現場還元：Looker Studioで本部と店長が同じ数字を見られるダッシュボードを用意し、予測は各店舗の発注やシフトに反映。原価率の悪化や異常な売上はSlackに通知しています。

全体の流れは次のようなパイプラインになっています。

このパイプラインの考え方はデータパイプラインとはで、基盤づくりの全体像はデータ基盤とはで整理しています。

成果：月30時間の集計作業が消え、フードロスも約10%減った

これまで本部の担当者が各店のExcelを集めて貼り合わせる作業に月30時間ほどかけていましたが、自動化でほぼゼロになりました。データは毎日自動で更新され、本部も店長も約40店舗の売上や原価、デリバリーの状況をダッシュボードでリアルタイムに確認できます。

さらに来店予測をもとに仕込みを調整した結果、フードロスは約10%削減できました。

原価率の悪化や異常な売上はSlackですぐ気づけるようになり、本部はExcelでの手集計から解放され、店長もExcel報告の手間が減って、接客と店舗の改善に時間を使えるようになっています。