こんにちは、データ基盤グループの吉田(id:syou6162)です。データ基盤やデータマネジメントに興味を持たれている方はDMBOKを持っている / 読んだことがあるという方も多いのではないでしょうか。このエントリではDMBOK中に紹介されているデータマネジメント成熟度アセスメント(以下、アセスメントと省略)をモノタロウでどう活用しているかについて紹介します。
背景
まず、モノタロウでなぜアセスメントを行なったかについて説明します。モノタロウは20年以上歴史のある企業であり、データ基盤自体も10年以上の歴史があります。単一事業ではあるものの、受注 / 売上 / 商品 / 在庫 / 顧客 / 行動履歴など、対象となるドメインも多数ありました。
また、データマネジメントはデータアーキテクチャ / データモデリングとデザイン / メタデータなど多岐にわたる項目があり、どれも大事な項目です。しかし、これらの項目に対しアセスメント実施前はデータ基盤メンバー間で認識にギャップがあり、目線が揃ってない状況でした。具体的には
- 執筆者の私(吉田)は入社間も無い時期であり、モノタロウの既存のシステムへの理解がまだまだ浅かったこと
- メンバーのバックグラウンドがエンジニア / コンサル / データサイエンスなどバラバラであったこと
などが原因としてありました。モノタロウのデータ基盤は人数がそれほど多いわけではないですが(アセスメント実施時は3名。2022年7月現在、5名)、データ活用が進んでいるがゆえにデータ基盤グループへの社内の様々な部署からも依頼が多く、工数が限られている中、データマネジメントのどの項目から取り組むべきかは自明ではありませんでした。その結果、グループ内外から納得を得られるデータ基盤のロードマップを提示するのも簡単ではない状況でした。
どうやってこういった課題を打破するか考えていた際、DMBOK内で説明されていたアセスメントのことを思い出しました。DMBOKはデータマネジメント界隈で有名な本であり、特にこの本の内で紹介されている「データマネジメント成熟度アセスメント」を使うと、客観的な視点からデータマネジメントの項目の優先順位付けなどの課題を解決できるのはないかと思い、アセスメントを実施することにしました。
初手: 自社のデータ基盤の歴史を振り返る
アセスメントを実施する前に、まずメンバー間のモノタロウの既存システムへの理解ギャップを減らす目的でモノタロウのデータ基盤の歴史の振り返りを行ないました。過去からどういったことができるようになってきたのか、データ活用が発展するに従って現在はどういった課題が起きているか、将来的にはどういったデータ基盤にしていきたいのかをグループ内で議論しました。モノタロウのデータ基盤の歴史については以下のエントリをご参照ください。
アセスメントの実施
歴史を振り返り、グループのビジョンも整ってきたので、DMBOKをベースにデータ基盤グループ内でアセスメントを実施しました。代表的な項目は以下のようになりました。
- データストレージとオペレーション:
- アクセス権限の付与など、データの扱いに関わるセキュリティポリシーの運用が適切にされている
- データ活用の加速に伴ないストレージ料金が増加しているものの、どのプロジェクトで特に増加しているかは把握できており、長期間使われていないテーブルの定期的な削除など、コスト増のリスクを一定コントロールできている
- メタデータ:
- 基幹DBからBigQueryに同期されているテーブルについてはDB定義書が存在し、テーブルやカラムの定義が分かる
- 一方、テーブルオーナーやセキュリティに関するメタデータの整備はまだ網羅的ではなく、統一的にできる体制を今後整備していきたいが、1500を越えるテーブルに一度に付与していくのは現実的ではないため、優先順位を考える必要がある
- データ品質:
- ニアリアルタイムなデータ同期による高い適時性、丁寧なオペレーションによるデータの整合性や正確性についてはある程度高い品質が担保されている
- データ活用者と品質に関する合意が明示的に取れているわけではなく、定量的かつ継続的な計測はできていない。また、テーブルによっては一意性になっているべきカラムが一意になっていなかったり、そのテーブルを使った前処理が属人化しており、同じ指標でも部門によって違った値が出るなどの課題が発生している
- データモデリングとデザイン:
- 有志によるDWH相当のテーブルは存在するが、公式のDWHは存在しなかった。部門毎にデータマートが存在する場合もあるが、その正確性は属人的になっていることが多い
- モデリングに対する明確なプロセスが存在せず、設計者やレビュアーがある種空気を読みながらやっている状態であり、カラム名に一貫性がなかったり、必要なカラムが存在していない場合も多かった
データ活用者 / システム提供者 / 意思決定者へのヒアリングの実施
データ基盤グループ内でのアセスメントは完了したものの、データ基盤提供側の視点に偏っているという課題感がありました。そこで、データ活用者(商品部門やSCM部門の分析官) / 基幹システム提供者(IT部門のエンジニア) / 意思決定者(各部門の部門長)へのヒアリングをそれぞれ実施することにしました。データエンジニアリングを専門にする人以外にとって、アセスメントの項目は理解が難しいため、対象の方に分かりやすい言葉に直しながらヒアリングしました。
また、データ基盤グループが元々把握したかったDMBOKベースの事項が聞けたかも確認したかったため、ヒアリングの質問とリサーチの質問(ヒアリング対象の方に直接に語りかける言葉ではなく、ゴールを明らかにするための質問)をそれぞれ立てて、ヒアリングに挑みました。データ基盤グループのメンバー自身はユーザーヒアリングの知見は特に持っていなかったですが、UI/UXのグループで実施しているユーザーヒアリングのドキュメントが社内で公開されており、それを参考にヒアリングを実施しました。活用者の観点での希望度合いやシステム側の制約など、データ基盤メンバー以外の視点が加わることでより現実的かつ効果的なものにできました。
アセスメントを実施した結果
DMBOKによるアセスメントやヒアリングの結果をどう活用しているかについて説明します。各項目をレーダーチャート形式まとめて理想との差分が大きいところから取り組む形式も考えられましたが、データ基盤グループでは項目を依存関係として表現することにしました。以下がその理由です。
- 項目間の依存関係を考慮する必要がある / 考慮したほうが効果的に進めることができる
- ヒアリングの結果、システム側の制約やその解決の時期を大まかに知ることができた
- DMBOKの項目XがシステムYに依存していて、システムYの課題が解決しないとそもそもXに取りかかれない、といったことを表現するのは依存関係として表現するのが適している
- Root causeに近い項目から進めると、他の項目も効果的に進めることができる
- グループ外のメンバーに対してもタスクのやる/今はまだやらないが説明しやすい
- 今データ基盤グループがやっていることが、データ活用者の依頼にどう関わっているか、なぜ優先的に取り組んでいるかが説明しやすい
- 11個もの項目がそもそもフラットに並んでいると、データ基盤グループ内ですら認知負荷が大きい
各項目の依存関係を可視化したものが下の図になります*1。
現在はDWHを中心とした「データモデリングとデザイン」と「データウェアハウジングとビジネスインテリジェンス」から取り組んでいます。その理由としては「アセスメントの実施」の中でも説明しましたが
- モノタロウのデータ基盤内には1500種類以上のテーブルがあり、それらに対して画一的にメタデータの付与やデータ品質の向上をしていくのはかなり工数がかかり、進め方も自明ではない
- まずDWHを構築し、その限られた成果物に対してメタデータの付与やデータ品質の向上などデータマネジメントのプラクティスの適用していく
- 分析用のインターフェイスとしてDWHを磨き込む
- その中で得られた知見やプラックティスをDWH以外のテーブルについても展開していきたい
といった背景があります。DWHの展開後は、全社共通の指標 / 部門固有の指標などを考慮したDWH / Looker(LookML)の「データアーキテクチャ」再考、分散管理体制に向けたPoCの取り組みといった「データガバナンス」なども意識しながら進めている最中です。
DWHを社内に単純に提供するだけではなく、DWH提供を通じてデータ活用者にどういった価値提供をし、組織体系を含めてどういったことを将来的にやっていくといいかを考えながら動けるのがDMBOKを用いたアセスメントのメリットだなと感じています。また、議論の副産物として、チームのビジョンの形成やチームビルディングにも繋がりました。これについては過去の発表をご参照ください。
最後に
モノタロウではアセスメントなどを通じて、社内によりよいデータ基盤を提供するデータ管理の課題に興味がある人を募集しています。こうした取り組みに興味がある方はぜひカジュアル面談や採用へのご応募をお待ちしています。
*1:実施直後の図であり、現在はまた少し変化しています
