/home/by-natures/dev*

ソフトウェア開発者としての技術的なメモと、たまに普通の日記。

2021/07/27 Data Governance: The Definitive Guide の輪読会に参加しました

Twitter でのお誘いをみて、データガバナンスに関する以下の書籍の輪読会に参加させていただきました:

このブログでも何度か取り上げていますが、ようやく今日全章を読み終えることができました。参加者の皆様、お疲れ様でした&ありがとうございました!

データガバナンスと銘打ってはいますが、データマネジメント領域のほぼ全てをカバーしています。DMBOK と照らし合わせると、データ統合・DWHとBI・データアーキテクチャなど技術的な側面が強い項目は言及が少なく、データ品質・メタデータ・セキュリティなどの運用的な側面が強い項目について多く紹介されていた印象です。

ツール・人・プロセスの3つが揃ってデータガバナンスが機能するという主張で、ツールはともかく人・プロセスも重要であるというのは面白い指摘です。鳴り物入りで導入されたツールが使われないといった話はよく聞きますが、そこにどんな役割があり、どんな業務プロセスがあるか(あるべきか)を合わせて考えないといけないということです。特にデータマネジメント領域は人手不足であることが多く、一人の人が多くの役割を重複して担っていることが多く、人に対しての業務プロセスや権限管理を考えると上手くいかない場合もあるので注意が必要です。

最後の第9章はカルチャーについての重要性が書かれていました。データマネジメントのカルチャーは自然発生することはなく、重要性を訴えて醸成していかないといけないといった趣旨です。例えばデータを整理する地味だけれど非常に重要な人たちに「データスチュワード」と名前をつけて効率的なデータ管理の方法を学んだり、サイロ化するデータウェアハウスを統合して見通しの良いデータアーキテクチャにしていく・・・どちらも自然発生することはないというか、エントロピー増加には逆行しているので、その点でも意思を持って文化を作っていかなければいけない。「文化」をわざわざチャプターにしてまで解説している本は見たことがないので、面白い章でした。

輪読内のコメントで、上手くいっている文化があるならなんでも上手くいくのでは、といった指摘がありました。上手くいっている時はどうして上手くいっているかは考えず、上手くいっていないときに原因を考えたり対策を施す・・・そしていきつく先は個人の能力不足や、トップの考え方が悪い、といった話はどんな場所でも耳にしたことがあります。本の中では後からデータガバナンスの体制を敷いて会社を成功に導く例が紹介されていましたが、その会社はトップダウンでデータガバナンスに関する戦略・哲学を打ち出し、ツールを用意し、人員をデータ関連業務にあてました。明示的にデータガバナンス戦略を打ち出すことが特に重要だと説明されています。

最近ではいろいろな書籍が出てきたり、データ関連職種の方とも学びの場が増えて助かっています。実践するのが一筋縄ではいかない・・・この本の話を借りるとトップダウンの重要性があるので自分だけでどうにかなる領域でもないのですが、同じ悩みをもつ方がいると知れるだけでも心強いなと感じます。

2021/06/04 ビジネス用語集とは何か

以前こんなツイートをしたら反応をいただきました。やはり「ビジネス用語集は大事」というのは色々な場所で説明されているようですが、具体的にどういうものなのか?と言われると私はまだよく分かりません。

組織内でデータマネジメントを改善していく立場なので、どういうものなのか理解するために調べてみました。

stack exchange で、ユビキタス言語がどのようなものかという質問がありました(ユビキタス言語はドメイン駆動開発の文脈での言葉ですが、ビジネス用語集と指すものは同じだと理解しています):

softwareengineering.stackexchange.com

回答をかいつまむと、以下のことが書いてありました

  • 通常のソフトウェア開発のように、要件をユーザからヒアリングし、それに適したシステムを構築すべき
  • GPA などのような頭字語(acronym)の意味を調べたり、類似語(synonym)を調べたり、ドメインの中にある用語を学ぶには wiki(Confluence, Mediawiki)などが向いている

ユーザからヒアリングを踏まえて wiki でいいとなると、すでに有志の方が「〜〜用語集」というのを作っていることは多いですよね。そことの違いを考えると、データマネジメントチームが責任をもって最新の状態に保つ運用体制が整えられるか、ということになるかと思います。銀の弾丸はないということですね。。

DMBOK には「ドキュメントとコンテンツ管理」という軸があって、これが簡単そうで侮れません。ドキュメントをきちんと管理していくには、ドキュメントをどう管理していくかというルールを作らなければなりません。例えば一階層目には新しくディレクトリを作らないとか、議事録はここに保存して承認後に必ずWIPを外すとか、まぁそういったことなのですが、これを作るためには相応のガバナンス体制が必要になってきます。鶏卵の話になってしまいますが、ドキュメントを見やすく発見しやすく管理していくためにはガバナンスがある程度必要になってくるかと思います。もしくは有志の方が自ずと整理されているかもしれませんが、その方がいなくなるとたちまちドキュメントは探しづらくなってしまうでしょう。

いろんなプロジェクトを見させていただくことが増えてきたのですが、どういった体制でデータ管理されているのかを聞く前にドキュメントの状態を見ると、おおよそのガバナンスレベルがうかがい知れるんですよね。ソフトウェア開発者ならコードの状態でガバナンスレベルをうかがい知れるかもしれません。どちらも局所的に使う分にはルールなど必要ありませんが、「組織全体で」となった途端に話が難しくなります。

ではデータガバナンスをよい状態にしていくためにはどうしたらよいのか。それは誰かが都合よくやってくれて、データマネジメントにうまく連携してくれるのか… それにはどうも、ビジネスプロセスの構築・理解がキーになるような気がしていて、最近はビジネスプロセスも勉強し始めました:

www.amazon.co.jp

うまく意見がまとめられたら、またブログに綴ろうと思います。

2021/04/23 ハーバードビジネスレビュー: 「データ管理は戦略である」を読んで

輪読会への参加 "Data Governance: The Definitive Guide"

本日からデータガバナンスに関する書籍の輪読に参加させています:

www.oreilly.com

社外の方とデータマネジメントについて議論できるのはとても貴重な機会でありがたいです。普段業務で悩んでいるようなことを皆さん話されていて、どの会社でも同じような問題を抱えているのだと知りました。

後からデータガバナンスを敷くのは難しいのではないか、といった話もありました。ただ現実的に最初からデータガバナンスがしっかりしている組織はとても珍しそうですし、じゃあどこから手をつけたら良いのか?というと、成熟度評価をしたりして地道に押し進めるしかないんでしょうね。。

昔は基盤刷新などでシステムが入れ替わるタイミングで体制を整える、といったことがあったそうですが、一度クラウド基盤を利用し始めると、滅多に BigQuery からどこかに移る、といったことはないでしょうし、データ削除も行われずにデータが蓄積されていく一方の「データスワンプ」が生まれやすくなっているのかもしれません。

2025年までに175ZBものデータが生まれるとの試算があります。Zettabyte Era(ゼタバイトの時代) なんて言葉もあるようです:

Zettabyte Era - Wikipedia

「人間よりシステムがデータのことを知っている時代」という記載もあって、そんな時代のデータをどうやって管理していくんでしょうか?うまくデータを扱いこなせないとビジネスが成り立たなくなる時代が来ているのかもしれません。

ハーバードビジネスレビュー「データ管理は戦略である」

こちらの論文を読みました:

www.amazon.co.jp

データマネジメントって地道で対費用効果が見えづらい活動なのですが、それが「戦略である」と書かれていてふと目についたんです。

短い論文であまり内容に触れるとネタバレになってしまうのですが、Single Source of Truth: SSoT に対し、Multiple Versions of Truth: MVoT という考え方を提唱していて、ある程度多様なデータの捉え方を許容するという考え方です。SSoT を重要視する組織は防御、MVoT を重要視する組織は攻撃のデータ活用ができると説明されています。

データガバナンスはデータ利用ユーザの統制を敷き、可能な限り同じマスタデータを参照してもらうのが綺麗な世界だと思っていましたが、最低限守らなければいけないデータ以外はある程度ユーザ側に委ねる世界があってもよいんだと学びを得ました。

2021/04/22 文字の発明とデータマネジメント

データマネジメントについて色々と勉強したり業務をしていく中で、『「データマネジメント」と名前は付いているけれど、とても普通のことをしているのでは』という感覚がでてきました。もちろん技術的な話はあるのですが、ガバナンスが大切だとか、用語集を統一しましょうとか、とても基本的な事項が多く含まれます。

それであれば何か歴史から学べることはないか?とぼんやり考えて、Twitter でもツイートしたりしたのですが(面白いリプをいくつかいただきました)、先日Podcastを聴いていて気づきがありました:

podcasts.apple.com

コテンラジオは同僚がお勧めしてくれてたまに聴いていたのですが、その第3回で「文字の発明」についての話があります。私は専門家でも何でもないので詳細はPodcastを聞いていただくとして、以下のような話題が話されていました:

  • 文字の発明によって、物事を記録することができるようになった
  • 文字によって思考の抽象化が進んだ
  • 紙の発明によって利便性が向上した
  • 凸版印刷の発明によって大量印刷ができ、多数の人が同じ情報を共有しやすくなった(マスメディア)

この一連の流れは 1:N の情報伝達手段であるマスメディアまで発展し、インターネットの登場によって成熟しきったと考えられるようです。そしてインターネットの利用が深まるにつれ、個人が発信する新しい時代(多対多、N:M)に突入していったというんですね。「文字」というテーマでここまで話が広がるのかと驚きます。

さらにこの情報伝達を効率化するために、古代都市は街の整備にとても力を入れていたそうです。中央集権国家では効率的に情報を集め、効率的に情報伝達(拡散)させることが大切なのでしょう。知識がないので想像しかできないのですが、飛脚のような役割の人や、馬などが通りやすいように道路を整備したりしたのかもしれません。日本だと五街道はよい例かもしれません。モールス信号のような遠隔で情報伝達できる手段についても触れられていて、私からするとアナログなインターネットのような雰囲気さえ感じます。

ここまで書けばデータマネジメントとの相似性がかなり見えてくるのではないでしょうか。紙の発明は石版・木版に比べればデータ書き込み速度の向上(もしくは保存容量の増加)に擬えられそうですし、凸版印刷はコピー速度の向上、街整備はネットワーク整備や組織構築に近そうです。どんなツールを使って、どんなガバナンス体制を敷くか。小さい街・国づくりのような気さえしてきます。ガバナンスが弱いと統制が効かない点も、まさに一国のような気がします。

かなり類似性がありそうだという気づきだけがあるだけでまだ深く考えられていないのですが、コテンラジオのおかげで「データマネジメント」を違った観点で見ることができそうですし、データガバナンスがデータマネジメントの肝、というのはやはり正しそうです。

にしても、歴史は面白いですね。「愚者は経験に学び、賢者は歴史に学ぶ」とはよく言いますが、私は歴史の授業は苦手でした。でもコテンラジオは歴史嫌いだったのに歴史マニアになってしまった人たちが放送しているようで、楽しく聞けると思います。よかったらどうぞ。

2021/03/12 データマネジメント成熟度のフレームワークに何を使えばよいか

データマネジメントについて色々考えている時期で、今日は成熟度について。

様々なフレームワーク

とあるプロジェクトでデータマネジメント成熟度を測ろう、となったのですが、成熟度を測るフレームワークにも色々あるようです。

www.cloudtimes.jp

こちらの記事で紹介されているのは以下の3つです:

  • CMMI研究所 が定めるもの(DMM)
  • Deloitte 社が提供するもの
  • Data Orchard 社が提供するもの

他にもウェブ検索していたら EWSolutions 社が提供するものも見つけましたが、大半はコンサルティング企業が有償提供するサービスが多いようです。

ちなみに Deloitte 社が提供するものは、アンケートに答えるだけで成熟度が測れるので面白そうです。ちょっと軸が独特な気がしますが。

Data Maturity Benchmark

DMBOK の書籍の中に紹介されているのは、

  • CMMI データマネジメント成熟度モデル(DMM)(これは上と重複)
  • EDM 協議会 DCAM
  • IBMデータガバナンス評議会成熟度モデル
  • スタンフォー ド・ データガバナンス成熟度モデル
  • ガートナーのエンタープライズ・インフォメーションマネジメント成熟度モデル

…というように非常に多くのフレームワークが存在します。

さらに「DAMA-DMBOKはDMMAの準備や基準を確立するために利用できる」ともあって、DMBOK 自体を成熟度を測る基準にできる、とも書いてあります(ただしその方法やチェックリストは書かれていません)。

CMMI研究所 DMM(DataManagement Maturity)

唯一 CMMI研究所が定めるものが、CMMI の前身がカーネギーメロン大学のソフトウェア工学研究所であったことからなのか、無償でチェックリストが公開されています。以下のリンクからCMMI研究所が定めるデータ成熟度モデルのチェックリストがダウンロードできます:

CMMI Institute - DMM Model At-A-Glance - Japanese Language (Digital Version)

f:id:bynatures:20210312015055p:plain
CMMI研究所の定めるDMMは5+1カテゴリ

DAMA DMBOK での成熟度チェックリストは公開されていない

私が会社の方と読み進めていたのは DAMA DMBOK(v2) だったので、できれば DMBOK ベースのものがないかなぁと探していました。データ総研の記事によると、CMMI DMM と DAMA DMBOK の関係が紹介されていて、DMM は6カテゴリに対して DMBOK は10カテゴリ(v1当初?)ですが、DMM でも DMBOK 10カテゴリの内容は網羅されているとのこと。

データマネジメントマチュリティモデルその2 | 株式会社データ総研

それでも今から CMMI DMM ベースで成熟度を測るのがやや抵抗と手間があるのと、DMBOK の書籍内でも11カテゴリに対してレーダーチャートで成熟度を描画している図があるなど、DMBOK の11カテゴリをベースに成熟度評価できるようにも見受けられます。DMBOK が教科書だとすると、それをどう計測するかは各々の状況に応じて・・・ということなのでしょうか。

それに CMMI DMM だと書籍が英語のものしかなく、技術的な学習であれば英語でもよいのですが、会社に広めようと思うと日本語書籍がある DMBOK でないと苦しい気もしています。

データ総研では DMBOK を読み込み、独自のチェックリストを作成して成熟度評価されているそうです。すごいですね。そういったサービスを利用したい気持ちもありつつ… ひとまず簡易的なDMBOKベースでの成熟度評価チェックリストを作ってみようと思っています。意外と公開事例が見つからなかったので、ちゃんと整備して運用できれば、社外公開などもいつかできるかも・・・いやどうだろう、分かりませんが。。DMBOK の復習にもなって、今のところは楽しめています。

謝辞

Twitter で情報いただきました もりたく様、ありがとうございます!

2021/03/05 データマネジメントは成熟度から進める

雑談:テレビについて

最近 NHK の ねほりんぱほりん がかなり気に入ってます。見ないようにしてきた世界(最近の放送だと戸籍がない人、闇金の取り立て人、DVをしていた人)のドキュメンタリーをあんなふんわりしたテイストで提供するなんて驚きです。。番組構成はシンプルなので民法でどうしてやらないんだろう?と思ったら、スポンサーの関係で難しいのかもしれません。ザ・ノンフィクションとかも嫌いじゃないんですが、ねほりんぱほりんの方が気軽に見れて好きです。民法だと不倫騒動など同じテーマばかり扱われているのも好きではないので、意外と攻めた番組を作っている NHK とか、ショッピング番組の QVC とか・・・テレビではないですが同じ理由で ABEMA を見る、というのも人によってはありそうですね。

元々実家ではバラエティばかり見ていた家族が嫌で、割と部屋に籠もっていたことが多くて、一人暮らしして何年かはテレビを持っていませんでした。高校〜大学の頃ですかね。学び続けないと、という強迫観念みたいなものがあって・・・今でもあるんですが、バラエティばかり見ている家族、というのが嫌でした。

ところが一人暮らしして何年かして、体に不調があって精神的にまいっていた時期があって、その時にふとテレビがほしいなと思ったんです。土日の昼過ぎ、ベッドで横になって何も考えられない時でしたかね。テレビ見たいな、と突然思ったんです。

それからテレビを買って、少し地上波を見た後は Amazon Prime Video でひたすらドラマと映画を見ました。実家では能動的にテレビを見なかったので映画は何も分からなくて、そういえば父親は寅さん見てたなとか、昔スターウォーズ勧められたけど見なかったな、という感じで有名どころばかりですが楽しかったです。英語字幕で見るとリスニングの勉強にも多少なっていたので罪悪感がなくてよかったですし、おかげでその後受けた TOEIC のリスニングは大幅に点数が伸びて驚きました。

データマネジメントは成熟度から考える

先日書いたデータマネジメントに関する記事ですが、

bynatures.hatenadiary.jp

「結局どうしたら良いのか、私もまだ分かっていません。」なんて締めくくってしまいましたが、DMBOK 読み直したり、データ総研さんの資料を頂いたりしてわかったのは、データマネジメント成熟度アセスメント(DMMA)を行い、幅広いデータマネジメント領域のどこにウィークポイントや理想との乖離があるかを明確にする、というのが最初のステップになるようです。

DMMA を進めるのもガバナンスが必要なのではないか、とも思ったのですが、

DMMAプロセスの監視はデータガバナンスチームの役割である。正式なデータガバナンスが存在しない場合、DMMAを開始した運営委員会か経営層が監視を受け持つ。

というように、ガバナンスがなくても気づいた人(?)から始めなさい、ということですね。

データマネジメントの成熟度を評価する必要があると判断した組織は、すでにその活動を改善するために取り組んでいると言える

とも書いてあります。DMBOK はどこまで行っても教科書でしかなくて、どう進めるか?についてはあまり触れられていないのですが、堅苦しい文章の中でこの一文は血が通っているように見えて励みになりました。

データ総研さんはいろんな資料を無料で公開していて、無料のウェビナーも定期的に開催しています。ウェビナーは一度参加しましたがとても分かりやすくて、自分が悩んでいる領域にはすでに先人が多く歩いてきたんだと分かりました。会社に頼んでセミナー受けさせてもらえないかな、と思っているのですが、はたして。

jp.drinet.co.jp

2021/02/19 データマネジメント改善の難しさ

最近、業務ではデータマネジメントの改善に取り組んでいます。

「データマネジメント」と一言にいっても、国際的な非営利団体 DAMA は DMBOK という、データマネジメント体系ガイドをまとめています。DMBOK が制定する領域では、以下の11の領域がデータマネジメントの対象とされています:

f:id:bynatures:20210219020747p:plain
DAMAホイール https://www.dama-japan.org/Introduction.html

「データセキュリティ」や「データ品質」など直感的なものもあれば、「データ統合と相互運用性」といった聞いただけではよく分からない領域、「ドキュメントとコンテンツ管理」といった、それもデータマネジメントなの?といったものも含まれています。そして円の中央に位置する「データガバナンス」が、周りの10の領域を統合することを上図では表しています。

DMBOK はいわゆる教科書的な書き方がされていて抽象的な部分が多いのですが、実企業の状態に合わせてどのようにデータマネジメントを推し進めたら良いか、が "Data Management at Scale" という O'reilly から出版された本で記載されています。

Amazon | Data Management at Scale: Best Practices for Enterprise Architecture | Strengholt, Piethein | Network Administration

小さい組織では問題にならない

"Data Management at Scale" ではデータガバナンスについて、スタートアップや小さい企業では必要にならないと書かれています。これは小さい組織ではデータを管理するのは数人のみで、データも種類も比較的少ないからです。さらにデータに関する質問があれば、周りの人に聞けばすぐに解決できる状態だ、とも書かれています。

大きな組織ではデータガバナンスが必要

組織が大きくなるとそれぞれのメンバーが注力する領域が分化され、知識も分散していきます。意思決定プロセスが複雑になるにつれ、データ所有者も不明瞭になっていきます。同時にデータ利用に対する重要性や緊急性もまし、GDPR, CCPA といったデータ利用規制も最近では登場しており、個々人の努力では管理がしきれません。そこでガバナンスを強く敷き、データが正しく"管理"(management) された状態にすべき、ということですね。

大きな組織に、後からガバナンスを敷くことは可能なのか

最初からデータマネジメントが重要だ!と思っている組織は少なくて、大抵は後からその重要性に気づくと思うのですが、DAMA ホイールと周りの10個の領域を見ると、データガバナンスありきで物事を考え、整備するのが綺麗に見えます。実際に DMBOK では、効果的なデータマネジメントにはリーダーシップとコミットメントが重要だとし、CDO(Chief Data Officer) を据えることを提案しています。

企業の実情に合うように、DAMA ホイールの11の領域に関係性を定義したのが、Peter Aiken のフレームワークです:

f:id:bynatures:20210219013625p:plain
Peter Aiken のフレームワーク https://blogs.sap.com/2020/07/09/why-hr-data-management-strategy-is-important-in-your-hr-transformation/

このフレームワークの面白いところは、 の順番に企業はデータマネジメントに取り組む、と考えている点です。最初にデータをため、モデリングし、セキュリティやワークフローエンジンを導入するなど、基本的な事項に取り組むと()、データアーキテクチャに歪みが生じ、データ品質の問題が生じ、メタデータが足らないことに気づき()、データガバナンスの重要性に気づく()・・・といった流れです。

ただこれもかなり理論的で、現実的にはのデータ分析やビッグデータまでデータ活用が進んでから、土台部分の様々な領域に問題が生じる・・・ということが多いのではないでしょうか。スピードが求められるサービス開発では、データを利用した様々なアプリケーションがサービスイン直後から求められるかと思います。

しかしシステムが巨大化するにつれてデータ品質に問題が生じてデータへの信頼性が損なわれ、データアーキテクチャはその場その場で拡張された場当たり的な使いづらいアーキテクチャになり、利用者はそれぞれが使いたいデータを自由に使う、統制が取れない状態となります。

ピラミッドの各要素が下位レイヤーに依存していて、問題が生じているなら土台から固めるべきでしょう。上記フレームワークで言えば、結局データガバナンスを固めよ、ということになります。ではデータガバナンスとは何かといえば、データ自体やデータ利用方法に統制を敷くことなので、かなりのトップダウンが求められます。

結局どこから手をつけたら良いのか

DMBOK では CDO の役職を置き、長期スパンでのデータマネジメント改善へのロードマップを策定すべきと書かれていますが、実際はこのトップダウンアプローチを敷くのが難しいように思えます。データの問題に気づくのは現場のメンバーで、それを問題として管理者へ伝えていかなければなりません。

現場レベルで改善していくアプローチも取れるかもしれませんが、データマネジメントは想像以上にステークホルダが多いです。データを生成するシステム部門、それを使うユーザ部門が全て関係してきます。すでに業務が回っている状態だと、業務改善と称して既存の業務フローを変更してもらわなければなりません。

面白い考え方があって、業務改善が起こるには以下の式を満たさなければならないというのです:

C = D x V x F > R
D: 不満
V: Vision
F: ステップ
R: 抵抗

現状への不満と、改革へのビジョンへの共感、そこに到るまでのステップが明確化されていることの3つが、現状維持の抵抗を上回ったときに初めて改革が起きる、というのです。システム刷新などでも使えそうな考え方です。

データだと現場レベルでの考え方だと「とりあえず使えているし」ということで、「D: 不満」があまり起きていないような感覚があります。そのビジョンには共感するし今のデータにも多少不満はあるが、別に現状でもそんなに困っていない・・・といった感じですかね。これを草の根的に様々なステークホルダを対象にヒアリングし、改善してくのは大変な労力です。

結局どうしたら良いのか、私もまだ分かっていません。データマネジメントの知識が増えるにつれ、結局データガバナンスの欠如に戻ってきてしまうような感覚があります。それでもロードマップを敷き、やれることから少しずつ改善していくしかないのでしょうが、まだまだ経験不足だと感じます。

このあたり、一緒に議論していける方がいれば、気軽にお声がけください。まだまだ知識不足・経験不足なので、学んで理解を深めていきたいです。