最近、業務ではデータマネジメントの改善に取り組んでいます。
「データマネジメント」と一言にいっても、国際的な非営利団体 DAMA は DMBOK という、データマネジメント体系ガイドをまとめています。DMBOK が制定する領域では、以下の11の領域がデータマネジメントの対象とされています：
「データセキュリティ」や「データ品質」など直感的なものもあれば、「データ統合と相互運用性」といった聞いただけではよく分からない領域、「ドキュメントとコンテンツ管理」といった、それもデータマネジメントなの？といったものも含まれています。そして円の中央に位置する「データガバナンス」が、周りの10の領域を統合することを上図では表しています。
DMBOK はいわゆる教科書的な書き方がされていて抽象的な部分が多いのですが、実企業の状態に合わせてどのようにデータマネジメントを推し進めたら良いか、が "Data Management at Scale" という O'reilly から出版された本で記載されています。
小さい組織では問題にならない
"Data Management at Scale" ではデータガバナンスについて、スタートアップや小さい企業では必要にならないと書かれています。これは小さい組織ではデータを管理するのは数人のみで、データも種類も比較的少ないからです。さらにデータに関する質問があれば、周りの人に聞けばすぐに解決できる状態だ、とも書かれています。
大きな組織ではデータガバナンスが必要
組織が大きくなるとそれぞれのメンバーが注力する領域が分化され、知識も分散していきます。意思決定プロセスが複雑になるにつれ、データ所有者も不明瞭になっていきます。同時にデータ利用に対する重要性や緊急性もまし、GDPR, CCPA といったデータ利用規制も最近では登場しており、個々人の努力では管理がしきれません。そこでガバナンスを強く敷き、データが正しく"管理"(management) された状態にすべき、ということですね。
大きな組織に、後からガバナンスを敷くことは可能なのか
最初からデータマネジメントが重要だ！と思っている組織は少なくて、大抵は後からその重要性に気づくと思うのですが、DAMA ホイールと周りの10個の領域を見ると、データガバナンスありきで物事を考え、整備するのが綺麗に見えます。実際に DMBOK では、効果的なデータマネジメントにはリーダーシップとコミットメントが重要だとし、CDO(Chief Data Officer) を据えることを提案しています。
企業の実情に合うように、DAMA ホイールの11の領域に関係性を定義したのが、Peter Aiken のフレームワークです：
このフレームワークの面白いところは、青→黄→緑→赤 の順番に企業はデータマネジメントに取り組む、と考えている点です。最初にデータをため、モデリングし、セキュリティやワークフローエンジンを導入するなど、基本的な事項に取り組むと（青）、データアーキテクチャに歪みが生じ、データ品質の問題が生じ、メタデータが足らないことに気づき（黄）、データガバナンスの重要性に気づく（緑）・・・といった流れです。
ただこれもかなり理論的で、現実的には赤のデータ分析やビッグデータまでデータ活用が進んでから、土台部分の様々な領域に問題が生じる・・・ということが多いのではないでしょうか。スピードが求められるサービス開発では、データを利用した様々なアプリケーションがサービスイン直後から求められるかと思います。
しかしシステムが巨大化するにつれてデータ品質に問題が生じてデータへの信頼性が損なわれ、データアーキテクチャはその場その場で拡張された場当たり的な使いづらいアーキテクチャになり、利用者はそれぞれが使いたいデータを自由に使う、統制が取れない状態となります。
ピラミッドの各要素が下位レイヤーに依存していて、問題が生じているなら土台から固めるべきでしょう。上記フレームワークで言えば、結局データガバナンスを固めよ、ということになります。ではデータガバナンスとは何かといえば、データ自体やデータ利用方法に統制を敷くことなので、かなりのトップダウンが求められます。
結局どこから手をつけたら良いのか
DMBOK では CDO の役職を置き、長期スパンでのデータマネジメント改善へのロードマップを策定すべきと書かれていますが、実際はこのトップダウンアプローチを敷くのが難しいように思えます。データの問題に気づくのは現場のメンバーで、それを問題として管理者へ伝えていかなければなりません。
現場レベルで改善していくアプローチも取れるかもしれませんが、データマネジメントは想像以上にステークホルダが多いです。データを生成するシステム部門、それを使うユーザ部門が全て関係してきます。すでに業務が回っている状態だと、業務改善と称して既存の業務フローを変更してもらわなければなりません。
面白い考え方があって、業務改善が起こるには以下の式を満たさなければならないというのです：
C = D x V x F > R D: 不満 V: Vision F: ステップ R: 抵抗
現状への不満と、改革へのビジョンへの共感、そこに到るまでのステップが明確化されていることの3つが、現状維持の抵抗を上回ったときに初めて改革が起きる、というのです。システム刷新などでも使えそうな考え方です。
データだと現場レベルでの考え方だと「とりあえず使えているし」ということで、「D: 不満」があまり起きていないような感覚があります。そのビジョンには共感するし今のデータにも多少不満はあるが、別に現状でもそんなに困っていない・・・といった感じですかね。これを草の根的に様々なステークホルダを対象にヒアリングし、改善してくのは大変な労力です。
結局どうしたら良いのか、私もまだ分かっていません。データマネジメントの知識が増えるにつれ、結局データガバナンスの欠如に戻ってきてしまうような感覚があります。それでもロードマップを敷き、やれることから少しずつ改善していくしかないのでしょうが、まだまだ経験不足だと感じます。
このあたり、一緒に議論していける方がいれば、気軽にお声がけください。まだまだ知識不足・経験不足なので、学んで理解を深めていきたいです。
