/home/by-natures/dev*

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

レイクハウスアーキテクチャについて

最近よく Snowflake, Databricks 社のサービスを目にするようになり、私の所属している会社でも(部署は違いますが)Snowflake の導入を行っているようです。その中で "Data Lakehouse" という単語を目にしたので、どういう概念なのかを調べました。

実際に動かしたりしていないので半分自分のための備忘録として書いているのですが、明らかに誤った説明があればご指摘ください。

Databricks 社からの論文

このレイクハウスという考え方は GCP, AWS などのクラウドベンダーでも紹介されていて、徐々に広まりつつある考え方のように見えます。Google Cloud の data lakehouse の解説記事に、Databricks の方が筆頭著者の論文が紹介されていました:

http://cidrdb.org/cidr2021/papers/cidr2021_paper17.pdf

この論文は CIDR 2021 にて発表されており、発表動画もありました:

www.youtube.com

要約を引用します:

This paper argues that the data warehouse architecture as we know it today will wither in the coming years and be replaced by a new architectural pattern, the Lakehouse, which will (i) be based on open direct-access data formats, such as Apache Parquet, (ii) have firstclass support for machine learning and data science, and (iii) offer state-of-the-art performance.

Lakehouses can help address several major challenges with data warehouses, including data staleness, reliability, total cost of ownership, data lock-in, and limited use-case support. We discuss how the industry is already moving toward Lakehouses and how this shift may affect work in data management.

We also report results from a Lakehouse system using Parquet that is competitive with popular cloud data warehouses on TPC-DS.

データウェアハウスは新しいアーキテクチャパターン、レイクハウスに置き換えられるだろうという強い主張があります。既存のデータウェアハウスには以下のような問題があると主張しています:

  • データレイク・データウェアハウス間でデータ品質を保つことが難しい(微妙な差異が生まれたり、ETL処理においてバグなどが生じる可能性がある)
  • データウェアハウスに届くまでに時間がかかる(データが古くなる)
  • データウェアハウスは機械学習へのサポートを提供していない。データ抽出にはさらなる ETL ステップが必要となる
  • データレイク・データウェアハウスの両方にストレージコストが生じる

この問題を解決するために、データレイク自体にデータマネジメントの機能を持たせたり、機械学習・データサイエンスのサポートをしたり、データレイク自体にSQLを発行できるようにするというのが論文の趣旨です。下図は論文からもってきたものですが、(b) がデータレイク、データウェアハウスが分離された分かりやすいアーキテクチャですが、(c)(論文が主張する新しいアーキテクチャ) ではデータレイクが主役となっています。

f:id:bynatures:20220121202003p:plain
旧来の2tierアーキテクチャに対するレイクハウスモデルの紹介(論文より)

疑問: Snowflake との違いは?

Snowflake も最近よく目にするようになり、どちらも似たような機能をもっているように見えたので、比較記事を読みました:

www.firebolt.io

この2社のサービスは徐々に近づいてきているということですが、Snowflake はデータウェアハウス、Databricks は ETL 処理基盤として登場したとのこと。大きな違いは2つあり、1つ目は保存・処理できるデータ種別。Databricks の Delta Lake は非構造データ・半構造化データ・構造化データを扱えますが、Snowflake は構造化・半構造化データを対象にしているとのこと。しかし非構造化データについてもサポートを拡張し始めているようです。

2つ目はクエリパフォーマンス。これは当然といえば当然ですが、構造化・非構造化データを対象としている Snowflake, BigQuery, Redshift(そして Firebolt)に軍配が上がります。しかし論文にも書かれているように Databricks の Delta Engine には様々な工夫が凝らされており、Delta Lake に対するパフォーマンスを向上させています。

記事中にもありますが、どちらが良いかはケースバイケースですし、Snowflake, Databricks どちらも使っているパターンも多いとのこと。データウェアハウスを中心にクエリパフォーマンスを重要視するなら Snowflake, データレイクを中心に機械学習・データサイエンスのサポートをしたいなら Databricks…といった感じなんでしょうか。

疑問: データモデリングはどこに行ったのか?

このブログで以前データモデリングの話をしました。昨今はデータモデリングが必要な文脈が変わってきて、データモデルをもとにきちんと整備されたデータをデータウェアハウスに格納するのではなく、データレイクに格納したデータの関係性を理解するためにデータモデリングが必要になってきているのではないか、ということでした。

bynatures.hatenadiary.jp

レイクハウスでも Metadata レイヤーが存在する通り、データマネジメントの機能は需要だと考えており、データ品質やデータガバナンスをこのレイヤーで担保することが論文では書かれていますが、データモデリングについては述べられていません。運用上の課題に近いので論文中で議論される必要はないのですが、データレイクに存在するデータを扱いやすくしたようなレイクハウスアーキテクチャにおいて、データ同士の関係性がどのように表現されるのかは気になります。

2021/12/08 データモデリングの文脈変化

DMBOK で一番読むのを楽しみにしていたのがデータモデルの章だったのですが、いざ読んでみると細かすぎるというか、求めていたものと違う感覚がありました。私がドメイン駆動設計から生成されるモデルの実用性に興味をもっていた時期なので、実践的な内容を求めているだけかもしれませんが…。DMBOK ではデータモデリング・スキームが多数紹介されていたり、データモデリング戦略を立ててモデリングしていきましょう・・・といった内容が書かれており、現職で起きている問題を解決するのには役立たなそうだと感じました。

そんな中で見つけたこのデータ総研さんの記事で合点がいきました:

(EDW報告その2)データモデリングの逆襲 | 株式会社データ総研

データ構造を固めなくてもデータを格納して貯めていけるNoSQLは、Webを中心としたシンプルなビジネスで数多く採用されています。テキストも画像も音声も動画も、なんでも構造を意識せずNoSQLデータベースに格納し、必要なものを必要な時に見つける運用が広まりました。その結果、ER図を中心としたデータモデリングへの関心も下がっていました。

これまでは・・・

上の記事では NoSQL によって構造を気にせずデータを格納できるようになり、データモデリングの需要が減ってきたと書かれています。しかしデータ量が増えてデータ活用のニーズが増えてくると、データ同士の関係性を可視化したデータモデルへの需要が再び高まってきます。以下の一文でも完結に表されています:

20年前は「データの構造設計→格納→活用」の流れで必要だったデータモデリングが、現在では「データの格納→構造の発見→活用」という流れの中で必要とされているのです。

データモデリングが必要な文脈が変わってきた、というんですね。DMBOK はもちろんどちらでも使える内容ですが、やや前者・・・事前にデータ構造を設計してから格納することを前提にしているように見えるので、後者の課題をもつ現職だとどこから手をつけて良いか分からないのだと理解しました。ビッグデータアーキテクチャ では ETL(抽出、変換、ロード)ではなく ELT(抽出、ロードしてから変換)が主流な点からも、まずとにかくデータを格納するようになったという文脈の変化は理解できます。「データレイク」という言葉も文脈の変化を表しているかもしれません。

これは個人的な意見ですが、パブリッククラウドの登場によって多くのユーザが自由にテーブルを作成できる環境になり、データモデリングを今までのように行うことが難しいのではないのでしょうか。その中で dbt や Dataform(Googleにより買収)はデータリネージや変換処理を分かりやすく管理できるツールとして最近脚光を浴びています。こういったツールで実データに紐づく物理・論理レイヤのデータモデルを作成できれば、あとは中央集権的にデータモデラーが概念モデルとしてまとめ上げる流れがあればよさそうです。

dbt も Dataform もまだ利用経験がなく、憶測で書いているところもあるのですが、この辺りの違和感がある方や、DMBOK の解釈が間違っている、などなんでも良いのでご指摘いただけたら嬉しいです。

2021/12/03 DMBOKを横断組織で活用した話 #datatech-jp #AdventCalendar2021 #day3

datatech-jp Advent Calendar 2021 3日目への投稿です。

今年は datatech-jp のコミュニティの方達と話をしたり、輪読会に参加させていただくことができました。datatech-jp 自体の説明は1日目の投稿からご覧いただけます。Slack チャネルもあり、気軽にいろんなことが相談できたり、輪読会を開いたりと徐々に活発になってきていますので、ぜひご覧ください:

www.yasuhisay.info

私からは、技術的横断組織にいる私が ここ2年くらいの DMBOK を中心とした社内の活動で得た知見を共有できる範囲でお話します。

所属組織について

私はサイバーエージェント社の Media Data Tech Studio という横断組織にいます。秋葉原ラボという組織は聞いたことがある方もいるかもしれませんが、2021年秋から組織名が変更されています。以下公式HPから説明を引用します:

www.cyberagent.co.jp

Media Data Tech Studioは大規模データ処理やデータ分析、機械学習などを専門とするエンジニアが在籍する研究開発組織です。サイバーエージェントのメディアサービスから得られるデータを活用することで、メディアサービスと会社の発展に寄与することを目的として2011年4月、秋葉原にオフィスを開設しました。 サービスから日々生成されるユーザーのアクセスログや行動ログなどを大規模に集積、処理する基盤を整備し、その基盤上のデータを機械学習や自然言語処理技術などを用いてサービスに活かせるシステムを構築、提供しています。 また、基盤上のデータを分析、マイニングすることによりサービスやユーザーの状況を把握し、サービス拡大および健全化を図る基礎を担っています。

特定のサービス(例えばアメーバブログ、ABEMA(AbemaTV)、タップル、WINTICKETなどサービスがあります)の発展を支援することももちろんですが、あくまでも「横断組織」としてデータ活用をどう支援できるかを日々模索している組織です。

注力する事業を合理的に判断したい

DMBOK 輪読による共通言語の獲得

様々なサービス事業を有する中、どの事業のどのプロジェクトにフォーカスすべきかの戦略を立てるため、データマネジメントの観点で事業状況を可視化できないかと検討をしました。そのためにまず ゆずたそさんの30分本を読んで概要を理解し、その後 DMBOK の書籍をチーム内で輪読を始めました。

www.amazon.co.jp

www.amazon.co.jp

もう少し正確に言うと CMMI 基準のデータマネジメント評価をしようとしたのですが英語文献しかなく、何ヶ月か輪読した後に断念しました。。その点 DMBOK は日本語訳が出ており、チームでディスカッションできるレベルまで持っていくことを考えると、訳書があるのは無視できないメリットだなと感じました。ちょっと高いですが、一人一冊購入してバイブルのようにしている企業もあるようですね。

datatech-jp Advent Calendar 2021 2日目の方も記事も読ませていただきましたが、とても共感しました。DMBOK は読んでいて楽しいです。DMBOK は教科書的なことばかり書いてあるかと思いきや、著者たちの思いが詰まった文章が散りばめられています:

note.com

データは資産だと考えて管理することがデータマネジメントですが、「資産」というからには「負債」にもなりうる点にも言及されているのは新たな気づきでした。使う前に必ずデータ欠損チェックを行わなければいけない状態だったり、ライフサイクルが定義されていないためデータ削除ができずに管理コストが膨らんでしまっている環境もあります。

脱線しましたが、こうやってチーム内で DMBOK を読み合わせしたことにより、その後の業務の下地にできたと思います。データセキュリティについてここまで検討できていなかったねとか、メタデータも検討してユーザが参照できる情報を増やさないと、といった議論が横断組織内で行われるようになりました。

事業状況の可視化

事業状況の可視化については以前の記事に書きましたが、DMBOK をベースに弊社横断事業部の状況を加味した独自の成熟度評価を作成しました:

bynatures.hatenadiary.jp

私が横断組織ではなくサービス事業部の中にいたら、ここまでしなくてもよかったかなと思います。自分がサービス事業にいて DMBOK の知識があれば、どの辺が足らないかは課題ベースで取り組めそうですし、周りにディスカッションできるメンバーがいればブレストベースでも目標策定できそうです。サービスの詳しい状況がわからない中で注力事業を判断するという目的があったので独自の成熟度チェックリストを作成したのですが、サービス事業部の方へのデータマネジメントの啓蒙も行えたりするなどのメリットもありました。

横断組織としてデータマネジメントを遂行するメリット

データスチュワードを見つけて支援する

DMBOK にも書かれていますが、多くの組織では暗黙的にデータ周りの業務を担っている担当者がいるはずです。この方を組織の中で見つけ、データの問い合わせやクエリ作成で疲弊している場合はサポートしてあげることがとても大切だと考えています。そして俗人化を防ぐためにこの人の役割に「データスチュワード」と名前を付け、組織として重要なポジションであると伝えると、気づいたらデータ周りに詳しい人がいなくなってしまった、といった事故が防げます。

このデータスチュワードを組織として立て付けようとしている場合、ハードスキルだけでなくソフトスキルが非常に重要なポジションだなと感じています。というのもデータスチュワードはデータを整備して使いやすい状態に保っておくのですが、データ利用者とのコミュニケーションが重要になるためです。利用者がデータを使いやすい状態にするためにはどうしたらよいかが自然に考えられる方だと安心してデータスチュワードをお任せできると思います。

ここにDMBOKなどの外部知識を足して、さらに利用者がデータ活用しやすい状態にするのはどうしたらよいかを戦略として考えられると、データガバナンスとして成熟した状態かと思います。データスチュワードの方は、7つの習慣でいう第三領域(重要ではないが緊急性が高い)に忙殺されている場合が多いので、第二領域(重要だが緊急性は低い)の課題に取り組めるだけの時間やバイタリティが残されているかも組織的には重要です。

横断組織側のメンバーがデータスチュワードになるのは正直厳しいです。サービス内の様々な状況を把握しておかなければいけないため、基本的にはその組織内のメンバーからデータスチュワードの役割を探さなければいけません。ただ横断側としてこういった役割が重要であると伝えられると、企業全体のデータ活用レベルの底支えができると感じています。

駆け込み寺としての機能

データスチュワードを見つけ、その方が意欲的にメタデータの整備やデータモデルの整備を始めたとしても、組織規模によっては一人で孤軍奮闘することになりかねません。そのような場合に一緒に課題解決に取り組んだり、データモデル作成の方法を指南したりすることができます。

もちろん外部の専門家の力を借りるのも選択肢としてはアリですが、組織内に多くのサービス事業を抱える弊社の状況だと、横断組織としてこの役割を保有しておくのは合理的かなと考えています。

データ基盤としてパブリッククラウドを利用する場面もあり、私の組織だとオンプレミスの基盤を中心に運用しているため、まだまだ知見・経験が少ないのですが、パブリッククラウドでどのようにデータ基盤を運用したらよいかのノウハウを溜めておきたいです。ここは今後の課題ですね。この他、データモデリングの方法、データアーキテクチャ図の作成方法、ETL処理基盤のノウハウなど、横断組織として溜めておきたい領域はたくさんあります。今はオンプレミス基盤の運用中心なのですが、今後は外部ツールも積極的に検証して社内展開できると面白そうだなとも考えています。

共通化できるものがあればシステムで共通化する

行わなければいけない、ただ取り組むには時間がなかったり面倒な分野は横断組織として価値が出しやすい領域です。例えば以下の記事で答えていますが、Media Data Tech Studio(旧秋葉原ラボ)ではストリーミング処理システム Mine を開発・運用しています。ここではログのフォーマット管理、バリデーション、転送管理などを行っており、データ品質を保つことに貢献しています。他にも様々なアプリケーションを開発していますが、そうでなくても OSS やマネージドサービスの提供などでも運用が複雑なものであれば横断組織として取り組めるものもあるかなと思います。

developers.cyberagent.co.jp

今後取り組みたいこと

パブリッククラウドに強くなる

弊社ではオンプレミスのデータ基盤を中心に利用していますが、サービス事業部側でパブリッククラウドを利用する場面が増えるなど、いわゆるハイブリッドなデータ基盤を運用しています。オンプレミス側は横断組織、パブリッククラウドはサービス事業部という棲み分けが自然となされていますが、サービス規模も様々なので、相談があった時に困らないようにパブリッククラウドや外部ツールの学習も組織として取り組みたいなと思っています。

データモデリングに強くなる

データモデルは非常に強力です。可視化の力というか、データモデルを見せれば一発で解決するという場面を何度も経験したので、一度しっかりとしたデータモデルを作って定期的に更新すると、コミュニケーションの質が格段に良くなります。データ利用者からの問い合わせに対して「ここに可視化してあります」と一言でレスポンスできる場面も何度もありましたが、その度に作っておいてよかったなと感じました(本当は検索性を上げて、利用者自身が見つけておける状態にしないといけないですが)

データモデリングには鳥の目と虫の目を行き来する苦しさ、自分の理解が徐々に可視化されていく感覚、その先にデータの関係性を可視化の力で殴りかかる痛快感があります。DMBOK ではデータモデラーという役割があるぐらいですし、インフォグラフィクスのような多少アートのような領域でもあるので、もっと詳しくなりたい領域の一つです。まだ経験が少なく、作ったモデルを見せることはできるのですが「指南」できるレベルではないので、ある程度手順化したりして横断組織としての武器を手に入れられたらいいなと思っています。

さいごに

今年は datatech-jp のコミュニティに参加して、社外にこんなにも同じ悩みをもっている方達がいるんだ知れて心強く感じました。私は横断組織にいてサービスを直接見ていない点が少し他の方と違うかなと思い、今のポジションで考えていることをつらつらと書いてみましたが、もしツッコミや質問があれば Twitter でもよいので気軽にご連絡ください。

2021/11/02 ビジネス用語集の整備を始めました

データマネジメントの推進という立場から社内でいろんな方と話をするのですが、データマネジメントの様々な領域の中で自信を持ってアドバイスできるもの、できないものがありました。その中の一つに DMBOK に繰り返し登場する「ビジネス用語集」がありました。

社内用にデータマネジメント成熟度アセスメントのチェックリストを作ったのですが、ここでも「ビジネス用語集」は登場します。これが部分的に存在しているか、更新ルールがあるかなどをヒアリングしていますが、自分の中でそもそも「ビジネス用語集」へのイメージが確立されておらず、ヒアリングを自信を持って進めることができませんでした。

ビジネス用語集について以前にも記事を書きました:

bynatures.hatenadiary.jp

技術的に難しいことはないはずですが、思いつきで進めると更新が保たれず、結果的になんちゃら用語集が乱立する状態となります。必要なのは用語をまとめていく中心となる組織と更新ルールです。社内のデータマネジメントを進める横断組織にいる立場として、この部署で横断側のビジネス用語集を管理していくのは適切だろうと考えて用語集の整備を始めました。

用語集の「ツール」「人」「プロセス」

データマネジメントを進めるにあたり重要な三要素として「ツール」「人」「プロセス」が挙げられますが、「ツール」としては Notion を利用しました。Notion にはインラインデータベースという機能があり、表形式でデータを管理しながらその場で編集できます。ただの表ではなく関係データベースのようにカラムの属性が定義できるので、用語に対するラベルや説明をきっちり整備していくことができます。必要な際にはエクスポートして関係データベースに移行することも容易です。

f:id:bynatures:20211102231952p:plain
Notionでの用語集サンプル

「プロセス」としては今はゆるくしていて、誰でも編集できる状態にしています。ただし対象のNotionページが更新された場合はSlack通知を飛ばし、データ管理部署がその定義が適切かどうかを判断できる体制にしています。

「人」についてはまだ検討段階です。ゆるいルールにしても、この用語集を重要だと感じてもらい、さらに足らない用語を自発的に提供してもらうのはまだまだ時間がかかりそうです。当面はデータ管理チームの方で用語を拡充していく予定ですが、データ利用者からも更新してもらえるような体制にしていきたいです。

この地味な整備に効果はあるのか

用語集を実際に作るまでは、DMBOK に繰り返し登場しているけれど本当に必要なものなのか?教科書的に書いてあるだけなのではないか?と思っていましたが、実際に作ってみると用語集は絶対に必要なものだと感じています。

企業で働いていると必ず社内用語というのが生まれます。組織名、チーム名、なんらかのID、システム名などなど。ウェブ検索で出てくる用語であればよいですが、こういった社内用語は知らなければ業務に支障をきたしたり、理解不足で時間がかかったりする場合があります。これらの用語をまとめることで、日々の業務を円滑に進めるほか、新しく加わったメンバーのオンボーディングにも大きく役立ちます。特にリモート会議などでは意思疎通を音声のみで行うことも多く、用語の共通認識がブレていると打ち合わせがうまく進みません。

用語集を整備していく内に、様々な社内用語をまとめておくべきだと考えるに至りました。弊社も長きにわたって事業を展開していく中で、残念ながら縮小・撤退していく事業も存在します。そういった事業部からは人が抜けて別事業部に異動したりしていますが、たとえシステムが新規開発されなくなくなっても、さらに言えばシステムが停止してもデータは残り続けます。このデータを分析するためには、どうしても用語の定義が必要です。仰々しく言えば属人化を避けて企業活動の記録をデータの観点で行うことが用語集の整備なのかもしれません。言語の成り立ちに詳しくはありませんが、毎年出版される辞書には新たな定義が加わり、私たちが話す自然言語(ここだと日本語)も辞書出版企業によって蓄積されています。企業活動の歴史をデータの観点から積み上げていくものが用語集であり、もっと押し進めればナレッジベースになったりするかもしれません。DMBOK 的に言えばメタデータ整備をしてデータの説明情報を増やしていくことも、これにあたりそうです。

私の経験として、この重要性は伝わる人にはすぐに伝わります。おそらくオンボーディング時や分析時に苦労されたのでしょう。こういう情報が欲しかったと言ってもらえると整備している立場として嬉しく感じます。

この効果を直接表現するのは難しいですが、間接的に可視化する手段がデータマネジメント成熟度アセスメント(DMMA)であり、各分野のレベルが上がるにつれてデータが整備されて使いやすい状態だとわかります。用語集もその一要素として重要だと理解したので、成熟度をあげる一要素と考えて引き続き整備・運用していきます。

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を外すとか、まぁそういったことなのですが、これを作るためには相応のガバナンス体制が必要になってきます。鶏卵の話になってしまいますが、ドキュメントを見やすく発見しやすく管理していくためにはガバナンスがある程度必要になってくるかと思います。もしくは有志の方が自ずと整理されているかもしれませんが、その方がいなくなるとたちまちドキュメントは探しづらくなってしまうでしょう。

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

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

https://www.amazon.co.jp/ビジネスプロセスの教科書―アイデアを「実行力」に転換する方法-山本-政樹-ebook/dp/B012R7EKDQ/ref=sr_1_1?adgrpid=107870604427&dchild=1&gclid=Cj0KCQjw--GFBhDeARIsACH_kdaWsuUusxz_lk4IvamofV4Ii5IbkNSApJfDSIbM8CquUXEk-o2QnAoaAtDMEALw_wcB&hvadid=450367923510&hvdev=c&hvlocphy=1009239&hvnetw=g&hvqmt=e&hvrand=7099048010210625951&hvtargid=kwd-333629590490&hydadcr=2754_11130000&jp-ad-ap=0&keywords=ビジネスプロセスの教科書&qid=1622774959&sr=8-1www.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 を重要視する組織は攻撃のデータ活用ができると説明されています。

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