No.38 Data Casual Talk - データとエンジニアリングのよもやま話

先日、na0さんと、BIやデータマート、DWH等々について、カジュアルにお話する機会を頂きました。
その時に、良いお話ができたので、備忘も兼ねて、簡単に整理してみました。
(na0さんには、ブログに書くことを事前に了解頂いております。)

今回、まとめた内容は、あくまで、na0さんと私がお話した内容に基づくものであり、
それぞれが所属する組織の見解ではありませんので、その点は、ご了承頂けたらと思います。
また、先日、お話した内容を元に私の視点で追加整理している箇所も含まれていますので、
その点もご認識ください。

BI環境

f:id:yuu_kimy:20220205234759p:plain — データ基盤+BI環境全体像

いわゆるBI(ビジネスインテリジェンス)のことですが、上記の図では、敢えて、データ基盤とは分けて表してみました。
様々なデータが整理され、活用できる形で格納されているデータ基盤環境に対して、各ユーザが、それぞれの目的・用途に応じて、データ基盤へ接続する層を明確にしたかったので、データ基盤とBIを分けました。そういう意味では、よく言われるBI (Looker, Tableau,等々)よりも、もう少し広義な意味で、ツールという意味合いの方が近いかもしれません。

BIがしっかり活用されるには？活用を促すには・・・？

データへの欲求のスタンスは、「受動型」と「能動型」があるのでは？
- 受動型は、あくまで、漠然とデータを見たいと思っているタイプを指す。明確な目的があるわけではない。
- 能動型は、データで見たいものやそれを踏まえて、その後のアクションを想定しているタイプ。Burning Needsになっている状態。

この分け方は、個人的にとてもしっくりきています。

後者の能動型は、かなり稀なタイプと認識。(勿論、一定数は存在すると認識。)
能動型は、データの欲求が強く、データをよく利用するため、データ活用を浸透させていくには、一定数必要だと思っています。

一方で、データを見て、その後の動き次第では、受動型から能動型に切り替わるポイントがあるのでは？という仮説が会話の中では挙がりました。
(このあたりは、データの活用をサポートする人の伴走の仕方にも起因しそうと感じています。)

手に馴染む環境を提供する

特に、探索型のデータ活用において、開発運用側が、このツールをオススメといっても利用が進行しないことがある。
データを利用するユーザ側の方で、データ探索を自ら出来るようにするには、手に馴染む環境を提供することが大事
- ユーザが馴染む環境 + 新たなデータが、理想的な探索型の環境になるのではないか？

現状をモニタリングするというよりは、仮説の構築や深堀のための探索には、そのユーザ既知のデータに加えて、新たな分析軸を与えそうなデータの追加は大事。
それに加えて、そのユーザが、日頃から馴染んでいる(≒使い慣れている)ツールで、環境整備することも非常に大事。

個人的に、ユーザが「手に馴染む」という表現が、物凄く刺さっています！
勿論、スポット的な対応であれば、必ずしもそれが理想とは思わないですが、継続的な利用であれば、ツールの馴染み度合いは、重要な要素だな、と思います。
(運用観点で言えば、メンテナンスのコスト増の可能性もあるため、探索後のアクションや事業への貢献度合いも含めて、どこまでは対応するかのバランスも一方で必要だなと思っています。)

データマートやDWH

f:id:yuu_kimy:20220205234818p:plain — 各部門の「顧客」の定義

同じ社内でも、部門によっては、見たい単位が異なる場合があるので、それに合わせたデータマートを構築する必要がある。
自分が想定している「顧客」像が、別の部門では、粒度が異なっていた、そもそも、顧客の定義が違っていた、というのはよくあること。

汎化と特化

その組織における共通指標を構成したDWH層とそれぞれのユースケースに適したデータマート層の2つについては、界隈では既に浸透してきたように感じていますが、言い換えると、データの「汎化」と「特化」と言えるのではないかな、と思っています。
先日の会話の中では、下記の図にあるように、「蒸留」という言葉で表現していました。

f:id:yuu_kimy:20220205234841p:plain — データの汎化と特化

データマート層からDWH層を作成するには、データマートの特定項目の抽出を解除する形で汎用化を行う。
データマートという特定のユースケースに特化した状態から汎化するため、より全社的なビジネスドメインの知識を必要とする。

用途や運用的な観点では、全社的なレベルではなく、部門単位までの汎化となり、組織全体としての汎化にはならないケースも実際にあるでのは？
本気で取り組もうと思ったら、DDD(ドメイン駆動設計)とデータモデルを真面目にやる必要があるのでは？という問いも挙がっていました。

データマネジメント

組織で、データが正しく利用されるための仕組み作りは、やっぱり重要。

データの利用ログを見て、意図したように利用されているかのチェックする(誰や頻度といった観点も重要)
きちんとメンテナンスされているデータはどれなのかを定期的に発信していくことも大事
データを(組織に必要な形で)適切に運用することは大事。それに合わせて、ユーザの習熟度を上げていくも重要

データに、真にドメイン知識が反映された正しい状態であったとしても、事業の特殊性や制約等のために、ユーザ側から見て、難解過ぎると、結局は活用が進まない。理想の状態に持っていくにしても、データの難易度を下げる切り口をユーザへ提供することも大事では？という観点も挙がっていました。
(理想の姿の追求と利用推進におけるGAPは、なかなか悩ましいですが、利用時のバリア(障壁)を極小化、ユーザの習熟度向上も大事な取り組みだよな、と改めて思いました。)

最初の図で言うと、データ基盤・BI環境の整備、ユーザのデータ活用のサポート・伴走、情報発信etc..と、あらゆるところにデータマネジメントが関わってますが、時間の都合上、深く議論できなかったな、と感じています。
DMBOK ¹ には、11の領域で構成されていますが、各領域をもっと深堀していきたいところです。