Data Engineering Summit 事業成長を支えるためのデータ アーキテクチャの取り組み © 2024 MonotaRO Co., Ltd. 

2/23 自己紹介 斎藤貴文 株式会社MonotaRO プラットフォームエンジニアリング部門 データ基盤G　マネージャー 前職ではWebメディアにおけるデータ基盤構築・運用を担当。 2022年にMonotaROに入社。データマネジメントのチームを経て 今のデータ基盤のシステム開発の部署でマネージャーとアーキテクトを担当。 

モノタロウについて © 2024 MonotaRO Co., Ltd. 

4/23 モノタロウが目指す世界 資材調達ネットワークを 変革する モノタロウは、データとテクノロジーの力によって 間接資材の調達プロセスに変革をもたらし、 『すぐ見つかる』、『すぐ届く』を実現する BtoBプラットフォームを運営しています。 当社の提供するサービスによって、 お客様が購買に費やす手間を軽減し、時間資源を創出することで 日本の産業社会全体の生産性向上と発展に貢献します。 

5/23 モノタロウが提供するサービス 資材調達ネットワークの 変革を目指して 生まれたフルスタックEC 挑戦を続けて変革を起こすために「自前主義」を掲げ、物流セン ターや在庫を自社で保有しているほか、 コールセンター、マーケティング、ITなど多くの業務とシステムを 内製開発、自社運用しながらECサイトを運営しています。 

6/23 事業成長の推移 登録口座数の順調な増加と LTVの向上により、 16年連続の増収を達成 

モノタロウのデータ環境 © 2024 MonotaRO Co., Ltd. 

8/23 モノタロウの事業成長サイクル 

9/23 事業成長サイクルとデータ環境への要求の関係 顧客を求める商品を迅速に提案 →データが重要 成長サイクルを回すにつれ、データへの要求が増していく 顧客に定着してもらう施策を打つ →データが重要 SCMの高度化 → データが重要 マーチャンダイジングの高度化 → データが重要 

10/23 モノタロウのデータ活用の歴史は古い ● 2010年のDWH導入からデータの基盤の歴史は始まった ○ その前からデータ分析は行われていた ● 新システムの開発・導入をしながら、自分たちでデータ基盤を整備 ● 詳しくは下記のブログに記述してあります ○ MonotaROのデータ基盤10年史（前編） ○ MonotaROのデータ基盤10年史（後編） ○ （この記事も2021年なので4年前のものですが） 2010 2016　　2017　　　　　　 2020　　 2021 　 DWH導入 　BQに移行　　 リアルタイムパイプライン開発　 　　 Looker導入　　dbt導入 | | | 　　 | | 

11/23 モノタロウのデータ基盤の概要 11 Data Warehouse ECサイト 業務 オペレーション ECサイト Sheets 基幹システム 11 カスタマー 社員 DWH（BigQuery）を中心に構成 リアルタイムパイプラインシステムと集計データ用APIは内製で開発 基幹システムのデータをCDCをリアルタイムで同期 検索・推薦などサービス利用のための集計データを提供 

12/23 モノタロウではデータを自分たちで参照する文化が根付いている ● アナリストやエンジニアだけではなく、配送センターで働く人や商品採 用を計画する人なども自分でBigQueryからデータを参照している ○ ダッシュボードやスプレッドシート経由の実行だけでなく、 自分でクエリを書いてデータ抽出するパターンも多い ● 一ヶ月の間にプロパーの80%以上は最低一回はBigQueryでジョブを実行 

13/23 なぜ、社員が自らデータを見る文化になったのか ● データに基づく経営判断を早期から行っていた ● 2016年にデータ分析ができる人材を各部門に分散して異動することで データ分析の文化を全社に展開 マーケティング部門 A部門 B部門 C部門 分析依頼 データ マーケティング部門 A部門 B部門 C部門 新メンバーの入社 分析スキルをもつメ ンバーの他部門への 展開 

14/23 事業成長にともに生まれたデータへの課題 ● データに対する要求の複雑化 ○ 事業規模が大きくなるに従って、業務ドメインも変化 ○ 部署間でのコンテクストの違いが大きくなる ● データを提供する側が分析のフローに参加できていない ○ 業務データを自動的にDWHに展開する環境を用意（※秘匿情報は除外） ○ データ提供側（業務部門）が能動的に参加する余地がない ○ 業務側のコンテクストが伝わらず、データだけがDWHに置いてある状態 ● → 事業が成長にするにつれ、部署間の分断が顕在化 ○ 会社規模が小さい時は、コンテクストが異なっても伝わる余地があった 

15/23 システムにも課題が ● 内製システムの老朽化 ○ 長年、様々な部署の要求を叶えるために大きな泥団子化しつつあった ○ メイン開発者の退職により、プロダクトの方向性が見失われる ○ データ・利用者の規模が大きくなるにつれ、変更が難しくなる ● → データとシステムの課題を解決するためにデータメッシュを導入 

16/23 データメッシュとは ● 分散型のデータアーキテクチャ ○ Data Mesh Principles and Logical Architecture ● 特徴（細かい定義はいろいろありますが） ○ 事業ドメインが自組織のデータの公開を管理できるようにする ○ ドメインは単にデータを共有するだけではなく、 使えるような状態になったデータプロダクトとして公開する ○ 安全にデータのやり取りをできる環境の用意 ■ ドメインがデータパイプラインを独自に組み上げられる インフラストラクチャの提供 ■ ドメイン間のデータのやり取りを規定するデータガバナンスの提供 ● ドメイン、データプロダクト、インフラストラクチャ、データガバナンスの ４つの要素が重要 

17/23 データメッシュとは インフラストラクチャ データガバナンス ドメインA データプロダクト ドメインB ドメイン間では データプロダクトを介して やり取りする データプロダクトはインフラストラクチャを利用して作成 データの扱いについてのポリシーはデータガバナンスで管理 

18/23 データメッシュを選んだ理由 ● 「自由にデータを活用できる環境」を超えて 「自律的にデータを活用できる環境」にレベルアップする必要があった ● 自律的な環境を目指す「型」としてデータメッシュが適切だと判断した ○ 相互的に円滑なデータのやり取りができるようになる ○ 組織・データが分散しても統制が効かせられる ● また、一般的な概念ということにも利点があると考えた ○ 「データメッシュ」で検索すればいろんな人の説明が見つかる ○ 生成AIなども答えてくれる 

19/23 課題のデータメッシュによる解決 ● 「データに対する要求の複雑化」 → データプロダクトによって、データの正しい使い方を規定 ● 「データを提供する側が分析のフローに参加できていない」 → 提供側がデータプロダクトを用意できるインフラストラクチャを用意 → データガバナンスによって、全体への統制を仕組みとして効かせられる ● 「内製システムの老朽化」 → データメッシュを一つの型として、データ基盤の再構築を検討 ● 課題も解決できそうなので、データメッシュのために動き始める 

20/23 モノタロウのデータメッシュの取り組み ● データ開発部門の編成変更 ● 2024年からアナリティクスエンジニアリング（AE）グループを新設し、 データ基盤グループの２グループ体制 メンバーが各部門に常駐 現場のデータに関する課題を解決しながら業務知識を身につける ソフトウェアエンジニアリングを組み合わせてデータの課題を解決 既存のデータ基盤システムのモダナイズ 秘匿情報のポリシーや権限管理手法を用意 AI・ML・リアルタイム処理など、データに対する新たな要求の実現 アナリティクス エンジニアリング （AE） データ基盤 （DENG） 

データ基盤の担当 アナリティクス エンジニアリングの担当 データ基盤の担当 21/23 モノタロウのデータメッシュの取り組み ● 部署毎に担当領域を明確化 ● AEはドメインの責務の明確化とドメインにおけるデータプロダクトの構築を担当 ● データ基盤はデータガバナンスとインフラストラクチャの整備を担当 ● こうして、モノタロウのデータメッシュは順調に実現されたのであった...... インフラストラクチャ データガバナンス ドメインA ドメインB データプロダクト 

データメッシュの輝かしい実績 残念！現実はそう甘くない！ データメッシュに悪戦苦闘な日々！ © 2024 MonotaRO Co., Ltd. 

23/23 「データメッシュとは何？」 ● まずはデータ関連の業務を行っている部署に データメッシュをやっていきたいという説明を行った ● その結果、よく分からないという反応が多かった ○ 「データが商品（プロダクト）ってどういうこと？」 ○ 「データメッシュはドメイン毎に自分たちで管理しないといけない？」 ○ 「インフラストラクチャって今と何が変わるの？」 ● また「データメッシュの実現＝我々の目的」だと認知され始めた ○ データメッシュはあくまで自律可能な環境を実現するための手段の型でしかない ○ 手段と目的が入れ替わって成功することはほとんどない ● ま、まずい......🥺 

24/23 データメッシュがなぜ理解されなかったのか ● データメッシュとはソフトウェア工学に基づいた抽象的な考え方 ○ 「責務ごとに高凝縮と疎結合を実現することで自律的な開発を可能にする」 ○ DDD、サービスメッシュ、マイクロサービスなど類似の概念が多い ● ソフトウェアエンジニアであっても理解が難しい ● そしてモノタロウの場合、エンジニア以外の人もデータ環境の構築に参加する ○ 業務部門には必ずしもエンジニアが所属しているわけではない ● つまり、専門でない人も巻き込んで理解が難しい概念の実現を目指している ○ 全員がデータメッシュを理解をする必要はないが、 全員が無理解のままでは到底進めることができない 

25/23 まずは身近なところから始める ● まず、我々のチームがデータメッシュを理解しないと話にならない ○ 実際、メンバーごとに思い描いているデータメッシュが異なる ● 輪読会を通して地道に学習 ○ データメッシュについて、書物を通して議論 ○ 背景となるソフトウェア工学についても学ぶ ○ ある程度、データメッシュに関する認識が揃う ● 今のデータ基盤にデータメッシュを当てはめてみる ○ データメッシュのために新しいものを作らなければならないことはない ○ 既存のデータ基盤とデータメッシュの差分から何をやるべきかを考える ○ データメッシュという型を通して、本当に目指すものも見えてくる 

26/23 データ基盤をデータメッシュに当てはめてリデザインした例 ● リアルタイムパイプラインシステム ○ 基幹システムのOLTP（MySQL）をCDCでDWH（BigQuery）に同期するシステム ● このシステムのデータメッシュでの役割は何か ○ 機能要件と非機能要件で整理 ● →「データプロダクトを提供するためのインフラストラクチャ」 ○ その前提で必要な機能が実現できるように再設計 ○ Zero ETLやLakebaseなど、最近の概念との類似点・違いも整理 DWH CDC 基幹システム CDC 基幹システム DWH 同一のテーブルに対しても 利用者向けのデータプロダクトの機能と インフラストラクチャとしての機能を分離 OLTPと同じ状態のテーブルをDWHに再現 

27/23 データメッシュを広めていく ● チームでの共通理解ができたら、次は外に広めていく ● まずできるところからデータメッシュと比べて手を加えていく ○ インフラストラクチャとしてのシステムを再設計 ○ セキュリティの部門と一緒にデータガバナンスを整備 ○ データプロダクトのサンプルとして、DWHテーブルを用意 ● それからは説明、説明、アンド説明の繰り返し ○ アナリティクスエンジニアリングのメンバーも常駐先で データに関わるタスクをこなし、信頼を得ている ● そして、まだまだ道半ば...... 

28/23 まとめ ● モノタロウはデータメッシュを推進してます ○ まず近いところから少しずつ推進しています ● 見ての通り、まだまだやれていないことばかりです ● 活躍できる余地はたくさんあるので、興味がある方の募集をお待ちしています ソフトウェアエンジニア （データ基盤） アナリティクスエンジニア 

© 2024 MonotaRO Co., Ltd.