ナレッジグラフの事例紹介：Citigroup社における人口統計マスターデータの活用　 #Neo4j #ナレッジグラフ #金融業

本投稿は Neo4j 社の事例であり、「Demographics Master Data at Citigroup」の日本語翻訳です。この記事は、2018年9月に開催されたGraph Connect New YorkでWalter Trotta氏が行ったプレゼンテーションを元に構成されています。

Citigroup社における人口統計マスターデータの活用

プレゼンテーションサマリー

Walter Trotta氏は、Citi Private Bank社でデータサービス担当グローバル責任者を務めています。

このプレゼンテーションでTrotta氏は、プライベートバンキング業界に関していくつかの背景情報を設定しており、一定レベルの資産を保有する個人を対象にさまざまな種類の金融サービスを提供する業種として、プライベートバンキングを位置付けています。個人の所有する資産の額が大きいほど、その個人を取り巻く状況は複雑になります。これは個人と銀行との関係にも及びます。

Trotta氏は、データドメインについていくつかの話題を提供しています。データドメインは、高い階層でグラフに組み込まれるものです。データドメインは、「パーティエンティティ」とも表現できます。パーティエンティティとしては、対象として情報の保持および整理が必要な個人や組織、組織グループなどが知られています。この情報は、マスターデータシステムに保存されます。

Trotta氏は次にCitigroup社が解決に取り組んでいる問題に言及し、同社がたどり着いたソリューションでグラフが果たす役割を説明しています。単一の顧客に対応する場合でも、配偶者や子供、孫、弁護士、会計士、ファミリーオフィスなどのような、さまざまな登場人物がさまざまなレベルでその顧客に関係して登場してきます。どの関係においても、その影響は一定ではありません。この情報を把握するには、グラフ構造を利用するのが一番です。

そして最後にTrotta氏は、彼と彼が率いるチームがプロジェクトを通じて学んだ事柄のいくつかを明らかにしています。そこでは、データに関する課題やデータガバナンスなどが話題になっています。データガバナンスでは、グラフ構造の扱いに微妙な違いが生じています。従来の前提を見直し、考え方を完全に改める必要がありました。

また、このプレゼンテーションでは、グラフテクノロジーのNeo4jがCitigroup社にもたらした将来の可能性についても説明されています。データは新しい石油であり、グラフを活用すれば、価値をもたらすデータを特定できます。

▽ プレゼンテーションの全内容
▽ プライベートバンキング
▽ データドメイン
▽ Citigroup社における課題
▽ ソリューション
▽ データに関する課題
▽ データのガバナンス
▽ まとめ

プレゼンテーションの全内容

Walter Trottaと申します。Citi Private Bankで運用とテクノロジーのデータレポーティングおよびアナリティクスの責任者を務めています。本日は、人口統計のマスターデータに関して本年に弊社が取り組んできたいくつかのプロジェクトをご紹介いたします。

プライベートバンキング

この業界に携わっていない皆様のために、プライベートバンキングについて少しご説明させていただきます。

プライベートバンキングとは、一定レベルの資産を保有する個人を対象にさまざまな種類の金融サービスを提供する業種です。保有する資産の規模が数十万ドル規模の顧客はマスアフルエント（大衆富裕層）と呼ばれ、保有する資産が数千万ドルから数十億になる顧客は超富裕層と呼ばれています。

この定義は業界全体で完全に共通であるため、これらの言葉はどのプライベートバンクでもまったく同じ意味で使用されています。そしてそれぞれの銀行は特定のセグメントや特定の分野に特化して事業を行う傾向があります。

一方で、プライベートバンキングには、一貫しているテーマもあります。それは、個人が所有する資産の額に応じて、その個人を表現する要素、その個人と銀行との関係性、その個人の行動も複雑になる傾向があるということです。

顧客が資産を運用する場所や運用する資産の種類などが多岐にわたるようになるのです。そしてその結果、法規制への関心が大きく高まるようになります。

一方で、顧客自身を表す要素や、顧客と銀行との関係も著しく複雑になります。

弊社が取引している資産の種類を少し詳しく見てみると、基本的な小口の当座預金や、サブスクリプション、緻密に構成されたヘッジファンド、その他の代替投資などがあり、企業やスポーツチームへの融資や、不動産投資などが行われています。

このような多岐にわたる取引を、弊社はグローバルレベルで行っており、顧客の動向に合わせ、複数のロケーションでサービスを提供しています。この結果、どの顧客を表す要素もきわめて複雑なものになります。

取引の額の点で弊社の業務はリテールバンクや投資銀行のそれとは異なります。弊社の顧客はもっと小規模な個人のグループです。それゆえ、弊社でのテクノロジーの利用で注目すべきは、エクイティ環境で目にするようなフロービジネスを対象にしたものではなく、顧客に関係して発生するきわめて複雑な問題の解決に向けたものになります。

データドメイン

データドメインについてご説明します。これは、パーティエンティティについてお話しすることにほかなりません。従来のデータモデルやデータガバナンスでは、エンティティという概念で話を進めるところですが、今回は、パーティという言葉を使います。パーティとしては、対象として情報の保持が必要な個人や組織、組織グループなどが知られています。

この情報は、マスターデータシステムに保存されます。弊社では、顧客、従業員、トラストエンティティ、企業などに関係する情報を保管しており、より具体的には、それは、パーティのデータとそのパーティを取り巻く付随データを守る本人確認（KYC）関連の情報になります。これらの情報はマスターデータシステムに集約され、下流のすべてのユーザーやアプリケーション、エンドユーザーなどに配布されます。

プライベートバンクには傾向として、上流の情報ソースが数多く存在します。証券保管機関や、顧客に代わって資産を扱う部門にある、外部の参照データソースやシステムなどがこれに該当します。複数のソースに起因するこれらの情報は、事業を行う上で、集約、標準化、保持する必要があります。

これは完全に独特な概念というわけではありません。

パーティエンティティやマスターデータはどの業界にも存在します。ただし、業界やビジネス、企業ごとに、個々の事業部門には、このテーマに関してさまざまな独特の違いがあり、その内容は、ビジネスの種類や顧客の種類によって異なります。

Citigroup社における課題

当社における課題を説明するには、まず、プライベートバンキングの顧客について多少説明する必要があります。特別な事柄は何もありません。どの企業にもその企業特有の要素があり、プライベートバンキングの場合もそれは同じです。

これから説明していくように、弊社では、すべてのバンキングデータをグラフデータベースに保存していますが、顧客がこの点をよく理解していることを知っておくことは、プライベートバンキングの場合、重要であると考えます。

さて、まずは、顧客という概念について考えてみましょう。

個人の誰もが顧客となり得ます。しかし、プライベートバンキングのコンテキストに沿って顧客を考えると、当事者の顧客だけでなく、その配偶者や子供、孫についても顧客と見なす必要があります。

ここで話題にしているのは、世代をまたぐ資産です。資産は世代間を移転し、銀行の業務はその移転に関与することになるので、孫という概念が重要になるのです。

家族の一員である、脇役としての顧客であり、当事者の顧客が法人格であるか否かは問いません。また、業務を委託されている弁護士、税理士、マネーマネージャー、ファミリーオフィスなども顧客に含める必要があります。つまり、顧客の概念はその範囲がきわめて広範囲にわたるのです。

以下の図では、これらの内容を著しく簡略して表現しています。さてここまでは、顧客側の要素についてお話ししてきました。

さて、次は、銀行の側に視点を移してみましょう。

まず、行員のうち、リレーションシップマネージャーやアドバイザーと呼ばれる職種は、顧客対応の主要窓口になります。この行員が、顧客との関係構築の業務を担います。しかし、それで終わりではありません。

プライベートバンキングには、この行員以外にも顧客のサポートに携わる多種多様な個人が存在するのです。

フロントオフィスのコンテキストでは、信託部門担当のほか、顧客のサポートに当たるアソシエートバンカーやアシスタントバンカーの役職も考慮する必要があります。

顧客が運用を希望する任意の商品に関して特別なアドバイスを提供する投資コンサルタントや商品スペシャリストにも目を向ける必要があります。

続けて、ミドルオフィスやバックオフィスについても見ていきましょう。

ここには、顧客のために各種の手続きを行うオンボーディング担当の行員がいます。顧客が運用を望むあらゆる金融商品の手続きを担当し、口座を開設し、口座を管理します。一方で、融資の準備をする役職もあります。さらには、特定の地域のビジネス全体を統括するエリアマネージャーという役職も存在します。

こうして、登場人物は、かなり急激に増加することになります。

この顧客の場合は、銀行に複数の資産を保有しています。これらの資産を保有するエンティティを表現しなければなりません。資産のポートフォリオを表現するためには、資産のグルーピングを維持する必要があります。

そのための情報としては、納税者番号や企業名、従業員名、電話番号、商品名、従業員ID、メールアドレスをはじめとするさまざまな種類の付随データがあり、その内容は多岐にわたります。

上記の内容を考慮すると、最終的に以下のような図ができあがります。

この最後のグラフは大幅に簡略化されており、1つの顧客の様子を表しているに過ぎません。

弊社では長年にわたってプライベートバンキングのマスターデータを扱ってきましたが、そのデータをリレーショナルモデルで処理していたのです。リレーショナルモデルは多対多のモデルです。

プライベートバンキングのビジネスでは、データの照会で分岐型の質問を複数使う必要がありました。このモデルをリレーショナルデータベースに組み込もうとすると、分岐型の質問を処理するのにデータベースの結合が必要になりますが、結合にはコストがかかります。結合をしない場合は、データを非正規化したデータベースを用意する必要があります。

データを正規化した通常のデータベースを使用するか、データを非正規化したフラットなデータ構造のデータベースを使用するかのいずれかを選択することになりますが、後者の場合、数千の一時テーブルの処理が必要になることがあります。リレーショナルデータベースでは、理想とする環境の構築は不可能です。

このような状況であるために、データモデルに根本的な変更を加えようとすれば場合によっては大きなリスクが伴い、多額のコストが発生します。そして最終的にシステムが肥大化します。ビジネスが拡大したときや、ビジネスの内容が進化したときに、データベースに根本的な変更を加える代わりにテーブルを追加して属性の追加に対応する方法もありますが、グラフを使って全面的にシステムを入れ替え、一からやり直せば、翌日には、状況は完全に一変するでしょう。

いずれにせよ、古いシステムでは、ビジネスの変化に追いつくことができなかったのです。規制が変更になったり、新しい商品が登場したりすると、新たな要件が発生します。そして、地域限定型のビジネス構造がグローバル型の構造に置き換わると、このような要件の変化のスピードが加速します。従来のままでは、要件の変化に合わせてスピーディにシステムを変更することはできませんでした。

そこで、まったく新しいシステムを構築するべく、作業に着手したのです。プライベートバンキングで扱う種類の情報を配布でき、持続性に優れるグラフの概念を基に、一からシステムを作り直すことにしました。

この背景には、Citi Private Bank社全体で現在進行しているデータのトランスフォーメーションがあります。つまり、プライベートバンキング部門だけに限らず、広く変革が進められているのです。さらには、ゴールデンソースのアプローチを採用し、高いパフォーマンスと信頼性の確保を図り、扱うべき商品とサービスのすべてに対応できるシステムを目指しました。

取り組みのあらゆる側面で一貫しているいくつかの重要なコンセプトがあります。また、基本になっている一定の原則が複数あり、それらの原則はかたちを変えてマスターデータベースに組み込まれています。

データドメインはリポジトリごとに分割し、適切に処理ができるようにしました。人口統計関連の情報は金融関連の情報と分離しています。この結果、課題に合わせて適切なツールを選択できるようになりました。

さらには、銀行業務の観点からあらゆる法規制を遵守し、リスクに配慮するよう、努めています。データベースに格納する情報や、保存するデータにはどれにも、難読化の処理を施します。また、求めるタイミングや方法でより自由にデータを利用でき、一方で規制要件も遵守されるよう、トークン化の処理も行います。

弊社はグローバルに事業を展開しているため、世界各国に顧客が存在します。それゆえ、国境をまたぐ問題に配慮しなければなりません。これは根本的な意味で重要な事柄の一つになっています。データベースにおいて顧客や個人を表現する場合、特定の先入観は排除し、ロールベースのアプローチを採用する必要があります。

顧客や個人を表現する方法は非常に重要です。プライベートバンキングでは、数多くのビジネスルールが存在するからです。これのビジネスルールは明確に記述する必要があります。質問に答えるタイミングや質問を受けた理由を理解する必要もあります。

プレベートバンキングのビジネスは複数の年度にまたがるビジネスになります。旧来のフローとの同期も必要です。一定の期間はシステムの共存が必要であるため、古いフローのデータはインスタンス化して、新しいフロー、すなわち新しいデータベースに取り込む必要があります。

弊社では、あるデータベースのデータを別のデータベースと同期する際にさまざまな技術を利用しています。新しい構造に取り込まれたデータは、それと同時に、その表現方法が変わり、リレーショナルモデルに格納していたデータを単に作り変えただけにとどまらず、表記が正確になります。

弊社には複数のチャネルが存在します。データは、Neo4jに格納される場合であれ、別のデータベーステクノロジーに格納される場合であれ、利用者のニーズに応じた利用が可能です。今後は、RESTfulサービスやKafkaメッセージ、分散型オブジェクトキャッシュなども導入する予定です。ユーザーにとって、より利用しやすい環境が整います。

重要な要素の一つとして、システム上に展開するアプリケーションがあります。システムの開発は、別のトランスフォーメーションプログラムに従って進められていますが、このプログラムを通じ、システムを連携させる機能の追加が進んでいます。機能を重視しながら、孤立した存在にならないシステムを開発することが必要です。このシステムでは、解決が必要な問題に目を向け、問題の解決計画をマッピングします。

人口統計情報のカスタマイズほど、グラフ構造にて適したカスタマイズはありません。このシステムは現在開発中です。グローバルに展開するこのシステムは、現在事業を展開しているすべての地域に配置されます。システムには入手したすべての顧客情報を取り込み、情報を分配するようにします。最後に、ビジネスロジックとビジネスルールの表現について触れます。

この点で、Neo4jはきわめて魅力的です。ビジネスルールは物理的な仕組みでデータに付与されます。これらのルールは非常に複雑な記述が可能であるため、企業にとって大きなメリットがあります。

ソリューション

ソリューションの説明にあたり、いくつかのユースケースを確認したいと思います。

人口統計データを活用してプライベートバンクが答えを導き出す必要のある質問のタイプをどう表現するかという課題に、弊社では集中して取り組んでいます。典型的な例として、可視化の問題が挙げられます。

概念としての可視化では、顧客やアカウントなどのデータのうちでユーザーがどの範囲のデータに関心を示しているのかを問題にします。可視性という概念は権限の上位集合にほぼ等しいものと考えられます。

可視化において扱うのは、従来の権限に関するものではありません。一般に、権限に関するルールには次のようなものがあります。

• リソース
• 役割
• アクション

これらは権限ルールにおける一般的な3つの要素です。

一方で可視化では、もっと個人レベルの要素に重点が置かれます。関心を払うべきは、この範囲の情報です。そうすれば、ビジネス上のルールはその機能を発揮します。

私たちが採用したのはロールベースのアプローチです。このアプローチでは、誰がどこでどのような役職についており、何に関心を持っているのかを明らかにする質問を設定しました。ここでは、データレベルのルールの内容と得られる答えの内容を、役職ごとにご説明します。

まずはじめに、バンカーやアドバイザーについて考察します。

これらの役職で、根本的に興味の対象になっているのは、商談相手の顧客です。

この個人や個人のグループには、リードバンカーという役職があります。これらの個人は弊社の場合、ある関係性を持った1つの集団にまとめられます。

リードバンカーの場合、どのクライアントに関しても、関係性の情報にアクセスでき、結果として口座の情報も照会できます。完全にダイレクトなラインが存在します。

一方、ここでは、簡略化した組織を想定しているので、リードバンカーは地域マネージャーの役職も兼ねます。地域マネージャーは、その名が示すように、担当地域のバンカーが従事しているすべてのビジネスの内容を確認できます。つまり、弊社の場合、ここでのグラフは階層構造になるのです。

地域マネージャーは、顧客に関するレポートを参照できます。監督するバンカーが担当している顧客について、その情報、関係性の情報、口座の情報を確認できるのです。

これらに関するグラフはすでに開発済みです。さて、前に挙げた役職に関して考察を続けましょう。

アソシエートバンカーという役職がありました。アソシエートバンカーはリードバンカーをサポートする役割を担います。一方、リードバンカーは、顧客との関係構築や顧客対応に当たります。

リードバンカーは、複数の地域に存在します。それゆえ、地域をまたぐ関係性が生まれます。ある地域のアソシエートバンカーが別の地域のリードバンカーにもサポートを提供できるような関係性を構築する必要があります。そうなると、アソシエートバンカーは、これらのリードバンカーの顧客の情報やその顧客の口座情報にもアクセスできることになります。

このように、弊社には、広範な情報にアクセスできる役職が存在するのです。これらの情報には、顧客に関する情報だけでなく、それぞれの地域に関する情報も含まれます。

該当する役職としては、業務担当者、KYC QA担当者、オンボーディング担当者などが挙げられます。地域全体をサポートする関係上、個々の顧客ではなく、サポート担当の地域をまたがる関係性が構築されるのです。

前の実装では、特定のクラスの可視性を個人に割り当てました。以下の図に、グラフでその内容を示します。

可視性に関する問いは顧客ではなく、地域を起点にします。個人と、地域の個々の顧客との間には、直接のリンクは設定されません。

ビジネスルールは業務と地域という要素から構成されるので、グラフは、地域から始まり、顧客にたどり着くようになっています。この構造はビジネスルールを表しています。

個々の役職がグラフにどう組み込まれているのかと、ビジネスルールの仕組みが大まかにわかるようになっています。

ユーザーが求める問いは他にもありますが、一般の人々との関係性に関する問いなどがその好例です。

一方で、グラフ構造に組み込んでおけば特に意識しなくても最初から答えが得られる問いもあります。これは注目すべきことです。これらの問いは要件にはなっておらず、実装を要求されることもありませんでした。しかし、グラフ構造のおかげで、これらの問いでも答えを提供できたのです。

ソリューションについてもう少しご説明します。

グローバルデータはマスターデータベースに格納しています。これらのグラフがリクエストを受け付けられるよう、Neo4jのクラスターを複数の地域に構築しています。注目すべきことが1つあります。情報の照会では、キャッシュを使わず、常に直接グラフに問い合わせをするようにしているのです。グラフ構造やCypherに直接問い合わせるのが好ましい問いがあるためです。

いくつかのJavaコードを用意し、オブジェクトを作成し、必要な属性すべてをオブジェクトに実装して、コードやコードのオブジェクトを分散型のキャッシュ構造にプッシュしなければならないとすると、開発作業が難しくなる可能性があります。そのため、まずはじめにグラフに問い合わせを行うようにする必要があります。

これには遅延の問題も関係しています。ある地域でビジネスアプリケーションのサービスを何度も起動し直さなければならなくなったことがあります。データはアプリケーションのすぐそばに配置する必要があります。そうしないと、アプリケーションは中央のソースにデータを取りに行くことになるので数百ミリ秒の遅延が生じてしまいます。グラフデータベースはグローバルにプッシュし、グローバルレベルでデータの整合性が維持されるようにしています。

これが可能になった唯一の理由は、個人情報（PII）の規制や地域をまたぐ規制、プライバシーの規制などの要素を満足できるよう、可能な限り高い制限基準を設けたからです。これらの規制の最も厳しい部分に合わせて制限基準を設定したのです。さらに情報はトークン化し、その素性を隠しています。この結果、グローバルレベルでグラフの整合性を確保できるようになっています。

データを細分化して対応する方法もありますが、この場合、維持の作業が非常に複雑になります。それゆえ、トークン化と整合性の維持が持つ意味は重要です。もしも別の方法でマスターデータを表現していたり、別の場所にマスターデータを配置していたりしたら、同期するものと、同期せずにローカルに残しておくものを分けて処理することに時間や労力をかけることになってしまいます。

そして結局のところ、そのようなルールはほとんど理解不可能なものになってしまいます。ここでの目的は、グラフの整合性を維持し、グラフをシンプルな状態に保つことにあります。サービスの利用時に表示する内容を適切に判断する必要があります。これは一般的なアプローチでもあります。

多くのプライベートバンクでは、レポートの処理でID情報が使用されます。ID情報の照会があった場合、相手の素性やデータ利用の目的が明確になるまでは、情報が表示されないようにしています。この場合、処理を開始するかどうかの判断が必要です。

利用時に情報がトークン化されれば、管理者から情報を得たり、担当外の地域で運用されているオンボーディングアプリケーションを利用したりできます。この際、データはKafka上でプッシュします。

その後で、データはグローバルに展開しているすべてのデータベースとクラスターに送られます。

ユーザーが画面を開き、その操作が適切であると見なされると、トークン化の処理が行われ、ユーザーは情報にアクセスできるようになります。

そして次に、金融データのリポジトリを取得し、金融データからパーティのマスター情報とID情報を抽出します。ユーザーはアカウント番号だけで作業を始められます。アカウント番号はトークン化されます。次に、グローバルに一意のIDとトークン化されたIDの間でリンクが確立されます。

ポートフォリオビューアーで画面を見ると、トランザクションの一覧を確認できます。どのトランザクションがどのアカウントと関連付けられているかが、グラフに適用したトークン別に表示されます。トークン化の解除を行った場合は、画面を更新する必要があります。

このソリューションには他にも、ビジネス上重要な機能がいくつも搭載されています。

このソリューションは、オフラインの分析ツールではありません。ビジネスクリティカルなツールがダウンすると、ユーザーはすぐに気付きます。

特定の個人がWebブラウザーをオープンしたり、クライアントポータルを起動したりしたときには、その時点で表示内容がチェックされます。サービスが利用できなくなると、その影響はすぐに表れます。

弊社では、十分な能力を備える、エンタープライズ対応の、ビジネスクリティカルソリューションを確実に実現するべく努めています。

そして、読み出し、書き込みの要件や、機能以外の要件に関して一連のパフォーマンステストを実施してきました。クエリの機能では、応答のスピードを高めることを常に念頭に置いています。設定している基準に応じて100ミリ秒から300ミリ秒、またはそれ以下に、処理における応答までの時間を抑える必要があります。スピーディな応答は必須です。

Oracleデータベースの変更内容の同期に関して適切な要件を設定しようと考えています。新しいアプリケーションで対応できない状況があると、変更が生じますが、早朝にバッチ処理をしているので、適切な条件の設定が重要になります。必要な更新内容が数十万件程度であれば、バッチサイクルの前に処理を完了できるものと考えており、処理が1日も遅れるようなことはないでしょう。

一方で、レジリエンスにも常に十分な注意を払ってきました。そして、ローカル、データセンター、データセンター間、リージョンのレベルでフェイルオーバーを実現できるようなアプローチを考案しています。

幸い、グラフではグローバルレベルで一貫性が確保されるため、どの地域でも信頼性の高いインスタンスが得られます。データセンターが完全に停止しても、照会の機能が失われることはありません。処理の完了までに数百ミリ秒待つ必要がありますが、システムの一貫性と可用性は常に維持されます。

ここでは、CoBと一般的なフェイルオーバーの条件を満たす必要があります。これらの要件に対応できる機能がシステムには組み込まれています。

銀行業界では、新しいテクノロジーに関心が集まります。この業界では、規制や監査、コンプライアンスなどに特に注意を払う必要があるからです。情報のセキュリティはきわめて重要です。弊社では誰もが、データの消失やデータ漏洩のニュースに注意を払ってきました。

銀行で導入するソリューションは、あらゆる関係者のニーズを満たすものでなければなりません。私たちは、コンプライアンス部門や法務部門とやり取りを重ね、導入するソリューションを彼らに理解してもらえるよう努め、採用するアプローチに同意を取り付けており、適切な配慮を心がけています。

グラフを利用したのは今回が初めてではありませんが、今回ほどグラフで緻密な作業をしたことはありませんでした。これは私のチームも同じです。プロジェクトを進める中で数多くの興味深い事柄を数多く学んできました。

最初に学んだのは「モデリングの手法をやめたり、変えたりしない。」ということです。

既存のリレーショナルデータベースでは機能を満足できないため、使用せず、データはグラフ構造に組み込むよう努める。数多くある先入観は排除する必要がある。

そして、新たな視点でこれまでの状況を振り返るといったことであり、これらの考えはビジネスコンセプトに取り入れられています。新たな視点が必要になるのは、テクノロジーやコーディングばかりではありません。一定の前提をビジネスの観点から見直すだけでもそれなりの時間がかかります。見直しはあらゆる要素に関して必要です。

元来のビジネスコンセプトに立ち返ることになるので、実際のビジネスに照らして見直しをするのが望ましいと言えます。たとえば、これまでは、ロールベースの可視性を実現するアプローチはありませんでした。

何らかのソリューションを想定し、ビジネスルールをカギにして、新たな視点から見直しを行い、ビジネス上の条件は何か、ユーザーは誰か、利用目的は何かなどの問いを発し、それらの問いをビジネスルールの形式で表現できるかどうか考えます。

表現が可能な場合は、グラフでもモデル化できる可能性が高くなります。

データに関する課題

グラフを導入したことで、データに関するある特定の問題の存在が明らかになりました。

重複データの排除の機能は、グラフにおける役に立つ機能の一つです。これがよくわかる例の一つに従業員ノードの例があります。

ノードに適切な資格を付与するには、企業という概念を表現する必要があります。この場合、本人確認（KYC）の問いで、従業員の属している組織を確認する必要があります。この問いが発せられると、企業ノードの処理が開始されます。

これまでは、従業員も企業も属性の一つと考えられてきました。属性はKYCのフローの中にあるフィールドに過ぎないため、同じ種類の管理は必要ありません。必要なのはキャプチャだけです。

グラフのロールで同じ問いを扱う場合は、企業という概念を単一の方法で表現できるかどうかを判断する必要があります。同様のケースは他にも考えられます。この最初の段階の作業は非常に興味深いものになるでしょう。まずはグラフ内で使用する問いの表現方法を考える必要があります。

弊社の名称としては、Citibank、Citi、Citigroupのいずれも利用できます。これを1つに統一しようとすれば、大量のデータクレンジングの処理が必要になります。グラフの環境を旧来の環境と並行で運用している場合は、グラフと連携していない旧来のアプリケーションが実行していた検証の処理を適正化します。再度データのクレンジングが必要にならないよう注意しなければなりません。

データのガバナンス

データを扱う場合は、データのガバナンスをトピックの一つとして扱う必要があります。

弊社ではデータのガバナンスを強化し続けており、今この瞬間にもその取り組みがなされています。弊社では、最高データ責任者（COD）という役職を設けて監視を強化しています。究極的には、ガバナンスは今後も強化し続けます。当初より続けてきたとおりです。

プラットフォームの構築よりも、これを優先します。定義上、新たなリポジトリに組み込まれたエンティティはどれも、ガバナンスの対象とする必要があります。

このデータガバナンスでは、グラフ構造の扱いに一定の微妙な違いが生じています。データガバナンスに関する従来の前提を見直し、ここでも考え方を改める必要があります。

さらには、主要なデータエンティティ、重要なデータエレメント、オーナーやスチュワードの役割なども見直す必要があります。Kafkaのメッセージや、キャッシュ内のオブジェクト、グラフデータベースについても同様です。これまでガバナンスのプロセスとして理解していた事柄も、新しい環境で再度見直す必要があります。

データエンティティのロジックも旧来のロジックです。グラフではそのロジックは使えなくなるので、データエンティティを物理構造にマッピングする方法を検討しなければなりません。1つのエンティティには、属性が200、ノードが30、2から3のプロパティがあり、膨大な数の関係性の情報が存在します。テーブルのようなオリジナルの論理データモデルではそもそも対応できない規模です。

弊社では関係者同士の対話を改めて推進しています。データガバナンスの担当者は実装作業の当初より、作業中に、グラフ構造の実装担当者と頻繁に対話を行い、コネクションの内容を理解するよう努めてきました。このプロセスは今後も続けていきますが、対話を活性化する必要があります。

まとめ

最後に、今後の展望について考えてみたいと思います。

私たちは、データの位置付けをコストから資産へと変え、価値を生み出していきたいと考えています。

これまでに説明したユースケースでは、著名人に関して想定外の成果が得れました。どの著名人とどの著名人の間に関連性があるのかを、弊社との関連性に関する情報を通じて特定することができたのです。何のコストもかかっていません。リレーショナルデータベースの構造では、簡単には得られない情報です。

ドメイングラフのトピックを起動すると、人口統計マスターデータと見込み客の情報が得られます。一意のIDと一意のノードを使用すると、見込み客のデータを人口統計マスターデータとリンクさせることができます。リンクが完了するとすぐに値が表示されます。

たとえば、特定の地域で顧客とその担当のバンカーを検索すると、その顧客と同じ地域と同じ会社で働いていて、かつ、慈善活動組織に参加している見込み客を見つけ出すことができます。そして面白いことに、これが簡単に実現できてしまうのです

Oracleデータベースなどのリレーショナルデータベースを利用していたら、何度も作業を繰り返し、ずっと苦労していたことでしょう。グラフなら答えが得られても、リレーショナルデータベースでは不可能でしょう。この種の問題の解決では、グラフデータベースが大いに威力を発揮します。

Neo4jは、グラフデータベース技術をリードする存在であり、世界で最も広く導入されているグラフデータベースとして、Comcast、NASA、UBS、Volvo Cars などのグローバル企業で、人、プロセス、システムがどのように関連しているかを明らかにし、予測するのに役立っています。

Neo4jで構築されたアプリケーションは、関係性優先のアプローチを用いてデータ分析や人工知能、不正行為の検出、リアルタイムの推奨、ナレッジグラフなどのつながりのあるデータの課題に取り組んでいます。 詳細はneo4j.comをご覧ください。

Neo4jについて詳しく知りたい方はこちらまで：
info@neo4j.com
https://neo4j.com/contact-us

Neo4jについて日本語で詳しく知りたい方はこちらまで：
https://www.creationline.com/neo4j
https://www.creationline.com/neo4j/contact