[技術解説]

2008年11月27日(木)黒澤 基博（データ総研 代表取締役社長）

マスターデータ統合の目的は、複数の業務をまたがる広い視野で、管理対象に関する統一的な視点を提供することである。ここで言う広い視野とは、たとえば１つの企業全体あるいはグループ企業全体を指す。また、管理対象とはビジネス世界を構成する物事（「もの」と「こと」）であり、データとして捉える対象を意味する。

具体的な例を使って説明しよう。

図1は、通信業界における窓口業務担当者が見る画面イメージである。左上は、窓口を訪れた顧客が関係する契約情報を表示している。同様に、左下は請求情報、右上はコールセンターの応対履歴、右下はその契約が関係する通信設備の障害状況である。一般にこれらの情報は、通信契約管理システム、請求管理システム、コールセンター管理システム、設備状況監視システムなどに散在しているため、1つの画面に集約することが難しい。なぜならば、各業務システムは、顧客に対するデータとしての捉え方（意味的な粒度）や表現形式（コード体系）が異なっているためである。

このように複数の業務システムをまたがって顧客といった同一管理対象に関する情報をまとめるためには、各業務システムで扱うマスターデータ（顧客マスター）を標準化し統制する必要がある。多くの場合、これらのマスターデータを統制するためには、各業務システムから独立したマスターデータ管理システムを構築することになる。マスターデータの統合は、すでに存在する複数のテーブル・ファイルを1つに合体する抜本統合（既存のものは廃棄）と、論理的に統合する擬似統合（既存のものが残る）の2種類があるが、ここでは詳しく触れない。

マスターデータの統合が実現され、図1のような画面から統合された情報を照会できることにより、窓口業務担当者は顧客と同じ情報量を持つことになる。結果として、統合前と比較して、顧客満足度が格段に上がることになる。

マスターデータとは何か

業務システムのデータ設計とは、ビジネス世界の管理対象をデータとして捉える作業である。ビジネス世界の管理対象は２つの概念、「もの」と「こと」に大別されるが、「もの」にあたるデータがマスターデータである。「もの」に分類されるデータのほとんどが「名称」を持つ。顧客名・組織名・商品名・地域名などだ。逆に「こと」に分類されるデータは「名称」を持たない。たとえば、受注名・出荷名・請求名といったデータはない。また、別の見分け方として、「こと」に分類されるデータは「何々する」と表現できる。たとえば、「受注する」、「出荷する」、「請求する」などだ。逆に「もの」に分類されるデータは、「何々する」と表現できない。たとえば、「顧客する」、「商品する」などとは言わない。

「もの」であるマスターデータは、我々が普段使っている言語の構造に従って「Who」「Where」「What」「When」「その他」に分類できる。典型的なマスターデータを次に紹介する。

• Who（組織、社員、顧客、仕入先…）
• Where（在庫場所、拠点、地域…）
• What（製品、部材、部品構成表…）
• When（カレンダー…）
• その他（勘定科目、通貨、国、単位、契約、プライスリスト…）

ここで２つ注意すべきことがある。1つは、契約データの扱いだ。契約は、「何々する（契約する）」と表現できるため「こと」に分類されるデータである。したがって、先に示した分類法にしたがえば、マスターデータでないことになる。しかし、契約データもマスターデータに含めて考えるべきなのである。

契約は、契約時点に着目すれば確かに「こと」に分類される。しかし、その後数年、長い場合は何十年と、契約当事者はその契約に従ってビジネス的な取引を行うことになる。身近な例として、通信契約や住宅ローン契約を思い浮かべてほしい。契約時の取り決めに従って、毎月の通信利用料金や元利金の支払いが長期間発生する。契約が終了するまでの間、契約は契約当事者が従うべきルール・規則であり、ルール・規則は「もの」に分類されるべき管理対象なのである。

もう１つはプライスリスト（単価表）である。一般にプライスリストは、商品の単価表と思われがちだ。従って、Whatに分類されても良いことになる。しかし、昨今では、商品の渡し方・代金の支払い方法が多様化し、結果としてさまざまな要素で単価が決められるようになっている。プライスリストは商品データの仲間ではなく、契約データの仲間と捉えたほうが実態に合った捉え方なのだ。

概念データモデリング

マスターデータの統合とは、広い視野で管理対象を捉え、システムをまたがって利用する共通データを整理・統合することである。前述のような分類の観点によってマスターデータに分類されたからと言って、これがただちに統合対象になるわけではない。共通データか個別データかの区別が重要になる。そして共通データか個別データかを判断するためには、統合の目的を充分把握した上で、業務的な意味の異同を整理しなければならない。

たとえば、次のように取引先を表す管理対象（あるいはコード体系）が複数存在した場合、何を共通データとして認識し、どのように統合するのだろうか？

• 法人（法人コード）
• 法人組織（法人組織コード）
• 個人（個人コード）
• 顧客（顧客コード）
• 受注先（受注先コード）
• 出荷先（出荷先コード）
• 請求先（請求先コード）
• 物流拠点（物流拠点コード）
• 生産委託先（生産委託先コード）
• 仕入先（仕入先コード）

我々データ設計者は、管理対象の業務的な意味の異同を明らかにするために、概念データモデルを使う（図2）。

図の左は、我々が普段仕事をしているビジネス世界をイメージしている。我々は、取引先、社員、出荷といった管理対象を直接的に認識している。図の中央が、概念データモデルの世界である。実世界の管理対象をデータとして表現しており、ボックスをエンティティという。エンティティは1件1件を識別するための識別子を持つ。識別子は、取引先コード、社員コード、出荷番号といったコードによる表現形式を持つが、実装環境を意識したものではない。図の右は、エンティティを実装したファイルを表す。

マスターデータの設計では、第1ステップとして概念データモデルを作成し、エンティティを明らかにする。第2ステップとしてエンティティをリレーショナルデータベースのテーブルやXMLのタグとして実装する。