第1回～3回までで、BIが機能しない原因として、KPI設計やデータ定義の問題を見てきました。

これらはすべて「何を測るか」「その意味は何か」というテーマでした。

第4回では、それをさらに一歩進めて、「どう構造化するか」という問題に踏み込みます。

すなわち、データモデル設計です。

BIがうまく機能していない企業では、しばしば「データはあるのに分析できない」という状況が発生します。

データは蓄積されている。

ツールも導入されている。

しかし、欲しい切り口で集計できない、分析のたびにデータ加工が必要になる、といった状態です。

この原因は明確です。
データが分析のための構造になっていないのです。

多くの企業では、データは業務処理のために設計されています。

つまり、トランザクション処理を効率よく行うための構造（いわゆる正規化されたデータ構造）になっています。

この構造は、業務処理には適していますが、分析には適していません。

例えば、受注データ、出荷データ、請求データがそれぞれ別のテーブルに分かれており、さらに商品や顧客の情報も複数のマスタに分散している。

このような構造では、「顧客別の売上を商品カテゴリごとに月次で分析する」といった処理を行うために、複雑な結合や加工が必要になります。

その結果、何が起きるか。

・分析のたびにデータ加工が発生する

・同じ分析でも人によって結果が変わる

・BIツールのパフォーマンスが低下する

そして最終的には、「使いにくいからExcelでやる」という状態に戻ってしまいます。

この問題を解決するために必要なのが、「分析のためのデータモデル」です。

BIにおいて一般的に採用されるのが、いわゆる「スター型スキーマ」と呼ばれる構造です。

これは、データを大きく二つに分けて設計する考え方です。

一つは「Fact（事実）」です。売上、受注、数量といった、測定される対象となるデータです。

もう一つは「Dimension（軸）」です。顧客、商品、時間、地域といった、分析の切り口となるデータです。

例えば売上であれば、

Fact：売上金額、数量
Dimension：顧客、商品、日付、地域

といった形になります。

この構造の重要なポイントは、「どの軸でも自由に切って集計できる」ことです。

顧客別、商品別、月別、地域別といった分析を、同じデータ構造の上で一貫して行うことができます。

ここで重要なのは、この設計は単なる技術的な工夫ではないという点です。

むしろ、「企業の業務をどのような視点で捉えるか」というビジネスの問題そのものです。

例えば、「顧客とは何か」「商品カテゴリはどの粒度で管理するのか」「時間は日単位か月単位か」といった決定は、すべてビジネス上の意味を持ちます。

そして、この定義が曖昧であれば、データモデルも曖昧になります。

また、FactとDimensionの関係は、業務プロセスそのものを反映しています。

売上という事実は、顧客と商品と時間の交点で発生する。

この関係をどのように定義するかは、業務の理解なしには設計できません。

つまり、データモデル設計とは、単なるデータベース設計ではなく、
業務構造をデータとして表現する行為です。

ここが理解されていない場合、BIは必ず失敗します。

IT部門が技術的にデータを整備しても、ビジネスの意味が反映されていなければ、現場では使われません。

一方で、ビジネス側が要求だけを出しても、構造として設計されていなければ、実装は破綻します。

さらに重要なのは、このデータモデルが「共通基盤」になるという点です。

分析のたびに個別のデータ加工を行うのではなく、あらかじめ分析しやすい形でデータを整備しておく。

この基盤があることで、誰でも同じデータを使って同じ結果を得ることができるようになります。

ここまで見てきたように、BIの成否は、ツールではなく、KPIでもなく、最終的にはこのデータモデルに大きく依存します。

そしてこの設計は、ITだけで完結するものではなく、ビジネスと一体で行われるべきものです。

言い換えれば、BIとは「データの可視化」ではなく、
業務構造をデータとして再構築するプロセスです。

次回はいよいよ最終回として、ここまでの議論を統合し、「BIを機能させるための実践的アプローチ」を整理します。

指標アーキテクチャをどのように設計し、組織に定着させるのか、その具体的な進め方を解説します。

合同会社タッチコア　小西一有

[関連ブログ]
BI 第1回：BIはなぜ失敗するのか ― ツールではなく構造の問題
BI 第2回：KPIはなぜ機能しないのか ― 指標設計の落とし穴
BI 第3回：なぜ数字は信用されなくなるのか― データ定義とガバナンスの問題