データ基盤の構え方は、データ配置の観点から大きく分けて2種類あります。一つは、1か所にデータを集め、中央集権的に管理することを主とする中央集約型。もう一つは、データを分散させたまま管理を任せ、ルールとポリシーだけで統制して公開を促す分散型です。大きな分かれ目なので最初に考えておく必要があります。
UCAの時代に優先すべきは、スケーラビリティとアジリティ
データ基盤の目指す姿として掲げたゴール（理想像、最適解）は、今時点のものです。ゴールの正しさもわからなければ、道半ばでゴール自体が変化することもあります。
ゴールの変化を与える要因には、以下のようなものがあります。
- 市場や競合の変化
- 事業改革
- 予算の変動
- 新しいテクノロジーの登場
特に5年後10年後を見据えるというのなら、ゴールが変わることを前提にしても良いくらいです。
VUCAの時代、企業で考えるべきなのは、変化に対するリスクであり、ITで言えばスケーラビリティとアジリティの確保です。特に規模の大きい企業ほど、基盤システムを考えるうえで重要になります。
コンサルタントの罠
多くのコンサルタントは、データ基盤のソリューションとして、オールインワンの製品や、一つのDBを中心にしたアーキテクチャを見せてきます。具体的には以下のようなものです：
- 生データストアとデータベースをオールインワンにしたもの
- AIを搭載した分析ツール
- データレイク・データベース・ETL・カタログを組み合わせた「エンタープライズDB」
これらはいずれも会社中の全データを一つのDBに集める、という思想に基づいているものが多いのです。
しかし、これらは「わが社の製品」のスコープであったり、「我々が過去に構築したものは」を示しているに過ぎないことに注意したいと思います。彼らはまだ 1 社たりとも 10 年間追跡していません。
一方、外部業者の主張する失敗例を挙げると、以下のようなものがあります。
マスタは一意であるという前提で動いていたがそうではなかった- 表記ゆれや入力ルールが甘いためデータが統制されていなかった
これらの失敗理由を一言で言えば「お膳立てが旨くいってないから駄目でした」ということです。
しかし、我々は、お花畑の夢の国に存在しているデータ群を前提にしているわけではありません。そんな頭の中の国でデータ基盤を作りたいわけでもないのです。
従来の中央集約型は扱いに要注意
中央集約型のデータ構造は、中央集権型の管理ともいえます。
中央集権型の最大のメリットは、統制を効かせやすいことです。ただしこれらは、「中央管理のスキルの高さ」「環境変化が少ない」「スピード感不要」という３つの要素に支えられていることも認識すべきです。
専門知識を強く反映させる必要がある
データ基盤にかかわらず、スピードよりも一貫性とコンプライアンスが重要なもの、例えば、規制遵守、セキュリティ管理、財務報告、人事関連、法的手続きにかかわるものは、多くの場合、中央集権型にメリットが出ます。これらは専門的な深い知識を持ったメンバーにより、適切なガバナンスを効かせられることが重要です。
しかしながら、中央の管理組織が、専門スキルの無い状態、すなわち薄い知識の元に何となくルールを決めてしまう場合や、単純に作業を請け負うようなスキルしかない場合、恐ろしいデメリットにしかなりません。
新しいテクノロジの登場に対応しづらい
中央の構造をいっぺんに変えなければならなくなったときには目も当てられません。例えば、リレーショナル DB のみ考えてたところ、グラフデータベースや非構造データが主流となり対応できなくなった、AIの登場で生成データが爆発的に増え、データ収集が物量的に不可になった、等の事態が発生します。
末端の変化に合わせて逐一付き合う必要がある
中央集権は変更承認、ルール再編などに時間を要します。その結果、ユーザーは中央の管理組織を見限って、独自で様々なことを始めるようになります。
過度に統制をとってはならない
統制をとる必要がなく、むしろ状況による自由度が必要なものまで管理し始めると管理が破綻します。物の一面だけ見た統一ルール作りにはじまり、見落としていた発見とともに無数の条件分岐を追加したルールは目も当てられません。規則によっては各部門に移譲すべきこともあります。統制は専門知識が低い状態で触れると痛い目を見ることになります。
誰にでも使えて、誰にも使えないシステムが出来上がる可能性がある
全方向受容化という、予期しないコストを生むことがあります。たとえば「グローバルで共有するから英語を併記せよ、日本の本社で使えるよう日本語訳せよ」このような要求がいかに多くのコストを生むか想像できるはずです。
なお、AIが発達した今、ストレージ集約型にすることも一定の効果があることは断っておきます。その場合は局所的ストレージ＆局所的AI＋全体フェデレーション型AIという構成を考えることになります。
分散モデルを推奨
大規模な企業で、データ基盤に必要なのは、統合モデルではなく参照モデルを中心とした構造です。
基本的にはドメインベースの参照アーキテクチャを考える
組織全体のデータを分散させます。逆に、考え方は一貫させます。各ドメインに対して、たとえば以下を求めるようにします。
ドメインベースの参照アーキテクチャを考える
組織全体のデータを分散させます。逆に、考え方は一貫させます。各ドメインに対して、たとえば以下を求るようにします。
- データ仕様
- アクセス方法
- 公開データの精査
- 中央ルールの適用
- 結合方法、利用方法、利用例の公開
- データサンプル
各事業部署、機能部署で独立したシステムを持つ
各事業部署、機能部署で独立したシステムと独立した分析システムを持ち、それらがサイロではなく、エンタープライズ全体に公開され、容易に参照され、利用される形をイメージします。
実際には・・・
ドメインベースとはいったものの、実際にやるとしたら、個社、拠点、地域を一つの塊とすることが多いと思われます。統制がとりやすく管理の独立性のある境界線に合わせることになるでしょう。ただし、独立性の境界線でデータを持つことは、サイロ化の危険性も同時に保有することも意識してください。
「One Source」の正しい理解
「One Source」を掲げるコンサルタントは多いですが、「One Source」イコール「One Storage」ではありません。データリネージの先が同一であり、データの権威 (Authority) が一つであればれば One Source です。正確には、One Source of Truth です。
※ （注意）さらっと「大規模なら分散型」と言っていますが、厳密にはいろいろ考慮する必要があります。
コメント