【DMBOKで学ぶ】マスターデータ管理（MDM）

ここでは、データマネジメント知識体系（DMBOK）を参考にして、マスターデータ管理（MDM）について以下の観点で解説します。

• マスターデータと参照データ
• DMBOKにおけるマスターデータ管理の位置付け
• MDMとRDM

なお、データマネジメントとは、
データ資産の価値を提供、維持向上させるためにデータライフサイクルを通して計画、実施、監督すること
です。
※データライフサイクル

関連記事
データマネジメントの導入方法

マスターデータと参照データ

DMBOKでは、データを次のように分類しています。

まず、データは構造化データと非構造化データに分けることができます。

構造化データはさらに以下のように分類することができます。

参照データは、通常、コード、摘要、定義から成るシンプルなリストで表されます。
画面のプルダウンリストで選択できる一覧を考えていただくとイメージしやすいと思います。

次の例では、注文データ（トランザクションデータ）に意味を与える共通概念である顧客データや製品データがマスターデータになります。
また、注文データ、顧客データ、製品データの特徴を表す性別（男性、女性など）、年代（１０代、２０代など）、色（青、赤など）、サイズ（S、L、Mなど）、注文ステータス（受注済、出荷済、請求済など）が参照データになります。

これを見てもわかるように参照データは、機械学習によってデータを分析するときの特徴量（説明変数）になります。
なので、企業全体で、「なぜ何の参照データを管理するか」を決めることは大変重要です。
ここでは、マスターデータだけではなく参照データも対象にして説明します。
以降、マスターデータ管理をMDM、参照データ管理をRDMと略して記述します。

参照データの種類

参照データは次のように分類することができます。

独自参照データと社内参照データ

• 独自参照データ
  事業単位や内部業務プロセス、アプリケーションシステム用に作成された参照データ。
  事業単位によって顧客のステータスの表現が異なる場合、各事業単位で独自に顧客ステータスを管理する必要があります。
• 社内参照データ
  社内で一元的に管理されている参照データ。
  例えば、顧客のステータスを表す用語が統一されていない場合、ある時点においてあるステータスの顧客の社内総数を把握するのが困難になります。

業界参照データ

個々の企業ではなく業界全体や政府機関によって作成され維持される参照データ。
例えば、国際疾病分類コード（ICD）は健康状態（診断）と治療（手順）を分類する共通の方法を提供し、健康管理とその成果を伝える際に一貫したアプローチが取れるようにしています。

地理データと地球統計学データ

国勢調査局の人口密度や人口動態データ、気象の履歴など、地理データや地球統計学データを参照データとして使うと、地理に基づいた分類や分析が可能になります。

演算用参照データ

共通した演算手法を参照データとして使うことができます。
例えば、外国為替計算は管理されたタイムスタンプ付きの為替変換テーブルを使用しています。

マスターデータの種類

DMBOKではマスターデータを大きく次のように分類しています。

• パーティマスターデータ
• 財務マスターデータ
• 法令マスターデータ
• 製品マスターデータ
• ロケーションマスターデータ
• 業種マスターデータ

パーティマスターデータ

パーティマスターデータのパーティは、Party、人の集まりを表しています。
なので、個人や組織、また彼らが業務関係の中で果たす役割に関するデータが含まれます。
企業では、顧客、従業員、ベンダー、パートナー、競合他社などがパーティに含まれます。
CRM（顧客関係管理）システムは、顧客に関するマスターデータを管理し、全顧客に関する完全で正確な情報を提供することを目的とします。
個人や従業員、ベンダーなど顧客以外のパーティデータも含めて一元管理したい場合、独自のMDMシステムを構築する必要があります。
さて、組織などパーティの構造は頻繁に変更されます。
部の下位に新しい課が増えた程度であれば問題ありませんが、今までの事業本部ー部ー課という構造から事業本部ー事業部ー部ー課というように構造自体の変更や、事業本部の下位に直接課があるなど単純な直列ではない複雑なケースもあります。
マーティン・ファウラーのアナリシスパターン―再利用可能なオブジェクトモデル (Object Technology Series)では、このような複雑なケースに対応できるデータモデルのパターンとして「責任関係(accountability)パターン」を紹介しています。

責任関係パターンでは、型を知識レベルと操作レベルに分離します。

知識レベルは操作レベルのメタモデルに対応し、知識レベルの実例（インスタンス）は、操作レベルの型に対応します。
集合でいうと、知識レベルは操作レベルの集合族という位置付けになります。
※ある集合Sの部分集合からなる集合をSの集合族といいます。
知識レベルのパーティ型と責任関係型で、事業本部ー事業部ー部ー課など、組織の構造を規定し、その実例として、A事業本部ーA-1事業部などパーティと責任関係を定義できるようにすることで柔軟に組織変更に対応できるようになります。

出典：アナリシスパターンを読もう
柔軟に組織構造を変えたい場合は、責任関係パターンを参考にしてパーティマスターデータのモデルを設計することができます。
それから、過去のどの部門が統合、廃止されて現在の部門になったのか来歴をデータウェアハウス上に残しておくと、その時点の状況を把握することができるようになります。

財務マスターデータ

財務マスターデータには、事業単位、コストセンター、プロフィットセンター、勘定科目、予算、財務予測、プロジェクトなど財務に関するデータが含まれます。
通常、ERPシステムは、財務マスターデータ（勘定科目）の中心的なハブとして機能し、複数の周辺アプリケーションで作成され処理されるプロジェクトの詳細や取引記録を扱います。
ビジネスシステムの多くは、企業内のお金や物の動き、つまり、どのようにお金や物が入ってきてどのように出て行くのかを記録し、追跡できるようにするために作られています。
アナリシスパターン―再利用可能なオブジェクトモデル (Object Technology Series)では、お金や物の動きを記録する一般的なパターンとして、「在庫管理と会計パターン」を紹介しています。

在庫管理と会計パターンを適用することで、要約勘定やトランザクションも表現することができます。
なお、勘定、明細勘定、要約勘定の関係は、オブジェクト指向における再利用のためのデザインパターン、通称、GoFのデザインパターンのCompositeパターンを適用しています。

法令マスターデータ

法令マスターデータには、契約や規則などの法的事項に関するデータが含まれています。
法令マスターデータでは、同じ製品やサービスを提供しているさまざまな事業体の契約を分析して、より良い交渉を可能にしたり、契約をマスター契約に組み入れたりすることができます。

製品マスターデータ

製品マスターデータは、社内の製品やサービス、業界全体（競合他社含む）の製品やサービスを扱うことができます。
製品マスターデータは、次のように、ビジネス機能によって内容が異なります。

• PLM（プロダクトライフサイクル管理)
  PLMは、製品やサービスの構想、開発、製造、販売・配送、保守、破棄までのライフサイクル管理に重点を置いています。
  製品開発では、製品のコンセプトがアイデアの段階から最終プロダクトに進化するに伴い製品名が変わったり、最終的に異なるライセンス形態になったりします。
  製品ライフサイクルが長い製薬業界などのPLMでは、製品開発における製品の進化に対応して、複数のプロセスで発生するコストや法的合意事項を追跡することができます。
• PDM（プロダクトデータマネジメント）
  PDMは、エンジニアリング機能と製造機能を支援するので、設計図書（CAD図面など）、レシピ（製造指示書）、標準操作手順、部品表（BOM）のような製品情報を安全に共有することができます。
• 販売在庫管理
  ERPシステムの販売在庫管理内の製品データは、最小在庫管理単位（SKU）を使って在庫レベルに対応した注文入力を支援します。
• MES（生産実行システム）
  MES内の製品データは、原材料在庫、半完成品、完成品に重点を置き、完成品は、ERPシステム（販売在庫管理）を通じて、ストックや注文できる製品と紐づけることができます。
  MES内の製品データは、サプライチェーンやロジスティックスシステム全体にとっても重要になります。
• CRM（顧客関係管理）
  CRM内の製品データは、マーケティング、販売、製品サポートのやり取りを支援し、その中には製品ファミリーやブランド、営業担当者の関連付け、顧客ドメインの管理、マーケティングキャンペーンなどが含まれます。

次の図は、バリューチェーンを構成する活動のうち製品データが関係する箇所を示しています

マーケティングマネジメント―持続的成長の開発と戦略展開で、フィリップ・コトラーは、製品の階層構造を次のように説明しています。

• ニーズ・ファミリー
  製品ファミリーのもととなる中核ニーズ。
  生命保険の例
  安全。
• 製品ファミリー
  中核ニーズを満足させる全ての製品クラス。
  生命保険の例
  貯蓄と所得。
• 製品クラス
  製品ファミリーの中で機能的一貫性を持っているとみなされる製品グループ。
  生命保険の例
  金融手段。
• 製品ライン
  製品クラスの中で、機能、顧客、販路、価格水準などを同じくすることで密接に関連づけられている製品グループ。
  生命保険の例
  生命保険。
• 製品タイプ
  製品ラインの中で、形態や様式が同じもの。
  生命保険の例
  長期契約の生命保険。
• ブランド
  製品ラインの中の一つあるいは複数のアイテムにつけられた名前であり、アイテムの特性や出所を明らかにするもの。
  生命保険の例
  プルーデンシャル。
• アイテム
  製品ラインやブランドの中で、サイズ、価格、外見、その他の特性で区別される単位。
  生命保険の例
  プルーデンシャル更新可能長期保険。

これらは、すべて製品の種類を表しています。
しかし、受注生産で一台一台製造される機械などは製品単体でも管理されます。
次の図は、製品番号で識別される製品種類を表す製品エンティティと、製造番号（シリアル番号）で識別される製品単体エンティティの関係を表しています。
なので、製品種類が複数の製品単体に関連しています。
また、製品種類は、参照データである仕様×サイズ×色によって製品番号が一意に決まる最小在庫管理単位（SKU）を表しています。

この製品の種類と製品の単体の関係は、先ほどパーティマスターデータで紹介した、パーティ型とパーティと同様、冪集合と集合の関係になっています。
製品マスターデータの複雑な階層構造をモデル化するときは、責任関係パターンを適用することができます。

以上より、製品ライフサイクル全体で製品マスターデータを管理したい場合、
製品の種類だけでなく製品単体まで表すのか
製品の種類はどの階層まで表すのか
など製品データの粒度を考慮してデータモデルを考える必要があります。

ロケーションマスターデータ

ロケーションマスターデータは、地理情報を追跡して共有し、それに基づいて階層関係や担当地域を生成する機能を持ちます。
ロケーションマスターデータには、業務関係者の住所や、組織が所有地にある施設の住所が含まれます。
また、ロケーションマスターデータの参照データには、通常、国や地方、郵便番号などの地政学的データと、緯度、経度、高度など地理的座標が含まれます。

業種マスターデータ

ダン＆ブラッドストリート社による世界的な企業本部、子会社、支社のディレクトリや、米国医師会の処方医師データベースなど、外部から購入できるマスターデータがあります。

DMBOKにおけるマスターデータ管理の位置付け

次の図は、DMBOKにおけるデータマネジメントのフレームワークですが、これを見ると、マスターデータ管理と参照データ管理は、データライフサイクル管理の実装と維持に位置付けられています。

マスターデータ管理と参照データ管理に関連する主な活動は、全体に関わる「データガバナンス」と「基礎的なアクティビティ」、および、マスターデータを統合するときのフレームワークになる「データ統合と相互運用」になります。
なので、マスターデータ、参照データを管理するときは、データガバナンス、および、データリスク管理、メタデータ管理、データ品質管理を考慮する必要があります。

MDMとRDM

目的

MDMの目的

DMBOKでは、MDMの目的を、
マスターデータの値と識別子を制御し、重要なビジネスエンティティに関する最も正確でタイムリーなデータをシステム間で一貫して使用できるようにすること
と説明しています。
各企業でMDMを行う場合、企業全体でマスターデータを一元管理することによって、どのようなビジネス課題が解決されるのか明確にする必要があります。
DMBOKでは、MDMを進める意義として
業務効率の改善
顧客サービスの改善
プライバシーとコンプライアンスに関連するリスクの低減
という例を上げています。
次の図は、バリューチェーンを構成する活動のうち顧客データが関係する箇所を示していますが、カスタマーサポートの問合で使用する顧客データと、注文や出荷、請求で使用する顧客データが別々に管理されていた場合、配送状況や注文内容に関するお客様からの問合にすぐに答えることができず、顧客サービスの品質低下を招く可能性があります。
また、販売の顧客データと、出荷の顧客データが別々に管理されており、販売の顧客データのみ最新になっている場合、誤送による顧客サービスの品質低下を招く可能性があります。
データサイエンスでは、顧客の購買履歴に、顧客の嗜好やクレームなど紐づけて分析しますが、このように顧客データがバラバラになっていると必要なデータを準備するのに時間がかかります。
さらに、顧客データが散在していると、それだけ顧客データの漏洩リスクが高くなります。

また、次の図のように、サプライチェーンを構成する、購買、入荷、生産、販売、出荷で使用する部品データや製品データが別々に管理されていた場合、データの紐付けや変換によるオーバーヘッドが発生します。

MDMの実現要件は、定性的な内容だけでなく
在庫月数や在庫回転率をどの程度にするのか
納入リードタイムをどの程度にするのか
など、可能な限り定量的なKPIとして設定することが望ましいと考えられます。
DXの観点で考えると、MDMの導入により、次のような効果を考えることができます。
データの理解、準備作業を効率化、高品質化することで、データサイエンスによる仮説検証の効率と品質を上げることができる。
マスターデータ管理機能をサービス化し、再利用性、保守性を高めることで、業務とシステムを変化に強い構造にすることができる。

RDMの目的

参照データは、データのドメイン（定義域）をリスト形式で管理しますが、次のような点でマスターデータと異なります。

• あまり頻繁に変更されない
• データの構造が複雑でなく小さい
• 同一性がなく、複数のデータが同じ実体を指すのか識別する（エンティティの解決）必要はない

ドメインモデル駆動設計でいうドメインオブジェクトの種類でいうと、マスターデータは同一性を持つエンティティになりますが、参照データは、同一性を持たない値オブジェクトと同じ位置付けになります。
DMBOKでは、RDMの目的を、
異なる機能間で参照データのリストの一貫性と最新性を保証し、組織がデータにアクセスできることを保証すること
と説明しています。
参照データには、利用する組織の外部で発生するものが多くあります。
なので、RDMでは、データの所有者や保守責任者を明確にし、リストの最新性を維持する必要性があります。
DMBOKでは、RDMによって次のようなビジネス上の効果が期待できる説明しています。

• 参照データを一元的に関することによるコスト低減
• システム間で矛盾が生じるリスクの低減

ソリューション

ここでは、MDMやRDMをどう実現するのかソリューションについて説明します。

アーキテクチャ

MDMやRDMをハブ＆スポークのデータ連携モデルで実現する場合、次の３つのケースがあります。

• レジストリ
  マスターデータハブは、さまざまな記録システムのマスターデータを指すレジストリであるケースです。
  マスターデータは、記録システムで管理されており、マスターデータへのアクセスはレジストリのインデックスを介して行われます。
  この場合、記録システム自体の変更がほとんどないため、実装が比較的簡単ですが、複数の記録システムからマスターデータを組み立てるには複雑なクエリが必要になります。
  ※記録システム（System of Record）
  定義された一連のルールに基づいてデータを作成し維持する正式なシステム。
  
• トランザクションハブ
  マスターデータハブが記録システムであるトランザクションハブになりマスターデータを管理するパターンです。
  なので、マスターデータはトランザクションハブ内に存在し、他のアプリケーションには存在しません。
  それまで記録システムとして機能していたアプリケーション側に変更が求められ実装にコストはかかりますが、トランザクションハブでマスターデータが一元管理されるためガバナンスの質が上がります。
  
• 統合アプローチ
  レジストリとトランザクションハブのハイブリッドです。
  記録システムではアプリケーションの局所的マスターデータを管理します。
  マスターデータは、共通のリポジトリ内で統合され、マスターデータの参照システムであるデータ共有ハブから利用可能になります。
  ※参照システム（System of Reference）
  データ利用者がトランザクションや分析のために信頼できるデータを取得する正式なシステム。
  

ツール

MDMは次のようなツールを利用して実装されます。

• データ統合ツール
• データ修復ツール
• オペレーショナルデータストア
• データ共有ハブ
• MDM専用アプリケーション

データ統合ツール

データを統合する場合、ETLとELTの２種類があります。
ETLのEはExtract（抽出）、TはTransform（変換）、LはLoad（取込）を表しています。
次に変換の例をあげます。

• フォーマットの変更
  EBCDICからASCIIに変換するなど、データの技術的フォーマットを変換します。
• 構造の変更
  非正規化レコードを正規化レコードに変換するなど、データの構造を変換します。
• 意味的変換
  性別コードを０、１、２、３からUNKNOWN、FEMALE、MALE、NOT PROVIDEDに変換するなど一貫性のある意味的表現を維持するためのデータを変換します。
• 重複排除
  データが一意に決まる場合、重複するデータを排除します。
• 並べ替え
  定義されたパターンに合わせてデータの順序を変更します。

ETLとELTは、アプリケーション間や組織間でデータをやり取りするときのプロセスです。
ETLやELTは、
定期的に予定が組まれたバッチ処理や
データが利用可能になった時点におけるイベント駆動処理やリアルタイム処理
で実行されます。
ETLかELTは、Transform（変換）機能の多さによって選択します。
非構造化データのように、より多くの変換機能がある場合は、一旦、取り込んだ後に変換するELTが選択されます。
ETLの場合

ELTの場合

データ修復ツール

MDMでは、取得したソースデータを検証、標準化、強化することでエンティティを解決する必要があります。

• データの検証
  データが間違っているか、欠落しているか特定し、間違っている場合は削除するなどの処置を行います。
• データの標準化
  標準的な参照データ値（国コードなど）、書式（電話番号、住所など）にデータ内容が一致することを保証します。
• データの強化
  エンティティを解決するために必要な属性（生成日時、更新日時など）を追加します。

エンティティの解決
複数のデータが同じ実体（エンティティ）を指すのか、異なる実体を指すのか判断します。
該当データを決定論的アルゴリズムや確率的アルゴリズムでマッチングします。
マッチング後、該当データをリンクするかマージします。
その際、

• 氏名、生年月日、マイナンバーが同じだが住所が異なる場合、住所を変更しただけで同一人物か
• 生年月日、住所、マイナンバーが同じだが姓が異なる場合、姓が変わっただけで同一人物か

などマッチングルールを決めます。
マッチングルールは定期的に再評価し信頼レベルを上げていきます。
マッチングの結果、間違いが判明する場合があるので、マッチングの履歴を保持し、元に戻せるようにします。

オペレーショナルデータストア

アプリケーションが操作時に収集するオペレーショナルデータを様々なフォーマット（RDB、ログファイル、スプレッドシートなど）で保管できるリポジトリです。

体制

DMBOKではデータが適切にマネジメントされるよう統治するデータガバナンス組織を次のように表しています。

• 立法機能
  ポリシー、規定、エンタープライズデータアーキテクチャを定義する。
• 司法機能
  課題管理と報告。
• 行政機能
  データの保護とサービス、行政責任。

この中のデータスチュワードは主に次のような活動を行います。

• コアとなるメタデータの作成と管理
• データに関するルールの文書化
• データ品質の問題管理
• データガバナンス運営

活動

MDM、RDMの活動をデータのライフサイクルで説明します。

計画

マスターデータを計画するときには次のような活動があります。

• MDMの目的と要件の定義
  上記「MDMの目的」で説明したように、MDMによってどのよなビジネス課題が解決されるのか明確にします。
• データソースの評価と査定
  マスターデータの元となるデータの構造と内容、データが収集、作成され維持、活用されるプロセスを調査するとともに、データの品質（正確性、一意性、一貫性、適時性など）を評価します。
  データの内容を確認する場合、次の点を考慮します。
  • データの粒度
    上述した製品データのように、
    製品種類だけでなく製品の単体まで表すか
    製品種類はどのレベルまで表すか
    など、データの識別子や属性によって、その粒度を明確にします。
  • データの範囲
    例えば、製品データは自社製品のみか、他社製品も含むのかなど、データの範囲を明確にします。

  なお、データを評価する際、データのリネージュも明確するようにします。
  また、データを外部から調達できるかどうかも調査します。
  ※
  データリネージュ（Data lineage：データの系統）
  データの発生源から、データがどのシステムでどう加工されて来たかを示すデータの系統のことです。
  データリネージュを記録することで、データのトレーサビリティ（追跡可能性）を上げることができ、
  データ間の依存関係の可視化
  異常データの追跡（例えば、どのETL処理でデータ品質がどの程度落ちたかなど）
  ができるようになります。

• スチュワード制と保守プロセスの定義
• マスターデータを使用を強制するガバナンスポリシーの確立

設計・実装

マスターデータを設計・実装するときには次のような活動があります。

• アーキテクチャの設計・実装
  マスターデータのアーキテクチャの設計・実装します。
  ハブ＆スポークのデータ連携モデルを採用する場合、マスターデータハブを中心とした基本構造を設計し実装します。
  
  詳細は上記「アーキテクチャ」を参照してください。
• データモデルの定義
  マスターデータを統合して企業全体で一元管理していくためには、データ共有ハブの対象領域内の論理データモデルやカノニカルモデルを定義しメタデータとして管理する必要があります。
  それによって、対象領域のエンティティと属性の定義を全社レベルで確立することができます。
  データ構造を持つ参照データのデータモデルを作成し、管理することで、データ利用者が参照データセット内の関係を理解するのを助け、データ品質ルール確立のために使用することができます。
  なお、データモデルを定義するとき、データモデルのメタデータがデータカタログに登録されます。
  

生成・収集

データ統合ツール（上記参照）を利用して、マスターデータをELTかETLで取り込みます。
その際、データのリネージュがデータカタログに生成されます。

保存・維持

業務の流れの中でマスターデータが登録、維持されます。
マスターデータが登録されるとき、データの書式の調整やデータの重複の排除が行われデータが洗浄（クレンジング）されます。
マスターデータの管理者は、定期的に、データの重複を排除するためのマッチングアルゴリズムの精度を向上させるなど、マスターデータの品質の維持、向上に努めます。
なお、マスターデータが登録、変更される都度、データのリネージュがデータカタログに生成されます。

MDM、RDMに関するデータガバナンスの運営の活動には次のようなものがあります。

• MDMツールの運用・保守
  次のような活動があります。
  問合対応
  運用監視
  パフォーマンスチューニング
  バージョンアップ
  バックアップ
  障害対応
  ツールの機能改修・変更・追加
• マスターデータ品質維持
  誤マッチングの解消。
  エンティティの解決の精度向上（マッチングルール、アルゴリズムの見直しなど）。
• 参照データの変更管理
  参照データは共有リソースとして多くのアプリケーションで使用されているため勝手に変更できません。
  参照データを変更するときは、次のようなプロセスで行います。
  1. 変更要求の受付
  2. ステークホルダーの特定
  3. 影響範囲の特定
  4. 決定と通知
  5. 更新と公開
• システム開発者に対するマスタデータ・参照データの内容と活用方法に関する教育、技術支援、問合対応
• データサイエンティストに対するマスタデータ・参照データも含めたデータの理解、準備に関する教育、技術支援、問合対応

利活用

マスターデータは、業務活動の中で活用されます。
次の図は、業務活動で利用される製品マスターデータの例を示しています。

改善・強化

MDMでは、マスターデータを継続的に検証、標準化、強化する必要があります。

• データの検証
  データが間違っているか、欠落しているか特定し、間違っている場合は削除するなどの処置を行います。
• データの標準化
  標準的な参照データ値（国コードなど）、書式（電話番号、住所など）にデータ内容が一致することを保証します。
• データの強化
  エンティティを解決するために必要な属性（生成日時、更新日時など）を追加します。

エンティティの解決
複数のデータが同じ実体（エンティティ）を指すのか、異なる実体を指すのか判断します。
該当データを決定論的アルゴリズムや確率的アルゴリズムでマッチングします。
マッチング後、該当データをリンクするかマージします。
その際、

• 氏名、生年月日、マイナンバーが同じだが住所が異なる場合、住所を変更しただけで同一人物か
• 生年月日、住所、マイナンバーが同じだが姓が異なる場合、姓が変わっただけで同一人物か

などマッチングルールを決めます。
マッチングルールは定期的に再評価し信頼レベルを上げていきます。
マッチングの結果、間違いが判明する場合があるので、マッチングの履歴を保持し、元に戻せるようにします。
動画