自動車業界や製造業におけるグラフ: データから新たな価値を引き出す #Neo4j #RDB
この記事は1年以上前に投稿されました。情報が古い可能性がありますので、ご注意ください。
本ブログは、「Neo4j」社の技術ブログで2020年5月27日に公開された「Graphs in Automotive and Manufacturing: Unlock New Value from Your Data 」の日本語翻訳です。
プレゼンテーションサマリー
Neo4jは、グラフはどこにでもあると考えています。
本記事では、製造業全般、特に自動車産業におけるグラフデータベース技術について考えていきます。まず、グラフデータベースになじみのない方向けに、グラフ（具体的にはNeo4jについて）の一般的な概要を説明します。 そして、自動車メーカーや他の製造業が通常保持しているデータの概要を紹介します。
多くの場合、データは異なる複数のシステム上に存在し、ビジネスの様々な分野をカバーしています。 これらすべてを、グラフを使用してどうやって繋げていくのかをお話しします。その後、このデータをグラフにまとめる詳しいユースケースを見ていきます。サプライチェーンマネジメント、保証分析、顧客360度ビュー、ナレッジグラフなどです。最後に、我々のグラフデータベースが企業のデータの見方や活用方法をどのように変えてきたか、実際のケーススタディを紹介します。
プレゼンテーション本編：自動車業界や製造業におけるグラフ
グラフとNeo4jのご紹介
Neo4jとは？
自動車産業におけるデータの概要
ユースケース
サプライチェーンマネジメント
保証分析
顧客360度ビュー
ナレッジグラフ
事例
結論
プレゼンテーション本編：自動車業界や製造業におけるグラフ
自動車・製造業のグラフに関する当記事を読んでいただきありがとうございます。Neo4j のジョー・デポーです。
グラフとNeo4jのご紹介
まずは概要から説明します。まず、グラフデータベースとは何か、というところからお話します。
グラフデータベースを、既存のリレーショナルデータベースと比較して定義してみましょう。
リレーショナルデータベースは、行と列を持つテーブルで構成されたデータベースです。すべての行は要素であり、列はそれらの属性です。結合、外部キー、リンクテーブルを使用して、データベース内の異なるテーブルやオブジェクトのタイプをリンクしたり、SQLを使用してデータベースにクエリを投げたりできます。 エクセルと非常に似ていて、データの保存や処理モデルの中ではごく一般的なものです。
Neo4jは、データに対して異なるアプローチをとっています。 Neo4jはグラフデータベースであり、データ間のつながりを重視しています。 すべてを四角形の行と列に格納するのではなく、すべてが動的かつ直接的にリンクされています。従って結合やリンクされているテーブルはありません。Neo4jにデータを書くときは、関連するものに直接リンクさせます。 これによって大規模なデータセットでのパフォーマンスでも関係性を簡単かつ直感的に把握できます。
後ほど、つながりのあるデータの概念を具体化する事例を紹介します。SQLを使用するリレーショナルデータベースとは異なり、Neo4jでは Cypherというクエリ言語を使用します。Cypherは、グラフデータとそのつながりのあるデータの中に出てくるパターンを処理するために設計されました。
グラフデータベースのアプローチは、ビッグデータ時代に大変有効です。 また、データがビジネスの業務ごとに様々な場所に物理的に分かれて保管されている場合もあるでしょう。 そういった場合に、すべてのデータを組み合わせて、データ同士の関係性を可視化して理解できるようになれば、非常に有益です。
我々はグラフデータこそが、次の競争優位性のカギになると確信しています。事実、グラフを使ったアプローチで問題解決に取り組んだ企業は多大な恩恵を得ています。記事の後半では、自動車産業において、このつながりのあるデータをどのように活用して競争優位性を高め、データから新たな価値を引き出しているかお話します。
Neo4jとは？
Neo4jは、つながりのあるデータ向けの最良のデータベースです。グラフネイティブなデータベースであり、ファイルシステム全体がグラフで構成されます。変換レイヤは存在せず、根底のデータモデルが異なるわけでもありません。データをグラフとして保存し、データをグラフとして処理し、データをグラフとして提示します。 これは、他のエンタープライズ級のデータベースと同じ方法で行っており、大規模かつ確実な実行が可能で、ACIDに準拠しています。
また、小規模に導入してデータやユースケースが増えてきたら簡単にスケールできるため、非常にアジャイルです。 グラフデータベースがどのようなものか例を用いて簡単に紹介します。 グラフデータベースは、3つの主要な要素で構成されています。
1つ目の構成要素はノードです。ノードは物や、名詞、オブジェクトを指すことが多いです。 こちらの図でノードは円で表されています。ノードはラベルを持てるため簡単に識別できます。この例では、2種類のノードがあります。2つの Personノードと1つのCarノードです。
2つ目の構成要素はプロパティで、ノードとリレーションシップが持つ名前と値のペアです。左側の人の name のプロパティが"Dan"であることがわかります。
また、bornのプロパティ"May 29, 1970"、twitterのプロパティ"@dan"も確認できます。 右側にはもう1つのノードがあります。1975年12月5日生まれの"Ann"です。 Annのtwitterのハンドルネームがありませんが、それで構いません。
リレーショナルデータベースでは、すべての行が同じ数のカラムを保持する必要があるため、そのカラムにNull値を指定する必要があります。しかしグラフデータベースでは、特定のプロパティタイプを持っていない場合、その特定のノードに追加する必要はありません。 Neo4jでは、すべてのノードが同じプロパティと型を持つ必要はありません。
3つ目の構成要素はリレーションシップです。リレーションシップはノードとプロパティを組み合わせて、ノードがどのように相互に関連しているかを示しており、Neo4jの一番の特徴と言えます。ここでは、この二人に対していくつかの関係性があります。Dan LOVES Ann、Ann LOVES Dan、Dan LIVES WITH Annが該当します。 データベースにリレーションシップを書くときには、必ず方向があります。 方向性が重要な時もあれば、そうでない時もあります。ここでは、DanがAnnをLOVESであることがわかり、その方向は左から右へと動いています。 AnnもDanをLOVESであることがわかり、逆の方向の矢印があります。ダンがアンを愛していても、（残念ながら）彼女が彼を愛していない、という関係性も成立しうることに注目してください。また、DanはAnnとLIVES WITHで、左から右に矢印があります。 DanがAnnと同居していて、AnnがDanと同居してないのは成り立たないため、この場合は双方向のリレーションシップは必要ありません。ノードはプロパティを保持するだけでなく、リレーションシップも持てることがわかります。一番下で、Annが”Volvo”をOWNSしていることがわかります。 Dan はその車を2011年1月10日から DRIVES しています。この特定のリレーションシップには開始日がありますが、終了日や他のプロパティを持つこともできます。
これら3つの要素「ノード・リレーションシップ・プロパティ」がプロパティグラフモデルを構成しています。これらは、複雑でリッチなデータセットの構成要素であり、クエリを使って新たな洞察を得ることができます。
自動車産業におけるデータの概要
それでは、自動車メーカーやその他の製造業の企業が一般的に保持しているデータの種類についてみていきましょう。自動車の事例は皆さんにとって理解しやすく、より詳細に掘り下げていくことができるため選択しました。 ここでは特に自動車業界に焦点を当てていますが、他の業界に共通する項目もかなりあります。
最初のデータの種類は、組織データ、つまり社内のデータです。 組織内では、通常、様々な施設・工場・倉庫の情報、文書、プロセスが大量にあります。 人的管理にくわえて、各部門がどのように関わりを持っているかを示す階層構造があるかもしれません。また、クリティカルな経営判断が下されるKPIや報告書も重要です。このように、データがどのようにして生成され、どこから来ているのかを理解することは有意義です。 また、組織のデータには、システム、データベース、ITインフラなど、データやドキュメントが保存されているあらゆる場所も含まれます。
次に、製品データですが、これは何を作って売るかという情報です。 これには、文書や、顧客とのコンタクトやクレームへの対応方法、製品の製造方法などが含まれます。製品データには、その製品について社員や顧客が知りたいあらゆる詳細情報も含まれています。さらに、製品間で複雑に設定された製品階層（製品やブランドのグループ群）があります。また、部品表（BOM: Bills Of Materials）がありますが、BOM自体がカテゴリになる可能性があります。
BOMを描いて、すべての構成要素と要素同士の組み合わせを表そうとすると、グラフで表すのが妥当でしょう。 製品に伴う部品表を用意しておくことで、さまざまな製品に含まれる部品を追跡しやすくなります。当然、BOMが複数の場合もあり、かなりのデータ量になります。
また、 顧客データも保持していますが、ここでは少し厄介です。ディーラーを経由してくるお客様が多いため、自動車会社の多くはエンドユーザーと直接取引がありません。しかし、お客様に関するすべてのデータを確認してみましょう。お客様の個人情報や会社情報、お客様同士の関係性に関する全てを含みます。
次に、サードパーティのデータをみてみましょう。 これには、ディーラーネットワークの情報や取引先の情報、インスタグラム等のソーシャルメディアの公開情報が含まれます。 また、競合他社のデータ、プレスリリース、ニュース、サプライヤー情報、マクロ経済データ、関税情報などの市場データも含まれます。 別の切り口としてはイベントデータがあります。ある一定期間におきる具体的な事象データです。 センサーやテレマティクスデータがここに該当します。IoTの概念が普及しあらゆるものにセンサーが装備されるようになると、そのようなデータは増加します。お客様が自動車をディーラーに持ち込んだ際などに、そのようなデータを取得するチャンスがあるかもしれません。
イベントデータには、ディーラー経由で入手する保証請求も含まれます。 さらに、コールセンターの通話履歴、電子メールなど、お客様との個別の対応履歴情報もこちらに該当します。
最後に、サプライチェーンのデータがあげられます。材料や部品をどこで購入するかといったサプライヤーに関する情報です。また、物流データもこのカテゴリーです。モノの運搬方法、所要時間、コスト、他の選択肢などです。 さらに、在庫データもあります。これは部材の在庫データです。 もちろんこれらは製造業や自動車メーカーが保持するデータの全てではありませんが、様々なデータをどのように組み合わせてグラフ化できるかをご紹介するには十分でしょう。
ユースケース
それでは、自動車業界における具体的なグラフのユースケースをいくつか掘り下げてみましょう。 サプライチェーンマネジメント、保証分析、顧客360度ビュー、ナレッジグラフの例を見ていきます。
サプライチェーンマネジメント
始めにサプライチェーンのユースケースを紹介します。
これまでに説明した様々なデータを組み合わせてどのようにサプライチェーンを管理していくか、データを基にどのように意思決定するのか、についてお話しします。
黄色の部分は、部品購入元であるサプライヤー情報です。部品の費用や、輸送手段の情報もあります。ここでは、施設Aと施設Bにすでに在庫があります。 リレーションシップをよく見てみると、ここで言うコンポーネントはAnother Componentと同じであることがわかります。これは、別のサプライヤーから受け取ったために名前が異なるけれど機能は同様で、FFF代替品として使用可能なケースです。グラフの中央にはBOMが表現されています。ご覧のように、Assemblyの一部であるComponentがあります。もちろん実際のBOMはもっと複雑ですが、個々の組立部品を束ねて、上位階層でまとめていく感覚が伝わればと思います。 また、ある製品がどれくらい売れていて、これからどれくらい作るのか、がわかるので、部品数やその製品を構成する部品群をどうやって調達するのかを考える際に手助けになります。BOMにくわえて、部品を組み立てて作るコンポーネント、受注や完成車両の情報、部品の情報、組立部品を製造ラインと関連づけて表示できます。
このような形で、受注から製品まで、全ての工程（製造ライン）と部品がグラフ上で関連づけて表示されることで、サプライヤの影響を理解できます。その上で、現在の売上高、売上予想を確認して、サプライヤーからの調達の意思決定を行うことができます。 ここでいう需要とは、グラフの左側の注文数と今後の受注予測数を足したものです。部品の在庫数を確認し、需要から差し引くことで購買の決定ができます。そして、送料、部品価格、契約内容、関税の影響などを踏まえて、サプライヤーの選定が可能になります。このグラフを通して需要から供給までをエンド・ツー・エンドで把握し管理する様々な選択肢がうまれます。さて、このグラフを使用して事例をもう一つ紹介します。左下のClaimとCustomerのノードを見て下さい。
ここでは、ある"Component"に関連するクレームが複数あり、そのコンポーネント不良に同様のクレームをつけた顧客が多数存在する可能性があります。 その場合、そのコンポーネント不良の可能性をサプライヤーに確認することができます。 顧客やクレームから特定のサプライヤを追跡するために、必要なデータを、グラフによって得られます。これによって、コンポーネントを置き換えたり、不良品率が低い別のサプライヤーから購入するといった、他の選択肢が検討できます。
それでは、このようなグラフがどう活用できるか紹介します。 まず、受注・調達プロセスが改善できます。
データを入手し、データレベルで関係性を理解することで、予測に基づいた調達・発注プロセスをスピードアップすることができます。Neo4jは需要（グラフの左側）から供給（グラフの右側）まで、その全貌を把握しているため、どのように調達するのかが直観的にわかります。 また、このグラフは、発注コストの節約にも役立ちます。需要を長期的に見て在庫と比較し、特定の期間にどれだけ購入しなければならないかを把握している場合は特に、このようなグラフを使用することで、スケールメリットを活用できます。みなさんは現在、サプライチェーン全体でこのような長期的な視点を持てず、小口注文を定期的に行っているのではないでしょうか。もしグラフでわかりやすく視覚化し、長期的視点で確認できれば、一括購入したり、より賢明な購入決定を下してコスト削減が可能です。
さらに、グラフを使って在庫を最適化することができます。繰り返しになりますが、利用可能な部品の数、部品がある場所、部品が届くまでのリードタイム、どの車種に組み込まれるのか（予測の観点から）がわかれば、在庫を適切な場所に適切なタイミングで移動させることができます。在庫をそのままにして新規購入するのではなく、在庫を活用して需要にこたえることで、明確に在庫計画を改善でき、過剰在庫を防げます。予測の見通しが表示され、必要なパーツ数を発注できます。そうすれば、効率的に在庫計画を立てられ、必要以上に購入したり在庫を抱えることはありません。
最後に、グラフはサプライヤーとその製品の比較分析に役立ちます。使用しているすべての部品やコンポーネントに対するサプライヤーがビューで確認できれば、保証請求と比較して、さまざまなサプライヤーの不良品率を見て取れます。また、物流を比較し、関税や法規制コンプライアンス上の問題がないかどうかを判断することもできます。このように全体を見渡すことができれば、より多くの情報を得たうえで、どのサプライヤーからどの製品を購入するかを決定できます。
保証分析
それでは、保証請求とクレーム分析についてお話しします。
上のグラフはClaimを中心としたイベントデータです。このクレームは、特定の部品やコンポーネントに関する、特定の Fault (欠陥)に対するクレームです。 同じ欠陥に紐づく他のクレームをグラフから確認すると、類似した事例がどれだけ多いか理解できます。クレーム件数に応じて、不良品かどうかを推測でき、取引先に問い合わせることができます。例えば、その部品は他に何台の車に搭載されているか？クレーム数に対して、そのうちの何件が故障する可能性があるか予測できるか？どのくらいの頻度でクレームが発生するのか？クレーム数の増加は？ 高コストな問題となりそうか？ どうすればより迅速に解決できるのか？などの疑問です。
そして、この部品のSupplier を調べられます。これもまた、先ほどサプライチェーンマネジメントについて触れた事例と関連していて、クレームから欠陥部品を製造したサプライヤーを追跡し、対話を始められます。また、クレームや不具合に関連した Customer や Dealer の行動も確認できます。ディーラーと自動車メーカーは何よりも大切なパートナーであるため、「保証詐欺」という言葉は避けたいところですが、クレームが膨らむケースもあります。クレームの中に外れ値がないかどうかも確認できます。例えば、特定の欠陥に対するディーラーのクレームが別の顧客とのクレームと一致しているか、顧客がDocumentation (操作マニュアル)通りに操作していないことを意味しないか、修理方法を間違っていないか、などを調査できます。 クレームのパターンも確認できます。保証期間終了まで残り数か月という頃には、一定期間内に外観や特定の欠陥のクレームが一貫して急増することもあるでしょう。それらは調査したほうがよいクレームかもしれません。
ここでもまた、テレマティクスやセンサーデータを利用することで、特定の欠陥へとつながるドライバーの行動や車内の動きに特定のパターンがないか分析したり、予測することができます。 もちろん、関連する全ての状況を明らかにするために、問題のVehicle (車両)に関する情報も必要です。例えば、車両の修理歴や長時間（長期間）使用されている部品を確認すれば、個々のクレームにどのような影響を与えているか把握できます。また、その車両の構成や他の車両との違い、その製品の基本的な情報も知っておく必要があります。
また、グラフの下の方にSocial Media Posts があります。 車両の欠陥に関連するソーシャルメディアの投稿を見つけたら、保証請求の調査を考慮したり、クレームに至るまでのソーシャルメディアの投稿に対して感情分析を行うことができ、クレームに関する経緯と背景を明らかにできます。
では、このような保証分析グラフはどのように使えばいいのでしょうか？不適切なクレームや保証詐欺を示すパターンをグラフから見つけだすことはできるのでしょうか？もちろん可能です。パターンを見つけられたら、常に注視し、不適切なクレームではないか調査することが可能ですし、この特定のクレームにつながるパターンがあるかどうか調査することもできます。このように、不適切なクレームが発生する前に、先を見越して行動できます。 また、このグラフを使って今後のクレームを予測することもできます。テレマティクスデータ、センサーデータ、クレームの原因となった他の修理履歴、関連する部品など、クレームを取り巻くパターンを理解することで、将来的にこのようなクレームの発生を防ぐことができます。 これにより、保証リスクの管理や、深刻なケースではリコールリスクの管理に役立ちます。
そこから、問題がどれほど大きくなりそうか、技術部が不具合修正を製造現場に盛り込むまでどれぐらいかかりそうか、どれほどの規模の顧客が影響を受けそうなのかを理解し、状況に対処する手順を明らかにできます。繰り返しになりますが、グラフがサプライヤで発生した問題が関連しているかどうかを理解する手助けになり、問題にどう対処すべきか検討できます。
顧客360度ビュー
次に、あらゆる業界で話題になっている「顧客360度ビュー」について見ていきましょう。顧客360度ビューとは、顧客に関する全ての情報にアクセスし、それらの情報がどのように関連しているかを理解して、顧客の全体像を確立することです。
もちろん、上のグラフは Customer を中心としています。グラフを通して、顧客と他の顧客との関係を理解することができます。例えば、この顧客は別の法人顧客で働いているかもしれませんし、家族かもしれません。契約情報や現在の車両の情報、BOM、整備方法、オプション、製品定義などだけでなく、以前購入した車両の情報も確認できます。過去に購入した車両、付けたオプション、過去のクレームなども見ることができ、センサーデータ、テレマティクスデータ、クレームデータ、顧客連絡先もこのグラフには含まれます。異なるシステムに存在するデータを集約しておくことで、顧客や顧客が購入した製品を理解することができ、顧客の好みや他の人々との関係性、ソーシャルメディアの投稿に至るまで可視化できます。
では、このデータで何ができるのでしょうか？どうやって使いこなせばいいのでしょうか？顧客360度ビューを行う基本的な目的は、カスタマーエクスペリエンスの向上です。顧客の過去のクレームや車両履歴を把握していない状態で顧客対応すれば、顧客は間違いなく苛立ちをつのらせるでしょう。顧客とスマートなコミュニケーションが取れれば、カスタマーエクスペリエンスは間違いなく向上します。顧客360度ビューを利用して、生涯価値（ライフタイムバリュー）の高い顧客を特定することも可能でしょうか？もちろん可能です。顧客行動を理解すると、過去と現在の両方の状況を見て、顧客を識別できるようになります。例えば、2年毎に最新機種の新車をオプション付きで購入し、ほとんどクレームがない顧客群と、購入回数はかなり少ないのにクレームが多くTwitter上でネガティブな投稿している顧客群を識別することが可能です。グラフによって将来の優良顧客を過去の行動から予測することができ、サービス提供を優良顧客にフォーカスすることが可能になります。
同様に、生涯価値の高い顧客に関して、そのパートナー（夫/妻）の情報もある場合（その方自身も顧客ではあるけれど、一見、生涯価値が高く見えない顧客）は、ご夫婦としての生涯価値は非常に高いので、お二人に対して優れたサービスを提供したいと思うでしょう。また、顧客360度ビューのグラフは、顧客の解約の可能性を検知して防止します。価値の高い顧客を特定する際と同じ方法で、解約の可能性の高い顧客を特定することができます。例えば、過去の行動からクレームのパターンを見つける、ソーシャルメディアの投稿を見る、顧客が契約更新しなかったり、別の車を購入する原因となった可能性のあるやりとりを調査するなどして特定できます。そのパターン発生を監視し、解約に繋がりそうなケースを特定して、その顧客をどのようにサポートするか、そして時間をかけて解約防止を試みる対象とするか判断できます。同様に、このグラフを使用して、同じような商品を購入した他の顧客と比較することで、購入に至りそうな顧客を特定し、アップセルやクロスセルを増やすことができます。
このようにして、顧客の個々の行動やグラフから読み取れる行動の両方から判断して、顧客が魅力を感じる追加のオプションや機能の提案をしたり、上位ラインの販売を試みたりできます。
ナレッジグラフ
最後にナレッジグラフがあります。ナレッジグラフは包括的な名称ですが、この業界に限らず多くの用途で使われています。基本的には、会社全体のナレッジを取り込み、組み合わせることで、それらがお互いにどうリンクしているか分析できるという考え方（概念）です。
ナレッジグラフの登場で、以前は不可能だったナレッジのリンク付けが可能になり、それによって新たな知見を導くことができるようになりました。また、ナレッジを、単にエンジニアの頭の中やどこかのメモリ上やドキュメント、ファイルに散在させるのではなく、永続的に残していくことができます。
上のグラフは、製品ベースの内部用のナレッジグラフですが、これをさらに組織データや人事データなどに広げることも可能です。このグラフはProduct を中心としていて、製品の様々なバリエーションや製品群がどう関連しているかを示します。最終的には、ドキュメントのリンクをたどって、このドキュメントの保存先や、担当者、責任者も把握できます。また、検索エンジンを有効化できるので、ファイルシステム上にのみ保存されている情報や、タグやリンク付けされていない情報を簡単に見つけることができるようになります。グラフで見ることにより、情報の取り扱いがはるかに容易になり、時間の節約にも繋がります。このグラフでも、下部には製品のBOMがあり、Parts と Assembly から製造拠点が把握できます。さらに、その部品のサプライヤー情報を見ることができ、特にこのグラフにおいては多くのクレームや欠陥情報も確認できます。
また、マーケティングデータやソーシャルメディア分析データもあるので、ブランドや個別の製品に関連付けられます。これらの情報を売上や予測とひとまとめにしてリンクさせることで、これらの様々なデータ群の全体像を理解できます。どのように組み合わせれば、この業界でナレッジグラフを活用できるのでしょうか？製品やサービスの向上に使用できるでしょうか？はい、問題ありません。
ドキュメント、設計書、メモ、決定事項など多くの情報が、あらゆるデータセットに長時間保存されているかもしれません。検索機能を使ってすべての情報にアクセスできれば、新製品の設計や開発時に重要なあらゆる要素を考慮できるようになります。過去にうまくいったこと、いかなかったことを思い出してみましょう。過去に同様の問題が発生しなかったでしょうか？その時の解決策は？また、サプライヤーを観察し、そのサプライヤーがどのようにしてさまざまな欠陥に対応しているかを理解することで、自社製品に組み込まれる製品を改善して欠陥を減らすことに繋がります。ナレッジグラフ、とりわけデータの組み合わせやリレーションシップを通じてこれら全てを把握できます。同様にして、製品の市場投入時間を改善することができます。手元に適切なドキュメントがあり、しっかりと理解できている場合、設計サイクルやその他のエンジニアリング作業をより迅速に終わらせることができます。また、エンジニアだけでなくデータを探している他の社員にとっても、必要なデータを素早く入手でき、本来業務に集中できます。
また、このグラフは顧客対応にも使用されます。製品に関する情報やドキュメント、履歴情報を含むポータルを作成し、グラフを外部に公開して顧客に直接使いやすさをアピールすれば、カスタマーエクスペリエンスを向上させることも可能です。これ以外にも幅広い業界で適用可能なユースケースもあります。
事例
それでは、ここまで説明してきた方法でNeo4jを活用している企業の事例を見ていきましょう。まずはボルボ社です。ボルボ社はNeo4jを使用して、車両に搭載されているすべてのコンポーネント間のコネクションを確認し、それが顧客のニーズにどのように対応付けるか把握します。
ボルボ社におけるNeo4jの利用目的は、BOMを確認するためだけ、つまり特定のエンジニアリングメトリクスを満たすためだけにBOMを表示するだけではなく、車両のあらゆるものが顧客のニーズに応えられているかを理解することです。これは非常に興味深いユースケースで、高度につながったデータが大量に活用されているようです。次に、Neo4jをサプライチェーン最適化に活用しているアメリカ陸軍のユースケースを紹介します。一般的なメーカーとは思えないかもしれませんが、修理方法や必要なスペアパーツが何でどこに取り付けるかを把握する必要があるのは確かです。
そして当然、このユースケースは人命に関わるものであり、適切なコンポーネントを持ち、適切な場所、適切な時間に適切な修理を行うことは、文字通り命を救うことに繋がります。陸軍はNeo4jを採用することで、BOMを理解してサプライチェーンを管理し、より迅速な意思決定を行っています。
続いて、Schleichを紹介します。SchleichはNeo4jをバリューチェーン全体で統合された製品データ管理に使用しています。サプライヤー情報や、さまざまなサプライヤーから提供される原料が製造ラインの全工程でどのように移動していくか、などのデータが含まれます。その結果、さまざまな部品に関するナレッジや、別製品への搭載状況、さまざまな国における特定の材料に関する規制への準拠方法などの知識を一元的に得ることができます。続いてNASAを紹介します。NASAは一般的なメーカーとは異なると思うかもしれませんが、NASAのエンジニアや科学者は、Neo4jを学んだ教訓データベースとして使用しています。彼らは何十年分ものドキュメントをデータベースに保存し、Neo4jを使って情報間の繋がりを作成し、教訓の内容や、その教訓に関連するもの、教訓のメタデータを理解することができました。これらは検索機能の強化に使われています。エンジニアや科学者は学びを振り返り、過去の問題をどのように解決したか理解することができるようになりました。NASAの成果の一例は、火星に人間を連れて行くミッション「オリオン」のために作られたカプセルに潜む問題を、検索エンジンを使って発見したことです。問題を簡単に見つけ出すことができた結果、再設計が最小で済み、実に2年間もの時間と100万ドルもの資金を節約しました。グラフを使用して、必要なデータをすぐに見つけることができました。
最後に、製品360度ビューにNeo4jを使用しているロッキード・マーティン社を紹介します。既に顧客360度ビューの説明はしましたが、製品 360度ビューも同様のコンセプトに基づくもので、製品と製品の周辺に存在するデータがどのように関連付けられるかを把握するものです。このように360度の視点で製品を見ることで、多くの効率化が図られ、製品の改善に活かせる新たな気付きを得られました。
結論
今回の記事では、小さなグラフを通して簡単な例を見てきましたが、いつかあなたのデータが下のような状態になった時にこそ、Neo4jの出番です。
Neo4jは、複雑に絡み合う大規模なデータセットのなかからパターンを見つけ出したいときに、最も効力を発揮できます。
ホワイトペーパーはこちらからダウンロードできます。（英語版のみ）グラフデータベース技術を利用して競争優位性を高める方法をご覧ください。
ホワイトペーパーを読む（英語版のみ）
