スーパーのオーケーが購買データ基盤をクラウド移行、ほぼリアルタイムの分析へ

入社時点のオーケーは、独自に構築したオンプレミスのDWHを使っていましたが、各店舗から上がってくる膨大な購買データを処理しきれず、障害が頻発する状態にありました。長期にわたってデータを蓄積するだけのストレージがなく、処理性能も心もとない。加えてサーバーやネットワークの保守運用の負荷が重く、コスト面の課題も抱えていました。一方で事業側を見ると、商品を安く仕入れるために必要な「大量に売る力」はバイヤーの勘と経験に支えられ、売上は10年で2倍以上の5,000億円規模まで伸びていました。

編集部の見立てでは、この事例の困りごとの核心は基盤の老朽化そのものではなく、事業規模が勘と経験で扱える限界を超えたにもかかわらず、その判断を裏づけるデータを扱う手段が追いついていなかったことにあります。障害の頻発は、そのずれが最初に目に見える形で噴き出した箇所だったのではないでしょうか。これまでうまくいってきたやり方が通用しなくなる手前で危機感を持てたことが、基盤の作り直しという大きな決断につながったと考えられます。

容量の制約がなく、しかもフルマネージド（運用や保守を提供側に任せられる形態）で使えることを条件に置いた基盤選定が、この取り組みの土台になっています。蓄積量の頭打ち、処理性能、保守運用の負荷という三つの課題は、本来それぞれ別の対処が必要なものですが、運用の責任ごと外部に預ける選び方をしたことで、まとめて解ける形に整理されました。製品の機能比較ではなく、自分たちが持ち続けたくない負担は何かという観点から絞り込んだ判断が効いていると見ています。

データが届くと自動的にBigQueryへ読み込まれる、イベント起点の連携の作り込みも見逃せません。基幹システムのリプレースに合わせて連携部分を改修中とされていますが、Cloud Functionsで受け渡しの部分を薄く独立させておく構成なら、周辺システムが入れ替わっても手を入れる範囲が連携部分にとどまります。分析基盤は一度作って終わりではなく、上流の業務システムの都合で何度も揺さぶられるもの。その前提を織り込んだ設計だからこそ、外部環境の変化に大きな手間なく対応できているのでしょう。

アプリ開発では、開発からテスト配信までを一つの環境で完結させる方針が全体を貫いています。テスト配信を自動化できるFirebase App Distributionを使い、UI開発にはGoogleがオープンソースで提供するFlutterを採用して、扱う技術やリソースが際限なく増えないよう抑えている。顧客情報を扱う以上セキュリティは避けて通れませんが、ここもCloud NATやCloud Armor、Identity Platformといったフルマネージドの機能を推奨構成に沿って組み込むことで、独自に作り込むほど脆弱性が生まれやすくなるという構造を回避しています。オーケー側が何を実現したいかを決め、開発パートナーのアイレットが技術選定と実装を担うという役割分担も、この身軽さを支えた要素です。

大量のデータを高速に分析できる基盤へ移したことで、従来の環境ではとうてい不可能だった半リアルタイムの購買分析が可能になり、各店舗で作る弁当や惣菜の数をその時の売れ行きに合わせて調整できるようになります。費用面についても、同じことをオンプレミスで実現しようとすればトータルで何十倍もの費用がかかっていたのではないか、という評価が示されています。Looker Studioによる見える化は一部で実用化が始まった段階、機械学習を用いた売上予測や生成AIによる従業員支援は今後の構想として語られており、この二つは実績ではなく期待の位置づけです。