鶴田：
データプラットフォームの構築でよくある課題として、箱だけ作って中身（データ）をどう使うのかが全然考えられていないケースが多々見受けられます。データの質や鮮度を維持するために、データをどう管理するのか、すなわちデータマネジメントをちゃんと考えていかないと、意味のないプラットフォームになってしまいます。

齋藤：
データプラットフォームとは、データを集めて分析・活用するデータ活用基盤です。企業内のあらゆるデータを収集し、システム内に蓄積していきます。蓄積されたデータを加工してシステム上で可視化できるように構築します。大量のデータをどうやって扱いやすいものにするかが、プラットフォーム構築のポイントです。

鶴田：
近年、プラットフォーム構築のハードルは下がっており、SnowflakeやTableau、パブリッククラウドなど使えるサービスが増えています。以前に比べるとかなり検討しやすくなっているといえるでしょう。

齋藤：
企業が収集・蓄積するデータには2種類あります。ひとつは構造化データで、売上データのように理解しやすく扱いやすいものです。もうひとつは、画像、音声、文字、位置情報、センサー情報など、定型的に扱えない非構造化データです。データ量の割合でいうと、構造化データが2割、非構造化データが8割といわれており、圧倒的に後者が多い状況です。

そのため、データプラットフォームを検討する際には、こうした 非構造化データをどう扱っていくのかの検討が必要になります。例えばメタデータをどう付与するのかもそうですね。

齋藤：
既存システムや他のクラウドサービスとの連携をどうするかは注意した方がよいでしょう。現システムからどのようにデータを取り出して、それをどう取り込むのかをきちんと見ておくべきです。具体的には、多少泥臭い作業にはなりますが、プラットフォームに格納すべきデータ一つ一つに対して、インターフェースや通信プロトコル、データ更新頻度などをしっかり定義していきましょう。

鶴田：
データの利用権限についても注意が必要です。収集したデータは誰がオーナーで、どこまで閲覧権限をもたせるのかについて迷われる企業が多いです。セキュリティに関する意識は高くもっておかなければいけません。

齋藤：
組織や担当者間でデータが分断されてサイロ化が起きるリスクもあります。大量のデータをどう管理していくのか、というデータマネジメントの問題はデータプラットフォームを構築する上で一番気を付けておきたいところです。

鶴田：
データプラットフォームを作ること自体が目的になってしまい、その後のデータ活用が進まないという問題です。実際に、ご支援している企業の中でも、この問題を抱えているところは多いです。

齋藤：
データ活用の号令をかけてプラットフォームを構築したものの、実際には使われずランニングコストだけかかっていたり、データを集めてはみたものの、PoCに時間がかかって活用にまで至らなかったりするケースが散見されます。また、同じようなデータが複数存在してしまい、どれが正しいデータなのかが分からない事態に陥ってしまったこともありました。データ活用するその都度、関係者にヒアリングが必要になってしまうと、そのやりとりだけで多大な時間がとられてしまいます。

これらの問題はすべてデータマネジメントで解決すべき問題です。

齋藤：
データプラットフォームを構築しても単にシステム内に大量にデータがあるだけでは意味がありません。どんなデータがあるのかわからない状態に陥ってしまうと、システムとしては使い物にならなくなります。
データは、ある一時点で固定されるものではなく日々更新されていきますので、時間の経過とともに、データの内容・品質が劣化してしまうリスクがあります。データ品質を維持する活動が必要で、それがデータマネジメントです。データマネジメントを行わないと、データの信ぴょう性も担保されなくなります。また、データそのものだけでなく、メタデータや、データ間の関係性、データの鮮度に関する管理もデータマネジメントで求められる要素です。

鶴田：
データは日々の更新をキャッチアップするプロセスをきちっと定義しておかないと、すぐに使えない物になってしまいます。

収集したデータを用途に沿って最適な活用ができるようデータマネジメントの仕組みとルールを作るべきです。システムをリリースする過程でこうした要素を検討した方がよいでしょう。

データマネジメントの取り組みには、QCD^(*)に加えて、RSの視点が必要になります。RSとは、リスク（Risk）、サポート(Support)のことです。

ここでリスクとは何かというと、例えばGDPRや改正個人情報保護法に伴うプライバシーポリシーの話です。データの取り扱いに関する法規制が変わることで想定外の法的トラブルに巻き込まれるリスクがあります。そうした問題をクリアにしていかなければなりません。また、現場をサポートする体制づくりも欠かせません。プラットフォームを構築し、ルールを作っただけでは実質誰も使わないことになってしまいますので、活動を推進していくためにサポートの要素も大切です。

• ^*

  QCD：品質(Quality)、コスト(Cost)、納期 (Delivery)

齋藤：
データマネジメントには多くの人的リソースが必要です。一方、大変な割にその価値がなかなか伝わりにくく途中で挫折してしまうケースが多いです。データ活用でビジネス変革をしていくには、継続的なデータマネジメントが必要不可欠です。トップダウンでその価値をメッセージとして伝えていくことがよいでしょう。

齋藤：
理想とするDXのITアーキテクチャーには、これまで述べてきた「スピード・アジリティ」や「データ活用」の要素が求められますが、そもそもの大前提として、今のシステムをどう変えていきたいのかが重要な検討のポイントになると思っています。

鶴田：
ITアーキテクチャーを検討する際、どうしてもシステム目線だけになってしまうケースが多いです。それはIT部門の中だけで検討してしまっていることが原因と考えられます。システムをどこから変えていくかは、ビジネス側の要求度から考えていくべきであり、ビジネス部門との会話が必要です。「会社として実現したいことは何か」を意識し、いろいろな人を巻き込んで活動できるとよいですね。

齋藤：
NRIでは、まず、「現状がどうなっていて今後どのように変えていきたいのか」を考えるところからご支援させていただいています。何かお悩みがありましたらぜひお声がけいただければ幸いです。 https://www.nri.com/jp/service/scs/dx/digital_architecture