中央集権から自律分散型のデータ管理へ〜モノタロウにおけるアナリティクスエンジニアリング〜

アナリティクスエンジニアリンググループのマネージャーをしている吉本です。
モノタロウでは昨年7月よりアナリティクスエンジニアリンググループを立ち上げ、データ管理をより高度にするための取り組みを始めております。
今回はモノタロウにおいてアナリティクスエンジニアリンググループができた背景と取り組みについて紹介いたします。
またこの記事を読んでモノタロウのアナリティクスエンジニアリングに興味がある!詳しい話を聞きたいと思ったかたは2/13にイベントを開催いたしますのでぜひご参加ください! monotaro.connpass.com

データ活用と管理の歴史

モノタロウでは10年以上前よりBigQueryを中心としたデータ基盤を構築し、全社員に向けてデータを活用できるようツールの提供やサポート、研修などを積極的に実施し、アナリストはもちろん業務担当者自身がSQLを書きデータを駆使して業務を進めたり意思決定を行うようになりました。

tech-blog.monotaro.com

このようにデータ活用がどんどん進む一方で、「担当者ごとにロジックがバラバラで指標に対して数値が合わない」「分析要件はわかるけどデータが多すぎてどこに必要なデータがあるかわからない」などのようにデータを統制、管理する必要が出てきました。 そのため、Lookerを導入し全社員が見る指標について定義を揃え可視化できる環境を整備したり全社向けのDWHを構築することによって全社にまたぐ重要指標を管理できる状態になってきました。

tech-blog.monotaro.com

各業務におけるデータ管理の課題

上記の取り組みによって社内における重要指標が管理、統制できるようになったことで一見落着かと思いきや次の問題が発生しました。

各業務の指標の管理先がない

DWHについては継続的に必要な指標を募集し、最初はどの部署でも使いそうな指標が多かったのですが、徐々に個別の業務におけるKPIや指標についてDWHへの追加依頼が来るようになりました。

その背景として各業務内において、

  • 業務で指標として使いたいけどメンテナンスができる環境がない
  • 要求を満たす仕様をどうロジックとして表現したらいいかわからない

という状況にありました。

データ管理を進めるうえで業務とデータ仕様の理解が必要

その当時はDWHの利用者を増やす目的もあり基本的に依頼があった指標についても追加していく判断をしましたが、中央集権で管理しようとすると

  • 要件を把握しないといけないため業務の知識が必要になる
  • テーブルの仕様も理解し適切にロジックを作成しないといけない
  • 実装後要件の変更があるたびに都度コミュニケーションが発生する

という状況が発生します。

モノタロウの事業特性としてECサイトだけではなく、商品採用、マーケティング、サプライチェーン、営業などなど業務が多岐に渡っているため膨大な業務知識とテーブルの理解が求められます。

www.slideshare.net

そのため今後のメンテナンスや全体の業務を深く理解する必要性があることを踏まえると中央集権的に管理するにも一定のコストが発生することが懸念としてありました。

ドメイン内におけるデータ品質の維持管理が難しい

もちろん各業務でデータを作成ならびにメンテナンスしているところもあるのですが

  • ロジックの仕様やメンテナンスが属人化し、異動や退職などに伴い指標のロジックを把握できる人がいなくなる
  • 意図せずシステム側のデータの入り方の変更が発生することでデータの不整合が起きる

という事例も時折あり業務に支障が出るケースもありました。

上記のことからモノタロウではこれまでのような中央集権的なデータ管理だけでは不十分であると考えるようになりました。

データメッシュとアナリティクスエンジニアリング

そんな中昨今のデータ活用、管理のトピックとしてデータメッシュやアナリティクスエンジニアリングの存在を目にするようになりました。

データメッシュとはThoughtworksのZhamak Dehghaniさんが提唱した考え方で 中央集権的にデータを管理するのではなくドメイン毎にデータ管理の責務を持ってデータプロダクトを提供し、中央部分はプラットフォームを提供、全体の管理をする考え方です

How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh

非中央集権型データマネジメント データメッシュとは | NTTデータ | DATA INSIGHT | NTTデータ - NTT DATA

アナリティクスエンジニアリングはソフトウェアエンジニアリングのベストプラクティスをアナリティクスのコードベースに適用し、信頼性のあるデータモデルを提供することでエンドユーザーが自律的にデータ活用できる状態を目指す取り組みを指します。

What is Analytics Engineering?

Analytics Engineering | The GitLab Handbook

モノタロウが目指す自律的なデータの分散管理

これまでの課題ならびに昨今のトピックを踏まえモノタロウでは各業務において自律的にデータ管理ができる状態を目指そうと考えています。

具体的には各ドメインにアナリティクスエンジニアを配置し、ドメイン内において

  • テーブルやダッシュボードなど資産の管理
  • データモデリングの実施、その結果としてデータプロダクトの構築、公開
  • データマート構築や一定の品質を保ちながらデータ集計、分析を手軽に行えるためのプラットフォームの構築ならびに教育の実施

を行いたいと考えております。

上記の取り組みを実施するため2024年7月にアナリティクスエンジニアリンググループを立ち上げ営業ならびにSCMのドメインにおいてアナリティクスエンジニアを配置しドメイン内でデータ管理の取り組みを行っている最中です。 またモノタロウにおいては上記だけでなく商品採用やマーケティングなどドメインも幅広いため、取り組みによって得られた知見を集め他ドメインにも横展開していきたいと考えています。

最後に

このようにモノタロウではデータ活用を文化とし、より精度の高い意思決定が実現できるための管理面の仕組みや体制を築いていきたいと考えています。 上記の取り組みに興味を持ち、一緒にデータ活用を推進していただける仲間を募集しています!

アナリティクスエンジニア | 株式会社MonotaRO

ソフトウェアエンジニア (データ基盤) | 株式会社MonotaRO

データマネジメントエンジニア | 株式会社MonotaRO

改めてですがこの記事を読んでもう少し具体的に話を聞きたい、質問したいかたがいらっしゃったら2/13にイベントを開催しますのでぜひご参加ください!

monotaro.connpass.com