PART2 マスターデータをどう捉えるべきか

マスターデータとはそもそも何なのか？マスターデータの種類を明らかにするともに、典型的なマスターデータに関して、その特徴と概念データモデリングの重要性、設計ポイントを解説する。（本誌）

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

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

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

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

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

マスターデータとは何か

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

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

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

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

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

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

概念データモデリング

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

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

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

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

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

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

具体的なマスターデータ設計ノウハウ

筆者は20年以上マスターデータの統合に携わっているが、近年特にその難易度が増している。最大の理由は、統合対象が連結企業まで含む広範囲になったことである。管理の視点が広くなったことにより、エンティティの位置づけが変化するのである。

社員マスターデータの統合を考えてみよう。連結企業における人材管理を効率化するために、連結企業全体の社員データを統合し、適材適所の人事を行うケースである。社員データの性質を端的に表現しているデータ項目は、社員エンティティの識別子である社員コードである。1つの企業に閉じて考えれば、社員コードは社員という人を識別している。しかし、連結企業の範囲になるとそうではなくなる（図3）。

同じ鈴木一郎さんを識別するためにA社は社員コード（6桁）、B社は社員番号（8桁）、C社は社員コード（5桁）を使っている。3社とも同じ連結企業にグルーピングされるとすれば、連結企業全体で鈴木一郎さんを識別するためには別のコードが必要になる。図3では、個人コードを識別子とした個人エンティティを設定した。これを概念データモデルにすると図4になる。

従来から存在する３つの社員エンティティは、雇用契約エンティティに対応するものとした。個人に従属するデータ項目（氏名、住所…）は個人エンティティに、会社と個人との関係で決まるデータ項目（役職コード、基本給…）は雇用契約エンティティに、それぞれ持つことになる。

このように管理の視点が広がると、社員エンティティは単なる社員を表現したものという概念ではなく、個人と雇用契約という2つの概念として再認識しなければならなくなる。

次にデータ設計の例を紹介しよう。これは、通信業や金融業のCRM（顧客関係管理）を想定した例である。CRMにおけるデータ設計のポイントは、それまでの契約中心のデータ構造から顧客中心のデータ構造に変化させることである（図5）。

図5の左では、契約を識別するために通信契約番号や預金口座番号・住宅ローン契約番号を使っていた。顧客については識別子がなく、契約エンティティに含まれる契約者の氏名を見て、同じ取引先かどうかを判断するしかなかった。これを図5の右のように、顧客エンティティを設定し、各契約の上位概念として顧客マスターを設け、顧客コードを各契約エンティティに持たせるのである。この結果、1人の個人顧客、1つの法人顧客に関する複数の契約をまとめられるようになる。

ここで、粒度とは企業グループ、企業、組織、人といったエンティティの粗さ、細かさを指す。一般に取引先は組織の粒度で統一する。ロールは、各イベントエンティティのなかでマスターデータが演じる役割である。たとえば、取引先は、仕入イベントの中では仕入先、出荷イベントの中では出荷先、請求イベントの中では請求先といった役割を演じる。取引先を統合するためには、粒度とロールに着目して既存のエンティティを整理する必要がある。

最後に、マスターデータ統合の心得を、7つ紹介する。

1. アセスメントを実施すべし

マスターデータの統合は作業量が膨大になることが多いため、最初にマスターデータアセスメントを実施し、目的に応じた内容に絞ることをお勧めする。統合されることが理想だと考え、むやみに統合しようとして、失敗するプロジェクトが後を絶たない。

2. 統合前に意味の整理を！

マスターデータの統合は、数多くのエンティティにおける粒度とロールの整理である。概念データモデルを使った意味の異同に敏感な技術者だけが成功を収める。

3. 識別子を使ってエンティティを見抜くべし

エンティティの意味は、識別子に頼って見極める。識別子の発番範囲や発番単位がエンティティの粒度を決めている。その意味では、「マスター統合とはコード統一である」と言っても過言ではない。識別子に頼らず自然言語に頼った会話になると、ミスコミュニケーションが発生する。

4. 共通データが統合対象だが個別データも尊重すべし

複数業務にまたがる共通データが統合の対象になるわけだが、共通化することに意識が向かいすぎると、個別データの自由度を確保することがおろそかになる。企業の競争優位を維持するような特徴のあるデータ構造が、共通化の名の下に壊されないように注意すべきである。

5. 原則として「関係」は共通マスターに持ち込まない

エンティティとエンティティの「関係」は、なるべく統一マスターに持ち込まない。「関係」は、たとえば「出荷先を指定すると請求先が決まる」といったビジネスルールを表現していることが多く、業務個別である場合が多い。

6. 落とし穴は技術課題よりもマネジメント課題に多く存在する

マスターデータの統合は、一種の標準化活動である。標準化活動の多くの失敗は、技術的な難しさよりもマネジメント的な難しさが原因のことが多い。日ごろのITガバナンスの実力が、マスターデータの統合で試されていると知るべきである。

7. 長期戦を覚悟すべし

マスターデータの統合は長期戦になる。筆者の支援先でも段階的に８年かかった例もある。段階的シナリオを重視し、すぐにあきらめないことが肝要だ。データ基盤づくりはそれなりの時間と体制が必要だと覚悟すべきである。