Vポイント分析基盤におけるデータモデリング20年史

2026/07/22 Data Engineering Study #36

Transcript

1. Vポイント分析基盤におけるデータモデリング20年史
2. 事業紹介
3. 自己紹介：松井 太郎 ／ Vポイントマーケティング テクノロジー戦略本部 本部長 2000年：営業職で入社し、Business ObjectsでBIとデータを触る 2002年：IT部門に異動し、セマンティック層の整備と展開 2006年：基幹系担当になり、データ項目辞書整備と標準化 2011年：TポイントIT組織に異動 ※この前後ぐらいからのモデリングの歴史をお話します 2013年：Tポイント分析基盤の担当 2020年：Snowflakeと出会う 2024年：コミュニティへ参加 ・Snowflake DataSuperheroes 2025-2026 ・Databricks JEDAI ORDER 2026 Padawan
4. 「“良いデータモデル”は、どこから生まれるのか」 「何を解くか」の見極めから生まれる
5. 2000年代、データに関する手法や技術も知らずに コミュニティの存在を知らない データマネジメントも知らない クラウドもまだなかった 勉強会文化はWeb系が中心 DMBOK の邦訳は 2011年 オンプレが中心 社内SEには縁遠かった世界 体系的な知識に Redshiftが2013年 触れる機会が少ない時代 限られたリソースによる制約 自分たちで何とかするしかない！ どうやって解くか、自問自答しながら体当たりでやっていた時代
6. 事業の変化に合わせ、データモデルの見直しと改善を実施してきた 2003 2011 2015 2017-2019 共通ポイントサービス 提携先データモデルの標準化 商用分析サービスの基盤刷新 販売管理を業務ごと再構築 Tポイント誕生 2008-2010 2013 2016-2017 2021-2025 ポイント基盤の刷新 商用分析サービスの構築 分析基盤 AzureSynapse移行 分析基盤の統合 それぞれのフェーズでどんなことをやってきたのか？
7. 各社各様のデータモデル 2003年：国内初の共通ポイントサービス開始 DVDレンタル履歴 出版 媒体 伝票履歴 店舗マスタ 購買履歴 商品マスタ ポイント履歴 統合商品マスタ ｼﾘｰｽﾞ BOOK購入履歴 作品 商品マスタ 企業A ・1業種1社で各業界大手と提携して開始 ｱｰﾃｨｽﾄ 購買履歴 ..etc 企業B 会員マスタ 伝票履歴 店舗マスタ 購買履歴 商品マスタ 企業C セル商品履歴 伝票履歴 店舗マスタ 購買履歴 商品マスタ TSUTAYA店舗マスタ 企業D 伝票履歴 伝票履歴 店舗マスタ 急ピッチで実現した共通ポイント（ TSUTAYAのTポイントへ切替が間に合わないぐらい） スピード重視で、最低限の共通ポイント化のための機能実装 数年後、事業が急速に拡大する中で、インフラ・アプリ・データモデルを含めた再構築を判断
8. 2008-2010年：共通ポイントの再構築 ・事業成長のために性能向上、ビジネスモデルに合わせたデータモデルへの刷新 API性能の向上：数万QPSの性能要件の達成 多様な企業業態に合わせたポイントデータモデル トランザクションの処理方式の見直し 分析基盤へのデータ連携 待機系／バックアップ環境の強化 データモデルに合わせたAPI刷新 業務フローの見直しと必要機能の整備 監査基準に沿った記録要件 ポイント基盤は全面的に刷新したが、提携先のデータモデリングは変わらず個社対応
9. 2011年：各社各様のデータモデルをどう吸収するか ・下流で個社仕様を吸収し続けると、組織も分析業務も破綻する→問いの見直し 1 毎回ゼロから積上げ 2 どこでせき止めるか 3 問いを設定し直す 新規契約のたびに、 下流で吸収する方式しかないのか 標準仕様を定め、契約時の合意形成 ゼロから発生する仕様確認 それ以外の方法があるのでは？ これができれば、モデリングの負担 は大幅に減るのでは？ 仕様と違う実データ 各社各様ではなく、自分たちが仕様を握る そのために、提携先に自分たちの分析要件に合わせたデータ仕様に合意してもらう
10. 2011年：標準化による個社ごとのデータモデル設計からの脱却 Before：とにかく、なんでも、貰っておく After：分析に必要なデータ群を明確化 POSデータやマスタの外部連携は高額 アナリストとの対話で、必要項目や仕様を明文化 先方仕様のまま受領するのが当たり前 それを標準仕様として、新規企業から適用 ・項目不十分、マスタ不整合 ・JANや商品コードの正規化 ・売上の算出や税計算の不一致 ・税抜きや値引の計算仕様を統一 ・不完全なリレーションや個別項目の乱立 ・ER図の整理、必須とオプションを区別し、仕様を統一 ・データエンジニアリングの疲弊と分析の難易度上昇 ・提携先と仕様充足を合意し、業務平準化 自分たちの数十倍・数百倍規模の大企業に 自社の分析価値・提供価値を データモデリングを合わせてもらう 説明できないと協力してもらえない ポイント導入に伴うPOS改修やデータ連携は、先方のIT部門にとっては厄介な取り組み 事業やデータの価値を、自分の言葉で語れるように、セールスエンジニア的な役割も担う
11. 2013年：提携先増に伴い、商用分析サービス構築の提供を開始 ・取引時点の商品コードやマスタ名称での表示など整合性と再現性を管理するための世代管理 分類マスタ 分類マスタ履歴 商品マスタ 商品マスタ履歴 時点商品マスタマート 商用 商品マスタマート 購買明細トラン 購買明細トラン履歴 時点購買明細マート 商用 購買明細マート 店舗マスタ 店舗マスタ履歴 分析サービス 当時はオンプレだったため、性能と実装コストのバランスを重視し、最低限の履歴管理 サービスの急成長（ウン十倍）により、Exadataがパンクし、2015年にVerticaへリプレイス
12. 2017年～：オンプレの限界からのクラウド移行とデータマートの整備 ・Oracle Exadataの保守期限に合わせ、アナリスト向けのデータ基盤をAzure Synapseへ移行 ・容量不足で見送っていたデータマート作成が可能となり、BI導入＋マート化が一気に進む ・エンジニア管轄とアナリスト自由領域を分けて、作成責任や問い合わせ先も責任分担して運用 データエンジニア 5名 データアナリスト 40名→現在70名 上流ソース／提携先／外部 正規化データ Azure Data Factory 元データ→正規化データ レガシー処理 ブロンズ/シルバー Dataiku BIやレポート用データ 役割分担はできているが、良くない実装が見つかることも 自律的に業務を行うためのガードレールや実装ガイドラインは継続的に必要 ゴールド
13. 2017-2019年：販売管理システムのフルリプレイス ・事業成長とともにサブシステム、ツールが乱立し、営業が複数ツールに何重も登録 ・最新の業務フローの可視化と入力業務の精査を行い、あるべき業務を新システムにより具現化 Before After サブシステム 既存システム サブシステム 外部ASP ツール EXCEL 営業が複数ツールに何重も登録し、業務負荷に 40近い媒体の半分以上が既存システム外で運用 Single Source of Truthも不確かな状態 6システム/ツール → 1つに統合 ⇒ 40以上の媒体を一元管理 Tポイント媒体商品の各販売フローを全社で整理 業務フロー・機能・帳票を可視化し、 汎用的に運用できるようにデータモデル中心に刷新 例えるなら、（ちょっと偉そうだけど）Salesforce を自社開発するようなレベル エンジニアが、業務設計に踏み込んでいく中で自社業務を深く理解 業務の柔軟性や拡張性を考慮し、データモデルを中心に設計（DOA的アプローチ）※開発は外部委託
14. 2021-2025年：分散していたデータ基盤をSnowflakeへ統合 ・ハードウェアの保守期限やリザーブド契約の更新タイミングに合わせた綱渡りのPJ 商用分析サービス 2021年5月 Vertica アナリスト用 2024年1月 Azure Synapse 基幹処理・外部連携 2025年1月 Oracle Exadata Snowflake SSoTの実現 アーキテクチャの統合 エンジニアスキルの集約 内製シフト 全体で1万を超えるテーブル群の統廃合を実施して、Snowflake内で用途別DB/スキーマに再配置 テーブル同名の中身違いやプライマリテーブルの見直し、不要テーブルの削除、 浮動小数点や文字型の仕様違い、関数レベルなど、PoCで検証しながら段階的に移行
15. 事業の変化に合わせて、データモデルの標準化・最適化を上流から実施 2003 2011 2015 2017-2019 共通ポイントサービス 提携先データモデルの標準化 商用分析サービスの基盤刷新 販売管理を業務ごと再構築 Tポイント誕生 標準IFをもとに仕様を合意 ExadataからVertica移行 業務フローを最新化し、 毎年数十社増に対応可能に 分析特化のDBの強さを知る データモデルを中心に設計 2008-2010 2013 2016-2017 2021-2025 ポイント基盤の刷新 商用分析サービスの構築 分析基盤のクラウド移行 分析基盤の統合（SSoT） 共通ポイント化に合わせた 時点再現のための世代管理 容量解放→データマート実現 Vertica/Synapse/Exadata アナリストと責任分担 SnowflakeにDB統合 データモデルを基盤ごと刷新 今の言葉で言えば、2011 データコントラクト、2013 SCD Type2、2017 メダリオン、2019 DOA 的アプローチ データモデリング・データマネジメントの手法や技術を知っていれば、もっと自信を持って実現できたかも
16. と言いながら・・Google Analytics あなたは苦手です ・スキーマも指標定義も、一方的に決まり、一方的に変わる相手（仕様が握れない） 下流吸収の実際 上流シフトの弊害 イベントストリームのセッション化、識別子の統合 握れない上流があると右往左往しがち 業務モデリングとは異なる設計原理 みんなどうやってるの？を学んでます 自前では立ち上がらず、外部の支援で構築 他にも、先方仕様でもらわざるを得ないデータ群（レガシーなシステムやSalesforceとか） イチからデータモデリングを学べる喜びを味わえる（僕だけ？）
17. 式年遷宮的なデータモデルや業務の棚卸をより速く ・ポイント基盤刷新 / 販売管理再構築 / 分析基盤統合も、いわば式年遷宮（伊勢神宮の20年ごとに社殿造り替え） 「式年遷宮」型：まとめて大規模改修 ズレを溜め込み、数年に一度まとめて最適化 人材の育成､業務仕様の言語化(表出化)､アーキテクチャ改善 ⇄ 「アジャイル」型：タイムリーな改修 ズレを都度顕在化させ、素早く解消 表出化された知識やルールに対する継続的な改善 2つのサイクルはどちらも必要な補完的関係。加速する事業スピードに対して、より最適化し続けるには？ 知識やルールの言語化と、その継続的なメンテをどのように実現していくべきか
18. 式年遷宮的なデータモデルや業務の棚卸をより速く ・ポイント基盤刷新 / 販売管理再構築 / 分析基盤統合も、いわば式年遷宮（伊勢神宮の20年ごとに社殿造り替え） 「式年遷宮」型：まとめて大規模改修 ズレを溜め込み、数年に一度まとめて最適化 人材の育成､業務仕様の言語化(表出化)､アーキテクチャ改善 ⇄ 「アジャイル」型：タイムリーな改修 ズレを都度顕在化させ、素早く解消 表出化された知識やルールに対する継続的な改善 2つのサイクルはどちらも必要な補完的関係。加速する事業スピードに対して、より最適化し続けるには？ 知識やルールの言語化と、その継続的なメンテをどのように実現していくべきか 組織変更や営業手法の変更 入力情報や入力エラーの傾向 毎日の全件出力の把握 入力形骸化や意味の変化からの兆し 業務手順自体の変化の兆し システム外業務の兆し AIエージェントが適切に動くために、業務や基幹システムを明確化、最新化していく必要がある ログやメトリクスで検知は可能だが、その業務の変化・ズレの意味の判断は人にしかできない 事業が走り続ける中で、この人材育成と継続的改善の仕組み化をどうやっていくべきか？
19. 我々のデータモデリングは良かったのか？ 分析基盤の中では、我々のデータモデリングのレベルは高くないかもしれません 我々は『どこでモデリングするか』を選び続けた 事業や業務の変化に合わせ、最適化をし続けた結果、上流のデータモデルそのものに投資してきました 解くべき課題を上流で解決していくことで、分析基盤は、その再現に注力してきた 結果的に年間数十社の企業追加を捌き、アナリストの分析環境を維持、拡大してこられたと考えています 事業の変化に向き合い、最適な場所を選んで、データモデリングをし続けてきた
20. "良いデータモデル"は、どこから生まれるのか 事業の変化に向き合い、最適な場所を選んで、データモデリングをする時に生まれる 我々の場合、その場所は「上流=基幹システムやプロダクト」だった ただ、事業が変わればモデルの良さは失われる → 検証され続けているモデルだけが良いモデルであり続ける 事業変化のスピードが上がる中で、数年がかりの見直しだけでは、良いモデルを維持できなくなる 良いデータモデルを「どこ」で生むのかに加え、「いつ」見直すべきかへ変わってきている
21. 自分たちのやってきたことは、ガラパゴスかもしれない それでも、いまはコミュニティがある 正しいと言えること、そうではないかもしれないこと、これからどうすればいいか 一つ一つ、答え合わせができることに感謝 自分もコミュニティに貢献したい！と思って、2024年から参加 僭越ながら個人として2つの称号に選出、企業として栄誉ある賞をいただくことができました Snowflake Data Superheroes 2025-2026 JDMC データマネジメント賞 2025 データ基盤賞 Databricks JEDAI ORDER 2026 Padawan
22. 私の話が、一つでも皆さんのお役に立てると幸いです！
23. ご清聴ありがとうございました！