Octo Knot(オクトノット)｜顧客データ統合を円滑に進めるために、概念データモデルが役立つ

金融機関における顧客データ統合ニーズの高まり

金融機関におけるデータ活用の動きは、今後ますます加速していくと思われます。データ総研も、金融機関のお客様からデータ活用、あるいは、それに向けたデータ統合のご相談を受けることがあります。

その中で、顧客データの統合は大きなテーマです。大規模な金融機関では、同グループ内で銀行、証券、信託、クレジットカード、リース…など、複数の事業を展開しています。もし、同一顧客との接点・取引実績を事業横断で見ることができれば、顧客の中で新たに立ち上がったニーズをいち早く察知し、顧客ごとに最適なプランを提案できる可能性が広がります。また、同一顧客の取引の可視化は、与信管理のようなリスク管理方面でも役立つでしょう。

一方で、こうした顧客データは各事業で分散管理され、対応付けできていないことがあります。事業によっては、支店ごとで顧客データが分散していることもあります。これらの分散した顧客データを統合する動きが、弊社にご相談頂いているケースの他にも、多くの金融機関で出ていることでしょう。

顧客データ統合時の意外な障壁

図1. コミュニケーションがうまくいかないイメージ図

データ統合を成し遂げるまでに、様々なことを検討する必要があります。例えば、「どのデータを、どの範囲で統合しようか」「どのようなシステムアーキテクチャにするか」「既存データと統合データの対応付けはどうやって行うか」「データ統合後のメンテナンスはどういう体制で行うか」…など、決めるべきことは山積みです。

そのうえ、データ統合は業務・事業を横断した活動です。多くの社内関係者とコミュニケーションを取りながら、議論・調整を繰り返し、時にベンダー・コンサルなど外部の力を借りながら、検討を進めることになります。

関係者とのコミュニケーションが重要な中、よく障壁となるのが「社内用語に対する認識が合わない」ということです。社内用語に対する認識が違うまま、それに気付かずになんとなく調査や検討がすすんでいき、後になって食い違いが大きくなっていくことがあります。
金融機関で顧客データを統合する場合でいうと、以下のような要素が絡み合って、認識をややこしくしていきます。

・各事業で、保持している粒度がバラバラである。例えば、銀行では支店をまたいだ銀行全体で顧客データを保持しているが、信託では支店ごとでしか保持していない。
・顧客属性や金融商品、地域（日本、アジア、北米など）によって顧客データ管理のやり方が異なる。例えば、法人顧客と個人顧客で顧客データの粒度や、採番しているコードの体系が異なる。
・顧客データ管理のやり方が異なっていても、使われる言葉は似ている。「CIF」「顧客」「取引先」など似たような言葉が、部署や事業ごとにそれぞれの意味で使われており、混同するおそれがある。
・同じ事業内でも、一つの言葉が複数の意味を持っており、文脈によって区別する必要がある。例えば、正式には「CIF」「MCIF」などの正式名称があっても、従業員は特に区別せず「CIF」と呼んでいる。

…など

関係者がしっかりと上記を意識して、「今は銀行の、支店ごとのCIFの話をしているんだな」「これから、信託の法人顧客の話をする」というように適宜確認しながら進めていければいいのですが、なかなかそうはいきません。注意していないと、証券の現行データについて話したかったのに、信託にある同名のデータについて延々と話していた…。という事態にもなりかねません。一回一回の認識のズレは小さくとも、それが積み重なっていくことで顧客データの要件・それを使用した集計データの要件、統合に向けた課題認識などに大きなズレが生じるおそれがあります。

データの地図があると、コミュニケーションしやすい

図2. 概念データモデルの例

用語の認識のズレを小さくするために、データ統合の企画の早い段階で概念データモデルを作ることをお勧めします。

道で迷ったときには地図を見て、現在地を確認するでしょう。合わせて、目的地までの道にある建物や目印を確認すると思います。同じように、データに関する議論のときに概念データモデルがあると、「今どのデータについて話しているのか」「他にどんなデータがあるのか」を俯瞰的な目線から見ることができるようになります。

一般的に概念データモデルというと、エンティティ（「顧客」「商品」など、企業活動のためにデータを管理したい対象を、管理目的に応じてグループ分けしたもの）同士の関係性をリレーションシップで表現したものを指すことが多いです。ただし、初期の段階ではリレーションシップについては考えず、いくつか領域を区切った中にエンティティを配置する程度で良いでしょう。

図2のような形で、検討範囲にどのようなデータが関わっているのかを一目で見ることができるようにしておくと、以下のようなメリットがあります。

・これからの議論で、どんなデータが出てくるのかあらかじめ把握することができる
・意識しなければ同じデータとして扱ってしまいそうな、異なるデータの存在に気付ける
・議論の中で用語のズレが出てきた／出てきそうな場合に、概念データモデルを使って再確認できる

議論の過程で、「このデータは、このデータを集約してできたものである」「このデータは、このデータの部分集合である」というような関係性を記載したくなった時には、適宜リレーションシップを追加していくのがよいかと思います。

図3. エンティティ、リレーションシップの説明

では、実際に図2のようなレベルで、顧客に関して、概念データモデルを作ってみましょう。
①まずは事業ごとに枠を作り、水平に配置します。今回は、例として「銀行」「ネット証券」「信託」の顧客を統合する想定で描いてみましょう。その上に、「全社」という枠を作ります。

②それぞれの枠の中に、現状各事業で存在している「顧客」に関わるデータ、これから全社的に作りたいデータを箱で描きます。（この箱がエンティティ）
この時に意識してほしいのは、「主キーの違い」「粒度の違い」です。

図4. 主キー、粒度の違いをもとにしたエンティティ抽出・配置

・主キーの違い
主キーとは、同じエンティティに属する管理対象1件1件（=エンティティオカレンス）を識別できるデータ項目のことです。例えば「顧客」というエンティティがあったとして、「株式会社〇×商事」「株式会社××工業」などの具体的な顧客1件1件を識別できるように「顧客番号」なる番号が採番されていたとします。その場合、顧客エンティティの主キーは顧客番号ということになります。

主キーとなる項目が異なるものは、異なるエンティティとして描きましょう。例えば、銀行で「顧客」1件を特定するための番号を確認した時に、「店番号とCIF番号の組み合わせ」「MCIF番号」など、複数の答えが返ってくるときがあります。この時、この2つはエンティティを分けましょう。その他、同じ事業内でも顧客属性や商材、地域などで異なるデータ項目を使って顧客を特定している場合は、エンティティを分けましょう。

・粒度の違い
主キーの採番粒度を確認し、モデルに反映します。
粒度が同じエンティティの高さを揃えましょう。また、粒度が細かいエンティティは、粒度が粗いエンティティより下に配置するようにしましょう。また、主キーが同じエンティティの中に、粒度が異なるエンティティオカレンスがある場合は、必要に応じてエンティティを分けましょう。（後述するサブタイプを使うとよいです。）

銀行の法人顧客を例に考えてみます。銀行の口座の名義は、部署ごと、プロジェクトごとなど様々な単位（顧客である企業が口座を作りたい単位）で作られます。各支店でCIFを発行しているとして、名義単位でCIFが採番されているのか、それとも、法人単位でCIFが採番されているのか、確認しましょう。また仮に、店ごとに発行されているCIFを国内の銀行全体で集約した「MCIF」という単位があったとします。CIFが事業所単位だった場合、MCIFも事業所単位でしょうか？それとも、法人単位にまとめているのでしょうか？このように、主キーの特定だけでなく、主キーが業務上どの単位で採番されているのかを確認するようにしましょう。

同じようなエンティティ名がたくさん出てきてややこしい、というような時もあるかもしれません。あるいは、人によって、同じエンティティに対する呼び方が異なる場合もあります。その時は、プロジェクト内のみで使用する標準的な名称をつけ、モデルに記載するのも有効です。

③リレーションシップの追加
もし必要があれば、エンティティの間にリレーションシップをつけることで、関係性がわかるようにしましょう。参考までに、データ総研で使用している記法を紹介します。

図5. リレーションシップの種類

図6. ヒアリング内容をもとにしたリレーションシップの反映

・1：多（↓）
矢線の根元側のエンティティ：先側のエンティティ=1：多の関係を表す。
すなわち、根元側のエンティティオカレンス1件に対して、対応するエンティティオカレンスが複数件ある。例えば、銀行で「CIF」「MCIF」という単位があったとして、CIFのエンティティオカレンス複数件をまとめて1件のMCIFのエンティティオカレンスを作っている場合は、MCIF：CIF=1：多となる。

・サブタイプ（￢）
全体集合と部分集合の関係を表す。（個々のエンティティオカレンスどうしは1：1対応する）
サブタイプで繋がれたエンティティ主キーの主キーは同じになる。
全体集合側のエンティティの横辺と部分集合側のエンティティの上辺をカギ線で繋ぐ。

・サブストラクチャ（―）
管理者の違いや状態遷移を表す。（個々のエンティティオカレンスどうしは１：１対応する。サブタイプと異なりエンティティオカレンスの数は同じになる）
エンティティどうしを横線で繋ぐ。

概念データモデルの描き方については以上です。

図2では顧客についてモデルを描きましたが、実際のプロジェクトでは、顧客以外のデータ（地域や商品・サービスなど）も合わせて検討するかもしれません。その場合は、適宜必要なエンティティをモデルに追加していくとよいです。

これらを軸にして集計データを作りたい場合もあると思います。まずは、どのような集計粒度でデータを作成したいのか考えましょう（例：法人顧客は、法人ごとの数字に加えて、グループ企業ごとの数字を見たい、など）。そのうえで概念データモデルを見ながら、今自社にあるデータ／これから統合して作るデータの粒度でそれが実現できるのかを確認していきましょう。

おわりに

最後までお読みいただきありがとうございます。今回紹介したデータモデルを活かして、データ統合プロジェクトを円滑に進めて頂ければ幸いです。

データモデリングは、データマネジメントを行う上で、データの現状や、データの将来像、それにまつわる課題を整理するために非常に有用な技術です。データモデルをチームの共通言語としていくことで、データに関するコミュニケーションがスムーズになります。

データ総研では、データモデルの描き方に関する研修や、OJTも行っております。何かお困りのことがあれば、気軽にご相談ください。

【この記事を書いた方】

芳賀恒太（ハガコウタ）さん
株式会社データ総研　コンサルティンググループ所属

京都大学理学部卒業、同大学大学院理学研究科修士課程修了後、広告代理店を経由し、2019年にデータ総研に入社。入社後、金融系企業のMDM・DWH構築プロジェクト、不動産系企業の基幹システム構築プロジェクトを支援。

株式会社データ総研

＜参考＞