結論

データ部門は大福帳を中央集権的にユーザーに提供すべきでない。
なぜなら分析ユーザーの求めに応じて、大福帳を作って配布するということは、ビジネス上の本質的な課題を、テクノロジーの問題にすり替えるということであり、焼け石に水だからである。

データ分析者からの「購買と発送を横断して分析したいのですが、JOINキーは何ですか？」という質問は多い。これは、一つの購買に対してどのくらいの発送が紐づくかを理解していない、という分析者のビジネスプロセスの理解不足に由来する。

しかし、この問題を「一般ユーザーにはJOINなんてできないのだ」というテクノロジーの問題にすり替えてはならない。
JOINして渡したところで、結局は「JOINキーは何ですか？」という質問が「このカラムのNULLは何ですか？」に形を変えて繰り返されるだけである。

そしてデータ部門はこれはメタデータ整備の不足だと、またテクノロジーの問題にすり替え、データカタログの導入を考え始める。

もっと悪いことに、大福帳にすることで、複数のテーブル（ビジネスプロセス）が相互作用して、キー情報が失われ、かえって元の問題よりも複雑化する。

だからデータ部門は分析ユーザーに大福帳を提供してはいけない。

本記事の目的

以下では、大福帳とビジネスプロセスの関係について更に詳しく解説する。

分析データは何を描写するのか？

ビジネスにおいて、データに基づいた意思決定は極めて重要である。顧客の購買行動の分析、キャンペーン施策の効果測定、在庫管理の最適化など、あらゆるビジネスプロセスにおいて、データは羅針盤の役割を果たす。しかし、分析に用いられるデータが現実のビジネスを正確に描写していなければ、その分析結果は誤った方向に導く危険なものとなる。データがビジネスの実態を歪めて表現していれば、そこから導き出される意思決定は、誤解に基づいた、的外れなものになってしまう。

したがって、分析に用いるデータモデルの構造は、ビジネスの成功を左右する極めて重要な要素である。単にデータを収集し、蓄積するだけでは不十分である。ビジネスの流れ、プロセス、そして各要素間の関係性を正確に反映した形で、データモデルを設計する必要がある。その中で、しばしば「大福帳」と呼ばれる、あらゆる情報を1つの巨大なテーブルに集約する設計パターンが用いられることがある。一見すると、このアプローチは「どんな分析でも容易に行えるようになる」と思われがちである。しかし、実際には、異なるビジネスプロセスを無理やり1つのテーブルに押し込めてしまうことで、データの解釈を困難にし、分析の正確性を損なうという大きな問題をはらんでいる。

本記事では、まず「大福帳がどのようなビジネスを描写しているのか」を分析し、その構造がもたらす潜在的な危険性を明らかにする。

大福帳が描写するビジネスは単一の巨大トランザクションである

「大福帳」とは、本来であれば別々のテーブルで管理されている複数のビジネスプロセスや、異なるコンテキストを持つデータを、1つのテーブルに集約した状態を指す。例えば、あるECサイトにおいて、「カード登録」、「商品の購入」、「商品の発送」といった、本来は独立して発生するプロセスがあったとしても、それらを全て単一のテーブルに詰め込んでしまう。その結果、テーブルの構造は以下のような、非常に横に長いテーブルとなる。

purchase_id, user_id, card_number, card_registered_at, card_holder_first_name, item_name, price, shipment_status, shipped_at, ...

このテーブルでは、カード情報、購入情報、発送状況といった、本来は異なるタイミングで発生し、異なる意味を持つデータが1行にまとめられている。まるで、「カード登録 → 商品購入 → 発送」という一連の流れが、**1つの巨大なビジネストランザクション（=Unit of Work） **として扱われているかのように見える。

しかし、現実世界のビジネスは、多くの場合、複数のプロセスがそれぞれ独立したタイミングで、非同期的に進行している。ECサイトの例で考えてみる。

カード登録: ユーザーは決済手段としてクレジットカードを登録する。具体的な購入予定がなくても、カード情報だけを先に登録しておくことができる。
商品の購入: ユーザーは、欲しい商品を選び、支払い手続きを行う。既にカードを登録していれば、その情報を使ってスムーズに購入できる。一方、カードを登録していない場合は、購入時に新たにカード情報を入力する必要がある。
商品の発送: 購入手続きが完了した商品は、倉庫でピッキングされ、梱包され、配送業者に引き渡される。購入後すぐに発送される場合もあれば、在庫状況や配送条件によっては、発送までに時間がかかる場合もある。また、複数の商品を同時に購入した場合、商品ごとに発送タイミングが異なることも考えられる。場合によっては、複数回に分けて発送されることもある。

このように、現実のビジネスでは、それぞれのプロセスは独立した小さなUoWとして捉えることができる。購入はしたものの、在庫不足やシステムトラブルなどの理由で、発送が遅れることもあり得る。こうした様々な状況を適切にデータモデルに反映するためには、プロセス（小さなUoW）ごとにテーブルを分割し、それぞれが持つステータスやコンテキストを独立して管理できる設計が望ましい。

一方、大福帳では、上記のような独立したプロセスを、全て1行のデータに無理やり押し込んでしまう。その結果「カードが登録されていないのに購入が記録される」、「発送されていないのに発送ステータスの欄がNULLになる」といった、ビジネスの実態としては不自然な状態が同居するテーブルが生まれてしまう。これは、テーブルが単一の巨大なビジネストランザクションに縛られているためであり、本来は独立しているはずのプロセス間の連携の有無や、それぞれのプロセスの進行状況を表すステータスが、1つのテーブルの中で混在してしまうことが原因である。

大福帳を分析に使うメリットと注意点

大福帳を使用する際の最大のメリットとして、しばしば挙げられるのが、複数のプロセスを「横断的」に一気に分析できるという点である。確かに、カード登録情報、購入情報、発送情報などが1つのテーブルにまとまっていれば、「カード登録 → 購入 → 発送」という一連のフローを、比較的単純なクエリで追跡できるという利便性がある。例えば、

ユーザーがカードを登録してから、実際に商品を購入するまでの平均日数を算出したい
商品の購入から発送までの間に、どれだけのタイムラグが発生しているかを測定したい

といった分析を行う場合、大福帳であれば、複数のテーブルをJOINする手間が省けるため、クエリが比較的簡単になる場合がある。これは、データアナリストにとって、「データの全体像を容易に把握できる」、「素早くインサイトを得られる」というメリットとして映るかもしれない。

しかし、全分析ユーザーにすべてのビジネスプロセスの知識が必要になる

一方で、大福帳を使用すると、分析を行う全てのユーザーが、全てのプロセスの詳細な知識を把握しなければならないという、大きなデメリットが発生する。
例えば、マーケティング部門のアナリストは、本来であれば購入データや顧客属性に関するデータさえ理解していれば、効果的な施策を立案できるはずである。
しかし、大福帳では、発送ステータスやカード登録のタイミングなど、マーケティング分析には直接関係のないコンテキストまで理解することが求められてしまう。
逆に、物流部門の担当者が、商品の発送状況に関する分析を行いたい場合にも、本来は関係の薄い購入処理やカード登録に関するカラムの意味や、それらのカラムがNULLになる条件などを理解する必要が生じる。

このように、「本来は不要な知識まで把握しなければならない」という状態は、分析作業における認知的負荷を高め、分析の効率を低下させるだけでなく、誤ったカラムの解釈による分析ミスのリスクを高めることにもつながる。データ構造が複雑化すればするほど、ユーザーは「どのカラムがどのプロセスに対応しているのか」、「NULL値はどのような意味を持つのか」といったことを、逐一確認しなければならなくなる。これは、分析作業の属人化を招き、組織全体のデータ活用力を低下させる要因にもなり得る。

NULLに意味を持たせてはならない

大福帳において、最も大きな問題の1つと言えるのが、本来はありえないNULLがビジネス上の意味を帯びることである。本来であれば、例えば「発送情報」は「発送プロセス」のテーブルにのみ存在し、未発送の状態であれば、そのレコード自体が存在しないか、あるいは発送ステータスを管理する独立したテーブルで適切に状態が管理されているはずである。ところが、大福帳では、発送ステータスに関するカラムが全てのレコードに含まれているため、「購入は行われたが、まだ発送はされていない」、「カード登録は行われたが、まだ購入は行われていない」といった、様々なケースでNULL値が発生してしまう。

ここで問題となるのは、NULL値の解釈が一意に定まらず、曖昧になりやすいという点である。例えば、「shipment_status」カラムがNULLである場合、以下のような、ビジネス的には全く異なる複数の意味を持つ可能性がある。

まだ発送処理が行われていない
発送処理は行われたが、何らかの理由でステータスの更新に失敗した
注文がキャンセルされたため、発送は行われない
そもそも購入自体が存在しない（カード登録のみが行われた）

これらの状態を正確に区別するためには、本来であれば、それぞれのプロセスに対応した独立したテーブルで、ステータスを管理する必要がある。しかし、大福帳では、全ての情報が1つのテーブルに押し込められているため、NULL値だけでは、そのレコードがどのような状態にあるのかを正確に判断することができない。その結果、分析結果に誤差が生じたり、誤った解釈に基づいた施策が実行されたりするリスクが増大する。

独立したプロセスを無理に結合した弊害

これらの問題は、突き詰めると、「本来は独立しているはずのプロセスを、無理やり1つのテーブルに押し込んでしまった」ことに起因している。それぞれのプロセスを独立したテーブルとして管理し、必要に応じてJOINすれば済むところを、「大福帳」という形で常に結合してしまったために、一見便利そうに見える一方で、データの解釈を困難にし、分析の正確性を損なうという、非常に扱いにくい構造になってしまっている。

ユーザー主導の大福帳

ここまで述べてきた大福帳の弊害は、全てのケースにおいて一律に当てはまるわけではない。例えば、各ユーザー部門が自分たちの業務プロセスを深く理解した上で、

「今回は、この特定の分析テーマに限定して、あえて複数のプロセスを串刺しにしたテーブルを作成する」
「期間限定のキャンペーンの効果を測定するために、データを横断的に見た方が都合が良い」

といった、明確な目的を定めた上で大福帳的な構造を利用するのであれば、それは問題にはならない。分析者自身が、NULL値や各カラムの意味を十分に理解し、適切に扱うことができるのであれば、大きな混乱を招くことなく、むしろ分析の効率化に寄与する。

中央集権的な大福帳は危険である

一方で、危険なのは、データ部門がトップダウンで、現場のユーザーに対して大福帳を渡すケースである。データ部門が、巨大なテーブルを分析基盤として提供してしまうと、分析ユーザーは、「このNULL値は一体何を意味しているのか」、「そもそも自分の担当するプロセスに関係のないカラムが多すぎて、理解できない」といった混乱に陥ってしまう。その結果、せっかく構築した分析基盤が、逆に現場で活用されなくなったり、誤った使い方をされてしまったりする危険性が高まる。

「3NFをそのまま渡す」のはどうなのか

運用系のデータベースが第三正規形（3NF）で設計されている場合、それをそのまま分析用途に転用すれば良いのではないか、と考える人もいるかもしれない。しかし、3NFはあくまでも、データの整合性を保ち、更新処理を効率化するための設計であり、必ずしも分析用途に適しているわけではない。分析系のシステムには、分析特有のデータの参照パターン、集計処理のロジック、データの履歴管理など、運用系とは異なる要件が求められる。

そのため、分析に用いるデータは、ビジネスプロセスを適切に捉えた上で、分析しやすい形に再編成する必要がある。大福帳のように、あらゆるデータを1つのテーブルにまとめるのではなく、かといって、3NFのまま「ユーザーが必要に応じて、自由にJOINする」と丸投げするのでもなく、ビジネス上の主体（Dimension）と、それらの主体間の関係性（Fact）を明確に定義したDimensional Modelingや、データの変更履歴を効率的に管理するためのData Vaultなどの、分析用途に最適化されたデータモデリングのアプローチを用いて、データを整備することが望ましい。

主体と主体同士の関係性を中心としたモデル設計

Dimensional Modelingの基本的な考え方

分析系のデータモデルとして、広く知られているものにDimensional Modelingがある。これは、ビジネスにおける「主体（Dimension）」と、それらの「関係性やイベントを示すFactテーブル」にデータを分割するアプローチである。例えば、ECサイトにおける商品の購入履歴をFactとして定義し、

顧客（Customer）
商品（Item）
時間（Date/Time）
店舗や発送拠点（Location）

などをDimensionとして切り出す。そして、Factテーブルには、「購入金額」、「購入数量」、「購入日時」などの、数値データや、各Dimensionへの外部キーを格納する。これにより、「誰が（Customer）、いつ（Time）、何を（Item）、どこで（Location）、どれだけ購入し、その結果、いくらの売上が発生したのか」という、ビジネス上の重要なイベントを、明確に表現することができる。

このように、主体同士の「つながり」の強さを数値化することで、分析者は「商品Aを購入した顧客の平均年齢はいくつか」、「特定の期間における、特定の店舗の売上合計はいくらか」といった、様々な角度からの集計や分析を、柔軟かつ効率的に行うことができるようになる。大福帳のように、あらゆる情報を1行に押し込めるのではなく、分析上の切り口となるDimensionを明確に分割し、Factテーブルにビジネスイベントの測定値を格納するという仕組みを採用することで、ビジネスプロセスを正確かつ柔軟に描写することができる。

Data Vaultとの関連

一方、Data Vaultは、主にデータウェアハウスの設計に用いられるデータモデリング手法であり、Hub（ビジネス上の主体）、Link（主体間の関係性）、Satellite（属性情報や履歴データ）という、3種類のテーブルを組み合わせて、Single Version of the Truthを構築する。
Data Vaultは「ビジネス上の主体を明確に定義し、主体同士の関係性を適切にモデリングする」という点においては、Dimensional Modelingと共通する部分がある。
重要なのは、どのようなデータモデリングのアプローチを採用するにせよ、「ビジネスの実態を正確に捉える」ことが最も重要であり、「とりあえず分析ユーザーの要望に答えて大福帳にする」という決定は避けるべきである。データモデルは、現実のビジネスの写像であり、その設計が分析の信頼性を左右する。

どのような形でユーザーにデータを提供するか？

データモデルの観点からはDimensional ModelやBusiness Vaultの形式で渡すのがベストである。また、分析ユーザーやデータを消費する部門が個人的に大福帳を作るのは全く問題がない。

大福帳はデータ部門の努力の証でもある。大福帳はデータ部門が自分達が自由に変更出来る範囲で、最大限分析ユーザーの意見を反映しようとした結果である。データ部門を責めてはならない。

本記事はあくまで大福帳をエンドユーザーへのデータ提供の標準フォーマットにしてはならないという主張である。

PR

データのNULLの意味不明さに頭を抱え、データカタログ導入を考えたことはありませんか？
それはデータモデリングの問題かもしれません。

私たちRAKUDEJIは「世界一Snowflakeに詳しい企業」を目指し、その圧倒的な専門知識で巨大企業のデータ基盤改革を支援しています。
ビジネスを映すデータモデル構築から、Data Vault等の最適なアーキテクチャの提案、Snowflakeを駆使した分析基盤構築まで総合的に支援します。

まずはお問い合わせから、あなたの課題をお聞かせください。

分析ユーザーに大福帳を提供してはならない

結論