データモデラー視点からのデータマネジメント入門

データマネジメントをどこからすれば良いだろうか？
DMBOKを読んでみたけど、実際に何をすれば？
と考えている方には、メタデータ管理を中心にデータマネジメントを小さく始めていく内容としています。
データの意味が分からない、提供された、共有されたけどデータを使えないというような、データ基盤が先行してしまった方にも、是非読んで、ここから始めてみていただきたい内容です。

Transcript

1. データモデラー視点で語る データマネジメント入門 ～組織のデータ活用を成功に導くために～ 2025年8月の夏休み 稲見 浩一
2. はじめに 先日、データ横丁のデータモデリング通りという活動の一環として、モデリング方法 論であるTMの紹介をしました。 その際に前提として、データマネジメントを支援している立場としてと話し始めたの で、その勢いでデータモデラー視点からデータマネジメントについての資料を書いて みました。 （動画） （動画／資料）
3. 自己紹介と問題提起 1. 自己紹介 • 元々は受託開発を行う中で、特に業務の理解と要件定義のためにデータモデリングとい う強力な武器を見つけ、その後にシステム開発の周辺にある状況へと手を広げ、現在で はデータマネジメント活動に関する支援活動を生業としています • かつてはDOA+コンソーシアムの幹事や、DMBOK2翻訳時点では一時的にDAMA日 本支部の理事をしていたり、現在はJDMCにも参加しています。 • 最近では、データ横丁にも関わらせていただいています 2. 問題提起 • データ利活用であったり、システム再構築が必要になるする中でも、企業や団体にとって 必要であるデータマネジメントが実践されていない例を多くみかけます。その中で、どう始 めて良いかわからないとか、できる人が居ないという声をよく聞くので、そういう方達に向け て、データマネジメントについて知り、手を付けるきっかけの一つにして欲しいです
4. 過去を振り返る（システム開発黎明期） 現状では、ブラックボックス化したレガシーシステムや、メタデータ不在問題による データ利活用の阻害などへの対応を迫られている状況があります。 過去を振り返り、原因を見てみましょう。 情報システム初期 給与計算などの比較的単純で大量 の繰り返し処理を単体で、電子計 算機に実行させるところから始まりま した。 インプット→処理→アウトプット の構図で、結果として給与が計算で き、必要な帳票を印刷できれば良 かったのです。 拡大期（汎用機） 計算機の利用が広がり、様々なシス テムが事業予算単位に、販売管理 だったり、生産管理だったりと作られ 始めました。汎用機であるため、今で いえば単純なFramework上で同 じようなシステム開発で良いという面 と、急激に需要が膨らむ中でのエン ジニア不足が発生し、間違った開発 標準などにつながりました。 オープン化 基幹業務へのUNIXサーバの導入を 契機に、汎用機から乗り換える例が 増えました。ISAMからRDBMSへ、 COBOLからCやJavaなどへの変更 が行われ、後にクライアントサーバか らWebへと。例えばRDBMSを理解 せずにISAMへの入出力のような設 計をしてしまうなどの技術不足による 弊害が増えました。
5. 過去を振り返る（データの流通） こうやって、個別のシステムがいくつも作られ、それぞれに機能が増えて複雑化す る中、それまで個別だったシステム間に連携の要求が増えてきました。 製造関連システム 製造A 製造B 製造B 販売関連システム 販売P 販売Q 販売R 〇〇間連携という機能（つまりプログラム）が部 門内でも増え、更には部門間に広がり巨大なメッ シュ構造になってしまいました。 中心にデータHUBといったデータ交換、流通の仕 組みを持てば良かったのですが、連携の要求ごとに 機能追加することが多く、こんな形になったものが 多かったようです。 結果として、システムの再構築などの場合も、これ らが解きほぐされて影響範囲がわからないとと、仕 様が塩漬けになる部分が増えてしまったりしました。
6. システム開発どうすべきだったか？ ここでは、ICONIXというプロセスの説明図を利用しましょう。 ICONIX Process (click for a larger image) この部分に データモデリングを！ 右下に示した酒匂さんの本から一節を拝借します。 • システムとは外から与えられる情報により、ドメインモ デルが更新され続けるものである • こうした考え方は特に目新しいものではなく、 事務処理系のソフトウェアを、巨大なデータモデルを 更新し続けているものとして捉える見方はむしろ一 般的な方法です ユースケースを考える一方で、それが実行可能なデー タモデルを考えるのは妥当ですよね。 2003年12月1日 初版第1刷発行
7. 本来はデータが中心 EA（Enterprise Architecture）を示すのに良く使われる4層のピラミッドを 見てみましょう。 BA DA AA TA 本来なら、ビジネスの要件があり、そこで必要なデータを考え、 それを支えるテクノロジーを利用してアプリケーションを開発す るという形になっています。 しかしながら、「機能」を中心にしてデータはそこに従えられた 付属物に近い存在となり、歪んだ構造になってしまいました。 なので、アプリケーションを介さないと、そこに格納されている データの意味を読みだせない状況が起きています。 AA データ 歪んだ構造 明らかなDAは 存在せず、AAの アプリケーション 内でデータが取り 扱われている
8. DMBOKを読み解く： どこから手をつけるべきか？
9. DAMAとDMBOK2 データマネジメントの基礎知識としてはDAMAがまとめた「データマネジメント知識 体系ガイド 第二版」を参照するのが良いでしょう。通称DMBOK2と呼ばれます。 17章あり600ページを超える本ですが、各章は40ページ前後に過ぎません。 • 左の図はDAMAホイールと呼ばれる図で、データガバナンスを中 心に10個の知識領域が取り囲んでいる形になっています • この他に、データ取扱い倫理、ビッグデータとデータサイエンス、 データマネジメント成熟度アセスメント、データマネジメント組織と 役割期待、データマネジメントと組織の変革の章が用意されて います • 先頭からでも興味がある章からでも読んでみましょう デ ー タ マ ネ ジ メ ン ト 知 識 体 系 ガ イ ド 第 二 版改 定 新 版 ※図はDAMA日本支部のサイトで見ることができます。
10. どこから読むか？取り組むか？ データマネジメントを実践する目的次第と言ってしまうと身も蓋もないので、もう少 し考察してみましょう。本書はタイトルで「入門」としている通り、既にガンガン実践 できている組織は置いておいて、これから始める、あるいは始めたがうまく進んでい ないという場合を想定しています。 中心課題 • ブラックボックス化したレガ シーシステム • メタデータ不在問題による データ利活用の阻害 • データ品質問題 と置いてみましょう。 • 実施すべきことに対して戦略を考え、その実施計画を立て、計画 通りに実施し、評価を行うためには、データガバナンスは必須です • 何処にデータがあるのかわからない、あるいはそのデータの意味が 分からないというメタデータ不在問題への対応には、メタデータ管 理も必須です • そして、データ品質に問題を抱えていることも少なくなく、データマネ ジメントの中心課題でもあるデータ品質も必須です • データの在りかを突き止め、新しい在りようの青写真を描くのは、 再構築でも利活用でもデータアーキテクチャが必須です
11. 4つの領域を中心に加えていく 再構築はある一定の領域を最終的には構築し直しますが、部分的に実現する 方法も様々に登場しています。また、データ利活用に関しては、効果が見込まれ るものから少しづつ実現することが好まれています。 右の図は、DMBOK2の第1章にあるピーター・エイキンのフレームワークと 呼ばれるもので、どの領域から実施すべきかの記述がない中、DMBOK2 で唯一フェーズ分けをしているものです。 フェーズ1～4に分かれ、情報システムがあるならデータストレージがあり、 何らかのセキュリティが施され、一部のデータが統合されているだろうという ことと、データモデリングがフェーズ1に置かれています。 フェーズ2でデータアーキテクチャ、メタデータ、データ品質と進み、フェーズ ３でようやくデータガバナンスやMDMが登場しています。 明にデータマネジメントに取り組んでいなくても、何等か着手されているこ とを下地に出発する形になっています。
12. フェーズ2と3 前頁の通り、フェーズ1にあるものはデータモデリング以外は概ね何らかの形で実 現しているものがあるでしょう（データマネジメントとしての過不足、成熟度は少し 後回しにしておいても）。そこで実際のデータマネジメント活動としては、次の領 域から取り組みましょう。これらは、相互に依存しています。一部例示します。 • メタデータを収集するための仕組みとしてデータガバナンスが必要 • データ品質を測るには、基準を示すメタデータ定義が必要 • データ品質の改善を行い、結果を確認するためにはデータガバナンスが必要 • メタデータの管理サイクル、データ品質の保全サイクルを回すにはデータガバナンスが必要 • まずは計画を立てるにはデータガバナンスが必要で、その中では全体像としてのデータアーキ テクチャを描いていくことが必要 • データアーキテクチャにはメタデータ（の中でもデータモデルを用いた文脈の理解）が深く関 与する
13. コンテキスト図 DMBOK2の殆どの章に左図のようなコンテキスト図と いう図が掲載されています。 上部に定義とゴールが示され、中央に左からインプット、 アクティビティ、成果物が並んでいます。その下には、イ ンプットの共有者、アクティビティの参加者、成果物の 利用者が示されています。 最下段には技法、ツール、評価尺度が並んでいます。 この図を見るだけでも、何をするかある程度分かります。 ※図はDAMA日本支部のサイトで見ることができます。 DMBOK2の購入前でも、コンテキスト図だけでも見ておくと 良いかも知れません。
14. データガバナンス データマネジメントとして考えるなら、現状を知ること（アセスメント）、課題の調 査（事象と原因と影響）とそれらからの全体計画が必要です。 ガバナンスというと日本では特に統制という監視や管理のイメージを持たれること が強いかも知れません。それも一面です。DMBOK2では組織構成を考えるのに、 立法と司法の視点（正しい事を行う）と行政の視点（物事を正しく行う）とし ています。ガバナンスを実践するための組織（役割の枠組み）を作り、データス チュワードなどの人（役割）を割り当てることも特に開始当初には必要です。 監視するより、戦略を立てて計画し、実現に向けた支援を行うことが必要です。 検討メンバーを 集める 現状を調査する 課題を発見し、 調査する 目標とのギャップ を埋める計画を 立てる 組織と役割を設 計して人を配置 する
15. 組織と役割についても良く質問を受けますが、唯一の正解はありません。前述の 活動から基本の形を考えます。 • ガバナンスの基本的なことは、データガバナンスオフィス （DGO)を置いて、そこで担います。計画を立て、結 果を評価します。また、各活動を監視するというよりも 現実的に支援することが重要です • エンタープライズデータアーキテクトは、独立で置けない 場合は、メタデータ管理のデータモデラーを使いながら データガバナンスオフィスで担います • データ共有などを実施するプラットフォームの実装は、 この配下にチームを構成するか、既存のIT部門と連 携して実施することになります • メタデータの定義においてもデータ品質に関しても業 務部門との連携が重要なので、その連携の仕組みを この中に組み込んでおくことが必要です 意思決定 （役員レベル） データガバナンスオフィス(DGO) （計画／評価／支援） データスチュワード （メタデータ管理） データスチュワード （データ品質） エンタープライズ データアーキテクト
16. メタデータ管理 最近は、その公開手段としてのツールともいえるデータカタログ製品への注目度が 高くなっているようです。メタデータには、ビジネス、テクニカル、運用と種類がありま す。今回は、特に最近話題となっているビジネスメタデータを取り上げます。 • 図は、特別会員にだけクーポン発行されている様を書いた簡易的な論理データモデルです • データカタログが、テクニカルメタデータのみを 扱っている場合、ビジネス上の意味付けを 知るのは難しいです • 更にビジネスメタデータといっても「会員区分」 という属性の説明だけで読み取るのは難しいです • 会員の属性であること、会員には部分集合として 一般会員と特別会員があること、その特別会員 のみがクーポン発行と関連を持っていること • これらが分析されて文脈としてのメタデータとなります
17. 論理データモデルの例を示しましたが、実際のメタデータ管理としては、論理モデ ルと実装の間でのマッピングが必要です。論理モデルで言うこの属性は、例えばど のテーブルのどの列に格納されているかわかるように、また逆向きも同様です。 • メタデータとしてどのような内容をどこまで 管理すべきか、これは成熟度に応じて 増やすことも含めて決めましょう • 一度集めて終わりではなく維持し続け ることが重要です。そのためにガバナンス の仕組みが必要です • データ品質もメタデータの一つでもあり、 データ品質を守る指標としてメタデータ が用いられるという関係にもあります 業務システム側 物理 実装 物理 実装 物理 実装 論理 モデル 論理 モデル 論理 モデル 統合環境 物理 実装 論理 モデル データカタログ メタデータリポジトリ 利活用 データ マート データ マート
18. データ品質 データ品質には、大きく2つの面があります。わかり易い方で言えば、計測、判定 可能である品質を問うものです。もう一つは、役に立っているか？ということであり、 判定は難しくなります。まずは、判定可能なものから対処していきます。 1. メタデータから浮かび上がる課題 • メタデータを整備する中で、複数のデータソースから同義のモノが出てくるなど、これらの中 で正となるものは何か、対処としては最終的にMDMの導入が必要な場合もあります 2. 初期アセスメントの実施 • 初期アセスメントとして予備的なデータプロファイリングを実施します • リファレンスデータとなる区分値が定義にないものはないか？定義されているのに使われて いないものはないか？場合によっては元のデータモデルに反映する必要があります • MDMの導入までいかなくても、重複値の排除など必要な手立てを行う必要があります
19. 初期アセスメントでも使用するデータプロファイリングについて少し紹介します。 • 実施計画を立てます • 用意するものを揃えます。なければ作ってでも用意します • 実データが余りに大量の場合は、サンプリングの検討が必要な場合あり • 実施内容 • 対象テーブルを絞り、統計的解析として、レコード数、ユニーク数、最頻値、分 布（ヒストグラム）、NULL数、基本統計量（平均、中央値、最小・最大、 標準偏差）を調べる • 文字列長、正規表現パターン（コード類、郵便番号、電話番号など）、範囲 外の値や異常値を調べる • 複合キーから実際にユニークになる属性を炙り出したり、複数トランザクション間 での時系列の確認、参照整合性の確保などデータ間の整合性を確認する • 調査結果から関連する課題探求を行う追加調査を実施し、報告のためのレ ポートにまとめる 用意するもの 論理 データ モデル データ ベース 定義書 実データの コピー 論物 マッピング表
20. エンタープライズアーキテクチャ 目的としては現在および長期のデータ要件を満たすデータの構造と計画を設計 することですが、最初にはこちらも調査が必要です。 1. 既存システムの調査 • マネジメント対象とすべきどんなシステムが、どこにどれだけあるのか、管理責任元の部署なり責任者までを 一覧にして明らかにする • 上記システムに関してメタデータとして明らかなものがどれだけあるのか、ないのか調べる 2. データ要件を明らかにする • 起きている問題点の解消や、利活用など、実現しようとすることをできるだけ要件として明らかにする • 明らかになった要件が関連するシステムを洗い出す 3. 現行のパイプラインを洗い出す • 要件を実現するために活用可能なパイプラインを洗い出し、利用の要求元とデータの発生源となるシステ ムの関連を見つける
21. 右図は、DMBOK2の第4章から引用したもので、 企業内のデータモデルの全体像を示しています。 • 残念ながら多くの場合、これらのモデルが整っているこ とは少なく、殆ど何も構成できていないこともあります • 再構築を行う場合、対象となる最下層のモデル群を AsIsのモデルとして分析する必要があります • 利活用では、できるだけ要件に合わせて、前頁での 調査に基づき、欲しいデータがどこにあるのか、その データの周辺にはどのようなデータが存在するのかをビ ジネスメタデータのレベルで探求するためのモデリングを 実施し、必要に応じて範囲を広げる必要があります • 結果をメタデータとしてリポジトリ管理し、管理可能な 領域を広げていくことを進めていきます
22. 人材について DMBOKでは、現在データを保全している人たちを探し、その人たちに正当な役 割としてデータマネジメントに従事してもらうことが出発点として望ましいとあります。 前述のデータガバナンスにおける組織構成を思い出してください。 1. 意思決定機関（役員レベル） • 可能ならCDOを置き、データマネジメント活動をリソース面と意思の表明という意味でも支援し、ビジネス 上必要なデータ利用が可能な組織に変革、推進する責任を持つ 2. データガバナンスオフィス（DGO） • データマネジメント全般（最初は前述通り絞る）に対する知識が必要で、初期にはできるだけ広い知識 を有する者が居ることが望ましい • ここで、DGOの核となるメンバー以外にも各業務部門やIT部門の実践者を巻き込んでおく必要がある • 社内で確保することが難しい場合、外部から専門家を招聘して、育成しながら実践という形をとることが望 ましい。例えばポリシーを作成する場合でも、外部の専門家が作成したものは各社の事情を強く反映した ものではないので、それぞれに必要なテーラリングが必要である。組織構成なども同様
23. （続き） 3. エンタープライズデータアーキテクト • 各システムの実情調査とエンタープライズデータモデルの行うスキルが必要である。全体を描くアーキテクトと データモデラー、各システムの実現に必要なデータエンジニアを集めることが理想である • 以下も含め、初期には外部の専門家を招聘し、技術移転を受けながら自社で実践できる形を作っていく 4. データスチュワード（メタデータ管理） • 中心はデータモデラーが務めることが多いが、新たなデータの登録要求に既存データの確認や標準化など の対応といった維持管理の側面での人材も必要となる • また、初期の段階ではデータ統合に関してもこのスチュワードが担う可能性が高い 5. データスチュワード（データ品質） • 実データの品質を測るには、データエンジニアと呼ばれる範疇のスキルが必要である。多種大量のデータの 品質を監視するため、最近ではツールによる実施の必要性が高く、それらのツール選定や導入なども必要 • 発見した不具合への対処、こちらはデータ発生元を含めた対応が必要なことも多く、円滑なコミュニケー ションが必要となる
24. 少し先送りするもの よく、「マスタデータの不整合に困っているのでMDMの製品を導入して解決した い」という声を聞きます。ヒアリングしてみると、前述の活動ができていない中、とも かく製品導入して対応したい、という場合が少なくありません。 • 例えば、その「お客様の情報」は、社内のどこにどれだけありますか？ • それらは整合性を持ってマッピングできますか？ • それぞれが持っているどの属性が共通になれば良いでしょうか？独立して管理した方が良い 属性はどれですか？いくつか集めたデータベース設計書だけで判断できますか？ • 仮に一度整合性が取れる状態に持って行けたとして、どう維持しますか？ メタデータ管理、データ品質、データガバナンス、そして現状のデータアーキテクチャ の情報が必要になることは間違いなさそうです。 • 範囲を絞ってでもこれらの実施が先行する形で進める必要があります。喫緊の課題であっ ても、MDMや本格的なデータ共有基盤などは、少し先送りする必要がありそうです。
25. その他の参考図書 DMBOK2より、個別に詳しく語られた本があるので紹介しておきます。 データスチュワードシップ データマネジメント＆ガバナンスの実践ガイド David Plotkin 著 データ品質プロジェクト実践ガイド Danette McGilvray 著 データ戦略の策定 データガバナンス確立のために Marilu Lopez 著 （Amazon／日本語版含む各国語版）
26. おわりに 冒頭にも書いたように、勢いで書いてみた夏休みの宿題的な感じになりましたが、いかがでしょ うか？データマネジメントに取り組むヒントくらいにはなりそうでしょうか？ 様々な図書が出てきていますが、それはそれとして、取り組みを始める最初の数人の段階では 是非DMBOK2を輪読し、自分たちが取り組むべきところを選択してみて欲しいです。 また、様々なコミュニティがあるので参加してみましょう。 • DAMA日本支部 DMBOKの発行元の日本支部です。概説セミナーをしたり、分科会活動やADMCという年次イベントを開 催しています • JDMC（日本データマネジメント・コンソーシアム） こちらも春に年次イベントがあり、年間を通じて様々な研究会が開催されています • データ横丁 日々データを扱う実務者がゆるやかに繋がるコミュニティです。様々なイベントも開催中です 私はいずれにも参加していますので、質問などありましたらそちらでもどうぞ。
27. ご覧いただき、 ありがとうございました 記載誤りのご指摘や、 ご質問、ご相談など ご連絡は各コミュニティや SNSでお願いします