バラバラのPOSをAWSで本部に統合し、欠品と過剰在庫を約15%削減

ディスカウントストアE社では、約120店舗にPOSは入っていたものの、各店が売上や在庫をExcelにまとめて本部にメールで送り、本部の担当者がそれを1つのExcelに貼り合わせて集計していました。

課題：店舗ごとのExcel集計で、本部は売れ筋も在庫も後追いだった

膨大な商品を扱う一方で、データが店舗ごとに分かれたまま手作業で集めているために活かせていませんでした。

• 約120店舗のPOSの売上と在庫を、各店が個別にExcelにまとめて本部にメールしていた
• 本部はそのExcelを貼り合わせて集計するため、全店の売れ筋や在庫が見えるのは早くて翌日以降だった
• ECサイトと店舗の在庫・会員が別管理で、全体の状況をつかめていなかった
• 発注は店長の経験に頼っていて、欠品と過剰在庫がどちらも起きていた

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

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

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

• データ取得：各店のPOSや基幹システムから、独自のシステム連携で売上・在庫データをAmazon S3に配置し、着信をAWS LambdaがAmazon Redshiftへロード。EC（Shopify）はFivetranで、会員アプリや仕入のAPIはLambdaで取得します（いずれもAmazon EventBridgeで定期実行）。各店のExcel書き出しと本部の手集計をなくしました。
• ストレージ・DWH：取り込んだデータは全社横断でAmazon Redshiftに集約。連携した生データはAmazon S3に残し、後からの再処理にも備えています。DWHの考え方はDWH（データウェアハウス）とはで解説しています。
• 変換：dbtで店舗や商品カテゴリをまたいで比較できるデータモデルに整え、重い加工はAWS Glueで処理。Elementaryで欠損や異常を継続的にチェックしています。
• 予測：整えたデータをRedshift MLにかけ、SQLだけで店舗別・商品別の需要を予測し、発注の目安を出せるようにしました。
• 基盤・運用：全体の処理はAmazon MWAA（Airflow）で動かし、構成はTerraform、dbtはGitHub Actionsで管理。データの所在はAWS Lake Formationで追えるようにしています。
• 可視化と現場還元：Amazon QuickSightで本部と店舗が同じ数字を見られるダッシュボードを用意し、需要予測は各店舗の発注に反映。欠品や過剰在庫の兆候はSlackに通知しています。

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

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

成果：月60時間の集計が消え、欠品と過剰在庫を約15%削減

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

需要予測をもとに発注を見直した結果、欠品と過剰在庫はあわせて約15%削減できました。本部は集計から解放され、現場は売り場づくりに時間を使えるようになっています。