マルチプロダクトのデータをつなぐ STORESのデータ基盤の現在地

STORES Data Lounge #3
「マルチプロダクトのためのデータ設計と活用」で発表した資料です。

Transcript

1. マルチプロダクトのデータをつなぐ STORESのデータ基盤の現在地 STORES Data Lounge #3 「マルチプロダクトのためのデータ設計と活用」 2026/08/25 STORES 株式会社 テクノロジー部門 データ本部 データ基盤グループ 佐藤 翔太
2. 自己紹介 名前： 佐藤 翔太 職歴： 〜 2023年12月 電機メーカーでカーナビの走行データの解析基盤を構築 2024年1月 STORES入社 データ基盤の保守開発 MyFun： ギター/お酒/最近は子供とサッカーを見るのが楽しい X:ssxota 2
3. 今日話すこと • • マルチプロダクトであるSTORESにおけるデータ基盤の特徴と課題 今後の展望 3
4. データ基盤の概要図 4
5. データ基盤からみるSTORESの特徴 ① • 店舗の業務支援に特化したプロダクトをM&Aで拡充 / 統合基盤の開発に投資 ◦ 共通IDでのプロダクト統合 / 統合画面での管理業務が可能に 統合基盤 事業者 ログイン 各プロダクト 事業者基盤 ID基盤 事業者・店舗・従業員の 認可/管理 共通IDの認証/管理 権限判定 管理業務 統合管理画面 全サービス共通の 管理画面 顧客管理 顧客基盤 プロダクト横断で 顧客データを統合 課題 • AWS/Google Cloud のマルチクラウド構成かつマルチプロダクト ◦ データソース引き込みをシンプルにして保守工数を抑えたい 5
6. ソース引き込みのシンプル化：プロダクト（AWS連携） • ECS 上で embulk をオンデマンド実行して抽出 ◦ ECSのクラスター管理のコストが課題 • RDS・MongoDB のスナップショット機能で S3 に Export → GCS → BigQuery ◦ プロダクト共通の引き込み形式とすることで管理工数を省力化 ◦ AssumeRoleWithWebIdentityによりAWS → Google Cloud 間のキー管理を排除 6
7. ソース引き込みのシンプル化：プロダクト（Google Cloud連携） • Cloud SQL/AlloyDBに対して外部接続を作成し、データ基盤側へ外部接続を共有 ◦ 転送ジョブ・データコピーが不要で、保守対象が存在しない ◦ 同一クラウドのため認証は IAM のみ ◦ クエリ時点の最新データを参照できる 7
8. リアルタイム転送 • • • CDC等のリアルタイム転送はスコープアウト ◦ 定常的なリアルタイム需要がなく、保守工数も確保できないため hourly の同期頻度が必要なユースケースはTROCCOでの増分転送で対応 API経由のイベントを内製のイベント送受信基盤Event Repositoryから取得 ◦ 各プロダクトが非同期にイベントを送受信 ◦ データ基盤へは Pub/Sub 経由で BigQuery にリアルタイム連携 8
9. データ基盤からみるSTORESの特徴 ② • 各プロダクトに紐づくSaaSの統合・改修が高頻度に発生 ◦ CRM統合 ▪ 各プロダクトごとのCRM環境を統合環境に移管 ◦ ◦ ◦ ◦ 決済領域での端末配送/審査業務でのkintone利用 課金基盤としてのZuoraの採用 サポート（Zendesk）・メール配信(Mailchimp) など Google/Meta/Microsoft/Yahoo等の広告媒体 課題 • SaaS連携の改修頻度が多く工数増 • SaaS側にデータ基盤のデータを書き戻すリバースETLの案件も高頻度に発生 9
10. SaaS連携 • Python・Ruby による自作スクリプトでの連携からTROCCOへ移行 ◦ 変更頻度の高いSaaS連携を省力化 ◦ データ基盤からデータを書き戻すリバースETLもTROCCOに移管 10
11. リバースETLの複雑化 • 事例：アカウント開設時のアンケート /設定情報の CRM連携 ◦ アンケート連携後、CRM上でのセールス側のオペレーション有り Before After 店舗開設時 設定情報 店舗開設時 設定情報 統合管理画面 統合管理画面 予約 アカウント開設時アン ケート 統合環境 アカウント開設時アン ケート BigQuery ネットショップ /レジ アンケート設問の変更時に BigQueryのロジックが 把握されておらず正しいデータが連携できず CRM環境統合のタイミングで プロダクト側からの送信経路に変更 データ基盤からのリバースETLは、プロダクトから見えにくく障害要因になりやすい >> データ基盤での実装がMustでないものはプロダクト側で実装できるよう調整 11
12. データ基盤からみるSTORESの特徴 ③ • 事業・プロダクトのフェーズごとに多様な分析要件 セグメント 売上規模 事業者 業種 共通の事業者 ID 法人/個人 ⋮ ネットショップ 店舗 共通のネットショップ ID 共通の店舗ID ネットショップ レジ プロダクト単体での分析 予約 プロダクト開発の影響 • プランも新旧が混在 • 統合環境への移行も段階的に進行 決済 ペアでの分析 プロダクト全体での分析 課題 • データの提供先が多岐にわたり、モデル変更や障害時の影響把握が困難 • 分析要求にデータ整備が追いつかず、データ構造が複雑化 12
13. データ管理 • • dbt Coreを採用しデータ間の繋がりを管理 staging → warehouse → mart の3層構成 ◦ component 層の整備中 • dbt exposures で主要な提供先（Metabase, Looker Studio, Connected Sheets）を管理 ◦ モデル変更時や障害時の影響を把握 BigQuery exposures 月次集計シート 月次売上サマリ mart モニタリング ダッシュボード A社提供 ダッシュボード 13
14. データ構造の複雑化：事業者の月次粗利を集計するには？ • • OBT（One Big Table）：JOIN 不要のワイドテーブルで抽出・モニタリング依頼に応える mart 間参照の許容：既存 mart の集計結果を再利用して速く作る warehouse 層 mart 層（プロダクト別） mart 層（店舗横断） mart 層（事業者横断） ネットショップ 店舗マスタ（ OBT） ネットショップ 注文明細 月次サマリ mart 店舗×月サマリ mart 事業者×月サマリ mart 店舗×月の粗利 プラン料金 ⋮ 決済 店舗マスタ（ OBT） 取引明細 決済 月次サマリ mart 店舗×月の粗利 プラン料金 ⋮ 予約 店舗マスタ（ OBT） 予約 予約明細 mart サブスク契約 mart ⋮ ⋮ 月次サマリ mart 店舗×月の粗利 14
15. データ構造の課題 • mart 間の参照が多層化し、リファクタリングと障害影響の面で課題 warehouse 層 mart 層（プロダクト別） mart 層（店舗横断） mart 層（事業者横断） ネットショップ ネットショップ 店舗マスタ（ OBT） 判定ロジック 月次サマリ mart 店舗×月サマリ mart 事業者×月サマリ mart 店舗×月の粗利 ⋮ ロジックが OBT mart の中に実装されている 再利用するには mart そのものを参照するしかない 参照の多層化 個別要求で作った OBT mart が、次の集計の材料にな り、上流の OBT mart の障害が下流まで伝播する OBT の採用自体が問題ではなく、ロジックの再利用層を設けないまま OBT mart への他 mart からの参照を許容したことが要因 15
16. 対策：component 層の導入 • • ディメンショナルモデリングを採用 ◦ 再利用可能な component 層を定義し、fact / dimension に分解 ファネル分析で需要のあったSalesforce関連のデータに適用 warehouse 層 component 層 mart 層 Lead dimension：リード Contact 複数環境の Lead／Contact を統合し GA4 の行動を接続 GA4 取引先 統合基盤 / 各プロダクト 店舗・事業者情報 dimension：アカウント（事業者） 獲得・商談分析の mart Salesforce 取引先と統合基盤・ プロダクトの店舗を統合 dimension（リード／アカウント）と fact（商談）を JOIN ✕ 商談 fact：共通の明細・イベント mart間の参照は禁止 商談・注文・プラン変更イベント など 16
17. 今後の展望 • 分析エージェントの性能向上/評価 ◦ データモデルの component 化の推進 ▪ 再利用可能な component から SQL を生成し、品質が高く自由度の高いクエリを発行 できるように • まずは参照の多いモデルから徐々に移行 ◦ データモデルのTier設計・ライフサイクルの適用 ▪ モデルの優先度を定義して、昇格/棚卸しを実施 ◦ エージェントの性能評価 ▪ 優先度の高いデータモデルを参照するほど高スコア 17
18. 今後の展望 • オープンデータの活用 ◦ プロダクト × オープンデータによる分析需要を探索中 ▪ 分析エージェントにより分析コストが下がっている ▪ データを入れて、分析させてみるという進め方ができる オープンデータ gBizINFO 経産省 法人活動情報（法人番号・基本情報） 分析エージェント e-Stat 政府統計の総合窓口 不動産情報ライブラリ 国交省 不動産価格・地価公示 気象庁 アメダス速報・過去の気象データ BigQuery OpenStreetMap 地物・立地情報 ⋮ 18
19. 今後の展望 • 可視化環境のアップデート ◦ Metabase → Lightdash への移行 ▪ BI as Code：指標の定義を dbt 側に集約し、ダッシュボードもコードで管理 ▪ 社内データツールとの役割整理 • 探索・定型モニタリング・アドホックの使い分けを明確化 • データ基盤の運用をよりシンプルに ◦ Argo Workflows/GKE を廃止し、サーバーレス構成へ ◦ 運用の自動化・プロアクティブ化 ▪ 品質・コストの自動計測 ▪ 障害一次調査のエージェント化 19