前回は、データ定義を統合的に管理する辞書（リポジトリ）をつくり、育てていくことの必要性を述べた。
今回はその進め方・アプローチについて述べたい。
■ メタデータ管理の進め方：DMBOKの記載
DMBOK2には次のような記載がある
「多くの場合、メタデータ管理がデータマネジメント全体を改善する出発点となる。」（DMBOK2 1章 2.5.5項）
メタデータ管理は「出発点」という性格を持つがゆえ、どこから着手し、どのレベルを目指すべきか、に迷うことが多い。
また残念ながらDMBOKには、他のBody Of Knowlegde本と同様、「何をすべきか」は書いてあるものの、「どうやるか」は具体的にはあまり書かれていない。
12章 メタデータ管理の2項には、
(メタデータに関する) 戦略の策定 → 要件の把握 → アーキテクチャの定義 → 作成と維持 → クエリ・レポート・分析
という枠組みのみが示されている。
要は、要件に応じてメタデータを管理する仕組み（アーキテクチャ）を作り、そこにメタデータを入れ、維持しましょう、という至極当然の記載でしかない。
結局、データマネジメントやメタデータ管理のような活動には、このタスクを順に進めさえすれば良い、という王道は存在しないともいえる。個々の企業の目的や課題、成熟度を考慮しつつ、自らが進め方を決めていくしかないのではと思う
但しその進め方を決めるための観点は幾つか存在する。ここではその観点を挙げてみるとしよう。
■観点１：業務用語から攻めるか システム項目から攻めるか
業務用語から攻めるというのは、例えば業務ドメインのエキスパートをアサインし、業務用語集の整理・作成から始めるような方式である。
システム項目から攻めるというのは、例えばDB定義やIF定義からデータ項目を収集し、その項目定義を進める方式である。
当然のことながら、どちらかが常に優れているわけではなく、ある程度の比率で両方やるべきである。が、どちらに力を入れるかは各企業の状況による。
＝ 業務用語から攻める場合 ＝
この場合、業務エキスパートに用語集を作成した上で、仕組みとしては一般的にはポータルサイトのような多数メンバが容易にアクセスできる場所にそれを公開していく。
この方式の利点は、なんといっても業務のドメインエキスパートの主体的な参画とその知見が得られることである。またナレッジマネジメント・知識の共有という別の効果も得ることができる。
留意点としては、業務エキスパート側だけにまかせておくと、どこまでの情報を対象にし・どのような記載とすべきかという点が迷走してしまうことが多い。
例を挙げておこう。
「配送先地区コード： 配送業務の観点で、都道府県を複数の地区ごとに分類したコード。例：東京城南地区）
このようなデータ項目名とその定義情報は有用である。
しかしながら
「東京城南地区： XX区とYY区とXX区の一部を含む。配送作業における注意点として、、、」
これは値そのものであり、メタデータ管理的には不要である。また付随する業務ノウハウの記述も残念ながら不要である。
業務エキスパートに対し、メタデータ管理的に何が必要／何が不要という基準を伝え、誘導するのは難しい場合も多い。
業務ノウハウの記述も、ナレッジ共有という目的に対しては有益な場合もあり、それも明確な一線を引くことの難易度を上げる。
対応策としては、先に結論めいた話になってしまうが、ある程度 システム項目の整備を先行させた上で、業務用語集側にどのような項目を記載して欲しいかを提示する、対応がとれるものは業務用語とシステム項目とのマッピングを管理していく、という方式がよいと筆者は考えている。
ある程度システム項目に軸足をおくことで、業務用語集をメタデータ管理の目的に沿ったものに誘導することが出来るのである。
＝ システム項目から攻める場合 ＝
この場合、多くのケースでは既存のDBのテーブル・IFファイルや設計書、モデリングツール等からデータ項目情報を抽出・とりまとめ、データ項目の定義を整理していく。
抽出は手動で実施することもあれば、ツールを導入し半自動的に集約をかける仕組みを構築する場合もある。
この方式の利点は、ある程度までは機械的に進めることができることである。
散財しているデータ定義を一か所に集めて整理する、これだけでも十分に価値を生む成果物ではあり、データ活用・分析対象のデータを探すための手がかりとして利用できる。
留意点は多数あり、以下のような点が挙げられる。
・物理データ項目の意味判別
物理的なデータ項目を、意味を持つ論理的な項目（とその定義）に紐づけていく必要がある。
設計資料にデータ定義が丁寧に書かれている場合はよいが、そうでない場合はデータの値や画面表示のラベルを手掛かりにするなど、定義情報の獲得に苦労することが多い。
また基本的にシステムは、ある限られた領域の業務を満足するために作られているため、領域をまたがってユニークとなるように項目定義がされていることは稀である。「注文日」という項目は販売管理システムであれば受注の日付であろうし、調達管理であれば発注の日付であろう、がそのようなコンテキストは省略された項目名になっていることが多い。
・スコープの絞り込み
基本的に収集するデータ項目数はかなり多量になるため。対象の絞り込みが必要となる。どのように絞り込むかについても方針が必要となってくる。
これらはメタデータ管理そのものの課題でもあり、対応策については次回以降に述べるとしよう。
（次回に続く）
コメント