【事例】NE株式会社
当社監訳書籍『アジャイルデータモデリング - 組織にデータ分析を広めるためのテーブル設計ガイド』の寄稿事例をWEB掲載しています。
- 本書における寄稿事例の位置づけについては寄稿事例について を参照してください。
- 本ページに掲載している画像および図表については、いずれも同書籍からの引用となります。
NE株式会社
寄稿者：マーケティング統括部 熱田亮
NE株式会社は、複数ネットショップを管理するSaaS型EC Attractions「ネクストエンジン」を運営し、5,600社以上（2023年1月時点）のEC事業者を支援しております。年間1兆円を超える流通データを扱っており、2021年に13.2兆円であった国内物販のEC市場 *1と比して相当の割合を占めており、ECモール横断のデータとして他に類を見ないものとなっています。
風音屋では2年以上にわたって、NEのデータ基盤構築を支援してきました。ディメンションやファクトのテーブルを作る前後でデータをどのように持つのか。どのようなテクノロジーを用いてデータモデリングを実現するのか。実践的な事例やノウハウをご紹介できればと考えております。
*1 経済産業省「令和３年度 電子商取引に関する市場調査 報告書」より
NEのデータ基盤の全体像は図1のようになっています。本稿ではこれらのテーブル構成や技術スタックについてご紹介します。
図1 NEにおけるデータ基盤のシステム構成
弊社のデータ基盤ではGoogle CloudのBigQueryを採用しており、保守性や拡張性、変更容易性等を担保するため「Data Lake（DL）」「Data Warehouse（DW）」「Data Mart（DM）」の3つのレイヤーに分けて構築しています。この3層構造は『実践的データ基盤への処方箋』や『データマネジメントが30分でわかる本』といった書籍を参考にしました。
Google Cloudでは「プロジェクト」と呼ばれる単位でコストを管理できるため、3つの層に対応させる形で3つのプロジェクトに分けました。DW層では大規模なデータ集計が行われることが多いため、DW層のプロジェクトに予算枠を多く割り当てる、といったコスト最適化を行っています。
図2 DL層へのデータ連携
Data Lake（DL）層は図2のようになっています。社内の業務データベースをEmbulkで、社外の広告データをAirbyteで取り込み、加工せずに元データのコピーをそのままBigQueryに保存しています。EmbulkやAirbyteはデータの取り込み処理を簡単に実現できるOSSです。Googleが提供するサービスについては、BigQueryの機能でデータ取得を完結しています。
BigQueryには複数のテーブルをまとめた「データセット」と呼ばれる箱があります。DL層のデータセットは、データソース（データの取得元）と1対1の関係になるように構築しました。どのシステムから流れてきたデータなのかがすぐに判断できるようになるため、長期的にチームの管理コストが下がるだろうと考えました。
DL層に蓄積されたデータは、データ加工ツールであるdbtを利用してデータクレンジング（手直し・前処理）を行い、DW層へと流し込んでいます。「加工後のデータを蓄積するだけで十分だ」とDL層を作らないでおくと、クレンジングの処理内容に問題があった場合やビジネス状況の変化によって加工処理を変更する場合に、各システムから再度データを取得することになります。ちょっとした修正のために、わざわざ10年以上の取引データを再取得するのは合理的とは言えません。そのため、DL層とDW層を分けて構築しています。
図3 DW層でのデータ加工
Data Warehouse（DW）層は図3のようになっています。データを加工するための中間レイヤーです。なるべく管理しやすく、変更に耐え、柔軟かつ安全にデータ利用ができるように工夫しました。各データセットの役割について説明します。
「cleansing」データセットには、クレンジング済みのデータが格納されています。クレンジングでは、重複データを削除する、文字列型になっているデータを適切な型に変換する、タイムゾーンをUTC（協定世界時）からJST（日本標準時）へ変換する、機密情報をマスキングするなど、データ利用者がデータを扱いやすいように加工しています。
「snapshot」データセットにはログや履歴を格納し、日次や月次でスナップショットを取得しています。顧客の契約ステータスを管理しているシートでは、ステータスが日々更新されてしまい、最新状態しか分からないといったケースがあります。スナップショットを毎日取得・格納することで、過去の推移を確認できるようになります。特定の時期に契約ステータスが滞りやすいといった特徴が分かったり、「契約ステータスが1か月前から変化していないので架電して状況を確認しよう」といったアクションに繋がります。本稿執筆時点ではシンプルな定期保存にしていますが、dbtにはSCDタイプ2でスナップショットを自動保存できる機能があるため、切り替えを検討しています。
「fact」データセットには、ビジネスイベントごとのファクトテーブルを構築しています。ユーザーのクリック単位でレコードを追加するなど、ビジネス上の最小粒度でデータを管理することで、今後の変更に耐える設計にしています。月次集計されたものをファクトテーブルとしてしまうと、後から日次で見たいと思ったときに戻すことができなくなるためです。cleansingやsnapshot内にディメンションに相当するテーブルがあるため、それらのデータと結合することで柔軟なデータ探索が可能となります。
図4 DM層でのデータ提供
Data Mart（DM）層は図4のようになっています。データ利用者が直接アクセスできるレイヤーで、「データの利便性」と「データの安全性」を両立することが重要です。利用者ごとにデータの置き場を分け、権限管理を徹底しています。テーブル更新時には影響範囲やアナウンス先を限定できるため、利用者の要件に応じて柔軟に設計を見直せるようになります。
社内利用者には「role_xxx」データセットを提供しています。営業向けにはrole_salesデータセット、カスタマーサクセス向けにはrole_csデータセットがあります。role_engineerデータセットにはシステム監視用のテーブルを配置するといった用途も考えられます。
社外利用者には「public_xxx」データセットを提供しています。グループ企業（Hamee株式会社）や研究機関（東京大学）に対し、Google Cloudが提供するAnalytics Hub経由でデータを連携しています。東京大学へのデータ提供時には、店舗名や商品名をマスキングし、代わりに機械学習・生成AIによる商品カテゴリ分類の推定結果を付与しています。
他システムには「service_xxx」データセットを提供しています。Chatシステムにはservice_chat、商品システムにはservice_productなど、連携先を容易に判別できる名前を付けます。
上記とは別に「workshop」データセットを用意しています。他社ではsandboxと名付けることもあるようです。利用者が自由にテーブルやビューを作成できる環境で、唯一dbtによるコード管理の対象外となります。SQLを勉強したり、単発のリスト抽出を行うときに使います。
DM層では、DW層のファクトテーブルとディメンションテーブルを結合し、必要な列をすべて備えた横長のテーブル（大福帳：ワイドテーブル）を作っています。利用者はデータ結合に手間を割かずに済みます。SQLを書けなくても、GoogleスプレッドシートからBigQueryにアクセスして、1つのテーブルからデータを抽出すれば、後はシート上でフィルタリングや集計をすることが可能です。BIツール（Looker Studio）からアクセスするときにも、加工処理が不要で、すぐにデータを可視化できます。
図5 複数の設計パターンを比較検討した例（モザイク加工済）
ご紹介した内容はあくまで弊社の事例です。プロダクトや企業によっては必ずしもこのデータ構成が合うとは限りません。現在のデータセット構成を決めるにあたって、風音屋さんにサポートをいただいて複数の設計パターンを比較検討し、関係者で話し合いながら設計を進めていきました（図5）。
安易な思い込みで自社に合わないデータモデリングを進めてしまうと、いざ組織にデータ活用を普及させようとしても、都度変化する要求の対応に追われ、本質的な活動をする余裕がなくなってしまっただろうなと思います。データ基盤構築をアジャイルに進めるには「専門的な知見」「関係者との対話」「自社に合う設計を考える姿勢」が重要ではないでしょうか。