fbpx

既存のデータアーキテクチャがイノベーションを阻んでいる10の兆候:パート1 #MongoDB #DataArchitecture #GDPR #360度ビュー

この記事は1年以上前に投稿されました。情報が古い可能性がありますので、ご注意ください。

本ブログは、MongoDB社のブログで2021年12月4日に公開された「10 Signs Your Data Architecture is Limiting Your Innovation: Part 1」の日本語翻訳です。

一般にほとんどの企業では、データレイヤーを意識することはありません。しかしその結果、新製品の市場投入までの時間の増加、メンテナンスコストの高騰、イノベーションへの集中阻害といった、ビジネスが直面する大きな課題の原因を覆い隠してしまう恐れがあります。

実は、これらの問題は全て、データアーキテクチャの複雑さに直接起因していることが多いのです。大量のコンポーネントが蓄積した環境をクラウドに移行させる場合であれ、最新のアプリケーションに対応するために即席の対応を重ねてきたレガシーのインフラストラクチャを扱う場合であれ、その複雑さが原因でさまざまな問題が生じています。開発者の時間やリソースが奪われ、メンテナンス作業にも集中せねばなりません。データの複製や統合で課題が発生し、その対応にコストもかかります。

この複雑さは様々な形で現れますが、それらが積み重なると、革新的なアイデアを市場に出す上で深刻な妨げとなりえます。この影響は、データアーキテクチャの複雑さに直接根ざした一種の税金と捉えられており、DIRT(Data and Innovation Recurring Tax:データとイノベーションに関する経常税)と呼ばれています。

我々は、このDIRTを支払わざるを得ない状況に陥っている企業に現れる10の兆候を特定しました。詳細については、弊社のホワイトペーパー、『10 Signs Your Data Infrastructure is Holding You Back』(英語)をご覧ください。

兆候その1:インサイト(洞察)を得るのに、数週間、数か月要する

顧客のことが何もわからない状態では顧客対応は不可能です。現代では、顧客や顧客のニーズを詳細に把握することが、企業の存続において欠かせません。リアルタイムでそのような情報が入手できれば、成長につながる競争優位性を確保することもできるのです。

そうなると、アナリティクス専用のデータベースを個別に用意し、維持の難しいETLパイプラインを通じてデータベース間でデータをやり取りするケースが多いようです。しかし、リアルタイムのインサイトを顧客のリアルタイムの行動と結び付けるには、ETLパイプラインの処理は遅すぎます。さらには、ほとんどのアナリティクスデータベースが、半構造化データや非構造化データ、地理空間データの対応を苦手としています。一方で、データ形状は、システムの対応能力を超える速さで急激に変化します。

多くの企業では、アナリティクス情報をデータウェアハウスやデータレイクに格納しています。データウェアハウスやデータレイクを使用する場合は、システム間でデータのやり取りが必要になるため、レイテンシーが発生します。処理全体が非常に遅くなるので、リアルタイムの分析ができず、アプリケーションでできることが制限されてしまいます。

MongoDBのソリューション:MongoDBのアプリケーションデータプラットフォームを利用すれば、データベース内のデータをリアルタイムに直接分析できるので、この問題を解決できます。

兆候その2:顧客の状況を把握できる360度のビューを構築できない

あらゆる小売業者は、クリックストリーム(Webのアクセス記録)や購買履歴などの顧客に関するデータすべてを、一元的に把握したいと考えるでしょう。金融機関であれば、アセットクラスや契約先、地域間のエクスポージャーを単一のビューで把握したいと考えるでしょう。360度ビューとも呼ばれる単一のビューを利用すれば、顧客サービス担当者が必要とするデータが全て得られるため、より迅速な顧客対応が可能になります。また、不正を検知してその被害を食い止められる確率も高められます。顧客のデータすべてを一元的に把握できるので、GDPR(General Data Protection Regulation:一般データ保護規則)の遵守も容易になります。

通常、単一のビューを構築するには、相互に連携しない異なるデータベースのさまざまなデータタイプを統合する必要がありますが、すべてのデータタイプに対応できる単一のスキーマを見つけ出すのはきわめて困難です。また、新しいデータを追加する必要がある場合、古いスキーマは機能しないことがあります。

MongoDBのソリューション:MongoDBのアプリケーションデータプラットフォームはドキュメントモデルをベースに構築されているので、360度ビューの構築に最適です。MongoDBのデータベースは、リッチなカスタマーオブジェクトをサポートしており、形式に関係なくあらゆるデータタイプに対応可能です。これらのオブジェクトはドキュメントにフィールドを追加するだけで、いつでも拡充でき、またスキーマの移行は不要です。

DIRTやDIRTの軽減方法について詳しく知りたい方は、
ホワイトペーパー『DIRT and the High Cost of Complexity』(英語)をご覧ください。


ブログシリーズの続きはこちらにてご覧いただけます:Part2Part3Part4

New call-to-action
新規CTA