写真：クラウド Watch

　昨今急激に注目を浴びているAIの台頭により、それと対をなしてその重要性を再認識されつつある分析用データ基盤の再整備を行う企業が増えています。AIを信頼できるものにするためには、そのインプットとなるデータが信頼できるものでなければならないからです。 【画像】図1-2　一般的なデータ仮想化のイメージ 　しかし、今やクラウドやSaaSの進化で誰でも簡単に構築が可能となった結果、データのサイロ化が急激に進み、企業全体で活用が可能な統合的なデータ基盤が思ったように構築できていないというケースが散見されます。特に日本では、サイロ化された組織に合わせた個別の基盤づくりが主流となり、組織全体での最適化が難しいのも実情です。 　ですが全体で見ると、企業規模が大きくなればなるほど、そうしたサイロ化を助長する構築はコストやリソースの面で同時に無駄も招き、複雑さも助長するアーキテクチャとなっています。 　大規模な組織において、AIの活用を促し迅速な意思決定や業務への活用を行う基盤の構築には、場当たり的な構築ではなく、データのサイロを最小限にとどめ、さらに各データが流通し最大限活用されるような企業全体のデータアーキテクチャ＝青写真を描いた上で進めていく必要があります。 　本稿では、大規模な組織における、統合的なデータ分析基盤がなぜ構築できないのか、見落としがちなポイントを探り、目指すべき方向性について最新のアプローチを解説します。 ■ 大規模なデータ分析基盤構築における注意点 　1回目はまず、各組織が取り組む次世代のデータ分析基盤構築において、見落としがちな落とし穴や陥りやすい誤解について、例を挙げて見ていきたいと思います。 □a）データの民主化が招くサイロ 　「データの民主化」という言葉が出てきて久しいですが、そのスローガンの下に、クラウドネイティブなテクノロジーを導入し、ビジネス部門などの各ドメインへのデータの分散化を推し進めている例が散見されます。ですが、最新のテクノロジーというだけで安心し、適切なデータガバナンスやデータ管理を考えずに進めた結果、民主化どころか無政府状態、カオスを招く結果となることも珍しくありません。 　例えば、営業部門とマーケティング部門がデータ活用を行うために、それぞれが別々のテクノロジーでデータ基盤を立てた場合、その構築負荷や管理負荷は倍になります。さらに2つの基盤間でデータのやりとりが発生する場合、データのパイプラインは複雑化し、受け渡しをどうするか考える必要も出てきます。これが全部門に広がることを考えると、各部門間での管理や調整だけでは各部門の負荷は相当なものになるだけでなく、データ品質にも大きく影響が出てくるでしょう。 　また、共通の基盤を立てたとしても、そのデータ基盤がユーザーにとって使いづらいと感じられるものであれば、ユーザーはデータを自分のPCにダウンロードして使うなど、自分たち独自で使いやすい“シャドーIT”を立て、見えないデータサイロを生み出してしまう例も多々あります。 　民主化というのは、中央政府がしっかり機能し守るべきガイドラインがしっかり打ち出せていることと、それらがうまく機能するよう民衆のリテラシーを高める努力がなされている前提でなければ成り立ちません。特にクラウド環境では、誰でも簡単にデータ基盤/分析基盤を作れてしまうことをかんがみると、その分サイロ化・カオス化しやすい環境でもあるという認識が必要です。 　簡単にできてしまうからこそ、適切なデータガバナンスとそれに従うリテラシーが必要だということを忘れてはなりません。 □b）小さく始めて、大きくできない 　クラウド環境ではオンプレに比べると、柔軟性や弾力性が飛躍的に増しているため、PoCで最小限の検証を行い、小さく始めて必要に応じて規模を大きくする方針を取られることがほとんどだと思います。その「小さく始める」を単純なユースケースだけで考えてしまうと、後で大きな落とし穴にはまります。データ分析基盤で必要となるデータ処理や分析処理はさまざまだからです。 　例えば、車を購入する時に、軽自動車と大型車を比べて、安い方を買う、という人はいないと思います。大型車の輸送量が必要な時には大型車同士の比較はするでしょうが、軽自動車と比較しても意味がありません。 　ですが、データ分析基盤になると、なぜか途端にそのようなことが起こり得ます。大型車が必要だったにも関わらず、実際のユースケースを想定せずに単純な機能と価格だけを比べて、近くのコンビニに行くのにお手軽な軽自動車を買ってしまい、後に長距離で大量の貨物輸送に耐えられない、要するに業務に必要な多くのデータが処理できないことが判明するというケースです。データが処理できない上に、オートスケールで気づけば軽自動車50台分支払っていた、というようなことも起こり得ます。大規模な組織の基盤では、さまざまなユーザーがさまざまな処理を同時多発的に処理する必要があるということを念頭に置いておく必要があります。 　また、クラウドのサービスは、リソースが足りなければ追加すればよいという思想で生まれたサービスがほとんどであり、今あるリソースをできる限り有効利用するというオンプレ時代の発想があるサービスはほとんどありません。SDGsが叫ばれている世の中のはずが、クラウドの世界だけはリソースは無限にあるという発想です。 　ですが、予算は無限ではないのです。小さな規模でのPoCではとても安かったものが、規模が大きくなるにつれ、処理が終わらないどころか指数関数的にコストも跳ね上がる可能性があることを頭に入れておくべきでしょう。大規模なデータ基盤のワークロードは、単純な検索だけでなく、データのロード、追加、更新、削除、変換、統合、集約などが、さらにAIのワークロードになると、特徴量エンジニアリング、モデル学習、モデル推論、スコアリングなどを、バッチまたはリアルタイムで多重に効率よく実行する必要があり、ユースケースをある程度想定したPoCが必要です。 □c）データは1カ所に集めても使えない 　次世代のデータ基盤を構築するにあたって、1つのテクノロジー、1つの物理的な場所に取りあえずデータを集めようとしている、もしくは集めてきた、というお話をよく耳にします。いわゆるデータの一元化です。 　ですがそれをどのように使える状態に持って行くのかという肝心の部分の構想をほとんど耳にしたことがありません。多くのプロジェクトではそこは基盤を構築するデリバリ側、もしくは使う側の責任であり、構想を練る側の仕事ではないという考えなのかもしれません。 　しかし、大規模な組織では特に、入ってくるデータの種類、粒度、量は膨大です。通常、そのままの状態では分析には使えません。即座に消費できるデータとソースシステムそのままの生データは性質が異なります。生データを一般のユーザーが消費するということは、いわばレストランで料理を食べたいのに原材料をそのまま出されるようなものです。 　おいしい料理にするためには料理を作る過程が必要なのと同じように、データを使える状態にするにはデータを使える状態に料理する必要があります。データ分析のうち80％の仕事はデータをきれいにしたり使えるように整えたりするデータの準備と言われています。それらを個人がそれぞれ場当たり的に行うだけでも、膨大な労力を消費するばかりかやり方がまちまちなため、品質も安定しません。そのような品質のデータをAIに使ったとして、そのAIのアウトプットを果たして信頼できると言えるでしょうか。 　さらに、各々でデータ変換を行う場合、機密性の高いデータ要素がマスクされない可能性があり、個人情報保護法に違反したり、データ漏えいが起きた場合に組織に莫大な損害を与えたりする危険性もあります。 　安全で信頼できるデータをどのように生み出すかは、組織が全体的な方針として打ち出すべきものなのです。 □d）仮想統合≠アクセス可能 　データを1カ所に集める動きと同時に、既に分散しているデータを仮想的に統合しようという動きも目立ってきています。その解決策としてデータ仮想化のテクノロジー導入を考えている企業は多いのではないでしょうか。市場には純粋なデータ仮想化基盤のテクノロジーだけではなく、データカタログツール、ETLツール、BIツールまでが、データの仮想統合ツールとして名乗りを上げています。ですが、その多くが複数のデータソースのディクショナリ情報を閲覧してアクセスが可能である、という機能に過ぎません。先ほどの一元化を仮想的に実現するという発想です。 　もちろん、その機能は重要です。今やあらゆるところに存在するデータを効率よく利用するには、全てを一カ所に持ってくるのではなく、使いたい時に使えるよう接続を可能にしておくという発想は理にかなっています。ただし、問題は、アクセスが可能であることと、データ統合可能であることを、区別すべきだということです。 　本来仮想統合に必要な機能は、分散したデータソースにアクセスするだけでなく、それらのデータを組み合わせてユーザーがちゃんと使えることです。複数のデータにアクセスすると同時にすぐ組み合わせて（結合して）使える状態が、「データ統合」可能な状態です。データにはアクセスできるものの、先ほどの例であったようなデータをきれいに整備する作業を全てユーザーがやらなければならないのであれば、それはすぐ使える状態ではないということです。分散したデータをどのように安心してすぐ使えるように整備するか、一元化以上に全体的なデータアーキテクチャを考える必要があります。 　また、大きな組織であれば、それぞれ組み合わせるデータ量も大量なものになりますし、利用するユーザー数も大勢になります。そう考えると、単体のデータ基盤以上にデータ仮想化基盤は大規模になる可能性があり、各クエリの解析能力やデータ処理機能などがその規模に耐えられる基盤である必要が出てきます。 　さらに、利用に応じたデータの移動量も計算に入れる必要があります。クエリの解析能力と処理能力が低い仮想化基盤であれば、不必要に大量のデータを流通させてしまうことになり、ネットワーク負荷やコストに大きく跳ね返ってきます。 　単にアクセスできれば仮想統合が実現できる、という簡単な話ではないことに注意が必要です。 □e）ツール導入だけでは解決しないデータの管理 　データが増えすぎてどこに何があるかわからないという課題の解決策として、データカタログの導入を考えている企業は多いと思います。データは企業内のいたるところに分散しているため、どこに何があるのかを探し出してくれるデータカタログは夢のツールに思えるかもしれません。果たして本当にそうでしょうか？ 　データカタログはさまざまなデータソースからディクショナリ情報を抽出し、カタログ化してくれるツールです。ですが、何も整理されないままのデータをカタログ化しても、整理されていないデータが見つかるだけです。例えば、似たようなデータが多く存在する場合、そのうちのどれを使えばいいかまでは判断してくれません。 　また、ユーザーが使う業務用語と物理的なデータ項目がきちんとひもづけられていなければ、ユーザーは自分が使う言葉で適切なデータ項目を見つけ出すことができません。たとえひもづけられていても、そのひもづけがほかのユーザーにも通用するものでなければ、余計に混乱を招くことになります（例えば”売上”と言っても、グロスなのかネットなのか、人によって解釈が違うなど）。データカタログをうまく利用するには、どのような基準にのっとり定義づけを行い、誰が管理し、どう業務フローにのせるか、などを適切に決めて運用する必要があります。 　また、データカタログはデータ管理のごく一部を担うものであり、その他マスタデータ管理やデータ品質、アーキテクチャ、統合、セキュリティ、ライフサイクルなど、ほかにも管理すべき項目は多くあります。今後、AIが複雑化したデータ管理をサポートしてくれる可能性は大きいですが、あくまでサポートとして使うものであり、最終的な意思決定や運用を行うのは人間です。適切な管理者をアサインし、運用プロセスに載せるところまでがスコープに入っておらず、結果的にうまく維持管理できずツール代だけがかさむという失敗例をよく聞きます。データ管理において、ツールを導入しただけで解決する、というものはほとんどないのです。 ＊＊＊＊＊ 　今回は、大規模なデータ分析基盤の構築にあたって、5つの注意点を解説しました。次回からは、その注意点に対応するための、目指すべき方向性について解説していきたいと思います。 日本テラデータ株式会社　ワールドワイド・データ・アーキテクト　藪 公子 ・日本テラデータのデータ分析プラットフォームにおける、リファレンス・アーキテクチャ策定の責任者。ワールドワイドなデータアーキテクチャチームの一員としてインフォメーション・アーキテクチャの分野において日本をリードしている。 金融、通信、自動車、製薬など多岐にわたる各種業界において、将来を見据えたデータ活用の目的やデータ管理などのコンサルティングを行い、企業のデータ統合・分析基盤のアーキテクチャ策定や構築を支援。