さあ読もう『百年の孤独』、始めよう新メタデータマネジメント(後編）

プロトキン氏著『データスチュワードシップ　～データマネジメント＆データガバナンスの実践ガイド～』から

ここでは本書の紹介を兼ねてデータスチュワードシップ実現のためにメタデータマネジメントの観点からその特徴を述べる。

人材配置と体制

本書では細かくデータスチュワードの種類と役割が述べられ、ビジネスデータスチュワードは次のように書かれている。

ビジネスデータスチュワードとは特定のビジネス領域における鍵となる代表者であり、その組織におけるデータの品質、使用、意味について責任を負う。

ビジネスデータスチュワードは通常、データをよく知り、データと密接に関わっている人である。「データアナリスト」や「ビジネスアナリスト」といった肩書きを持つ人が、ビジネスデータスチュワードに適していることが多い。
『データスチュワードシップ　データマネジメント＆データガバナンスの実践ガイド』「Chapter2　データスチュワードシップのタイプについて（P42）」より引用

本書ではそれほど大きくない企業でも、ビジネスデータスチュワードは数十人いるとあり、参画対象の多さに驚いている。彼らは通常の業務を抱えながら兼任で参加し、スチュワードシップに費やす時間は2割以下だと書かれている。このことはデータスチュワードシップを導入しデータ品質改善を実現するためには、多くのデータスチュワードが持つデータ品質に関わるナレッジを企業全体で共有し、実際にビジネスの現場でそれを活かすことが必須であるということだろう。

ビジネスデータエレメント(BDE)とは

前編で述べたように、DMBOKにおけるデータスチュワードシップのアクティビティを見ると、物理データエレメントに対するデータの有効値（値ドメイン)、ビジネスルール、データ品質ルールなどの定義が、その中心であることが分かる。
ここで新たにBDEと言う実装独立の概念的なものが必要となる。DMBOKではこの用語はないが、ビジネスメタデータの主要構成要素に含まれているものが考えられる。
ISO 11179との比較で言えば、BDEは値ドメインよりも粒度が細かく、エンティティの属性に近いものと考えられる。すなわちビジネスの中でデータを生成したり利用する上で、ビジネス部門がそのデータについて最低限熟知していなければならない決め事(共有知)を定義したものと言える。

例えば、保険会社における顧客の婚姻ステータスコード(BDE)のデータ品質ルールでは以下のように定義している。

ビジネスデータ品質ルール：婚姻ステータスコード（Marital Status Code）は独身（Single）、既婚（Married）、死別（Widowed）、離婚（Divorced）の値を持つことができる。空白のままにすることはできない。新規顧客の入力時に値を選択する必要がある。顧客がかつて結婚していたか、現在結婚していないかどうかにリスク要因が影響されるため、死別と離婚の値は独身とは別に記録される。

データ品質ルール仕様：顧客（Customer）テーブルの婚姻ステータスコードのカラムには「S」、「M」、「W」、または「D」を指定できる。空白は無効な値とみなされる。
『データスチュワードシップ　データマネジメント＆データガバナンスの実践ガイド』「Chapter7　データスチュワードの重要な役割（P168）」より引用

同じく、従業員の婚姻ステータスコードに対して以下のように定義している。

ビジネスデータ品質ルール：婚姻ステータスコードは独身（Single）と既婚（Married）の値を持つことができる。空白のままにすることはできない。新しい従業員を登録する際には必ず値を選択する必要がある。選択された福利厚生の確認として必要なのは、独身であるか既婚であるかだけである。

データ品質ルール仕様：従業員デモグラフィック（EmployeeDemographics）テーブルの婚姻コードのカラムには「Sng」または「Mrd」を指定できる。空白は無効な値とみなされる。
『データスチュワードシップ　データマネジメント＆データガバナンスの実践ガイド』「Chapter7　データスチュワードの重要な役割（P168）」より引用

これらを眺めると、上記のような列挙型ドメインについては、ビジネスデータ品質ルールの定義内容は物理特性（データ型や桁数）を除いた値ドメインに近いと考えられる。このことからデータ品質ルールを管理する粒度はBDEそのものとは異なり、本来であれば別物として扱うべきであろう。
また、データ品質ルール仕様は該当の物理テーブルの元となるエンティティ（例えば、顧客や従業員）の属性側で、物理データエレメント(PDE)が満たすべき仕様(制約条件)を定義している。このことからもBDEとは該当テーブル等のPDEに対応するエンティティの属性に相当すると考えられる。

BDE中心のメタデータマネジメント

本書の中でメタモデルは概要が表現されていて、残念ながら厳密な全体像は述べられていない。下図のメタモデル上の点線エンティティは私が想定で補ったものである。このメタモデルの大きな特徴はビジネスデータ層のデータガバナンスを厚くして、物理データ層のデータ品質を統制することである。

この概要メタモデルから以下のことが分かる。

PDEに一つのBDEを割り当て、そのBDEで物理データエレメントの生成や利用上のビジネスルールやデータ品質ルールなどを定義する。また法規制やリスクマネジメントなどの情報もBDEに紐づけている。
特にビジネス上重要なBDEをキービジネスエレメント（KBE）呼び、重点指向のデータガバナンスを目指す。
BDEを論理的なグループにまとめ、分割統治するために1つのデータドメイン（データ統治領域）を割り当てる。また、データドメインは階層を持たせることで柔軟に粒度を設定できる。
データドメイン毎にビジネス部門から任命されたビジネスデータスチュワードを割り当て、データスチュワードで構成されるデータドメイン評議会（複数）を設置する。

著者は本書の中や講演で、従来行ってきたビジネス機能主導よりもデータドメイン主導のデータスチュワードシップがいかに優れているかを強調している。このこと自体は大いに納得できる。ただし、残念ながらデータドメインの中身であるBDEについてその理論的背景に殆ど言及していない。私は長い実践経験からデータエレメントの意味や制約をいかに定義し管理するかがメタデータマネジメントの肝であると強く考えている。本書に則して言えば、その中核となるBDEでいかに対応するPDEの意味や制約を管理するかがポイントとなるが、BDEそのものをどう作成し定義するかをもっと明確にする必要があるだろう。

BDEの粒度

このような概念的なBDEを定義する場合、必ず発生する課題がその粒度をどうするかである。本書では次のように述べている。

BDE の意味や導出方法について強い意見の相違がある場合、2つの主張するグループが実際には異なるBDEについて話している可能性がある。これはBDE の名称が「金融取引」のように一般的すぎる場合によく発生し、より具体的な「未遂金融取引」や「正常完了金融取引」などのようにすることで解決できる
『データスチュワードシップ　データマネジメント＆データガバナンスの実践ガイド』「Chapter6　実践的データスチュワードシップ（P117）」より引用

すなわち、本来重要な利用上の差異がある場合は、その差異を明示する粒度でBDEを定義することになる。

なお、先のBDEの定義でBDEはエンティティの属性に近いものとしたが、この例にある「XX金融取引」はビジネス上のイベント名（ビジネス用語）であり、エンティティ金融取引のサブタイプと考えられ、属性そのものとはかけ離れている。本来、属性として定義するのであれば、「XX金融取引件数」や「XX金融取引金額」などとなるが、便宜的にそれらをまとめた「XX金融取引」としていると考えられる。この辺は今後BDEそのものの概念を整理する必要がありそうだ。

このように物理データエレメントが持つ制約をBDEで管理しようとする試みはチャレンジングであり、特に非列挙型の場合はその組織独自の視点で必要な粒度でBDEを定義する必要がある。
すなわち、BDEとは、ビジネス部門がデータガバナンスを実現するために、適切な粒度で適切なエンティティの属性やビジネス用語を定義したものである。調べるとBDEはテラデータの統合DWHのLDM（論理データモデル）で使われ始めたことが分かる。

キービジネスエレメント（KBE）の選択

ほとんどの企業では何千ものBDE、そしてそれ以上の物理データエレメントがあるため、最初にすべきは焦点を当てる最も重要な（キーとなる）ビジネスエレメント（KBE）を定めることである。BDE をガバナンス下に置くための作業を「投資」と考えれば、その投資のリターンで KBE を決定するのが合理的である
『データスチュワードシップ　データマネジメント＆データガバナンスの実践ガイド』「Chapter6　実践的データスチュワードシップ（P114）」より引用

BDEの中で特に重要なものをKBEと呼んで次のような例を挙げている。実際にデータスチュワードシップを立ち上げる際には、このような領域から始めるのが現実的だろう。

財務報告用データ
リスクと規制報告用データエレメント
企業幹部が紹介するビジネスデータエレメント
注目度の高いプロジェクトで使用されるデータ

このように企業独自に重点指向でKBEを決めてデータガバナンスを始められることは大きなメリットであろう。
また、このことがISO 11179 の適用と大きく異なる点である。

データドメインの例

ビジネスサブジェクトエリアの一覧を収集することは優れた出発点となる。これらのサブジェクトエリアのデータを反映させたデータドメインが必要になるためである。
『データスチュワードシップ　データマネジメント＆データガバナンスの実践ガイド』「Chapter11　データドメインを使用したデータのガバナンスとスチュワード（P249）」より引用

すなわち、データドメインとは、多くのBDEをビジネスデータスチュワードが統治し易いようにグループ化したものであり、データの独立性を担保するサブジェクトエリアに似たものとなる。
ビジネス機能や組織構成そのものに合わせるものではないことがポイントである。
例えば、金融系のトランザクションデータドメインとして、預金、クレジットカード、住宅ローン、自動車ローンなど、リファレンスデータドメインとして、パーティ、商品、組織階層、従業員などを挙げている。

また、プロトキン氏はある大手銀行の例として、30ほどのデータドメインを定義し、その内半分はリスクマネジメントに関するデータドメインだったとも講演で述べている。このことは企業が重点的にガバナンスしたいデータ領域については、より細かくデータドメインを設定しデータ品質改善をし易くできるということである。さらに、例えば以下の左図のようにデータドメインが商品別に分かれていても、債権回収のような他の商品にも共通する機能は別データドメインとして切り出す方法もあると述べている。確かに、BDEが共通するものを一つにまとめることで、データ品質を維持し易くなるだろう。