経営会議のダッシュボードと営業部門の集計表で売上が違う。昨日確認したBIの値が、今日見ると過去分まで変わっている。このような問題が起きたとき、ETLの不具合だけを疑うと調査は長期化します。数字の不一致は、指標の定義、集計粒度、対象期間、マスタの版、取消処理、更新時刻など、データが届くまでの複数地点で発生するからです。
正解と思う数字を先に選ぶのではなく、比較条件をそろえ、表示値から元データへ逆向きにたどります。差が初めて生じた地点を特定し、その証拠を恒久的な品質管理へ引き継ぐ調査フレームです。
解決の要点は、どちらの数字が正しいかを先に決めることではありません。レポートに表示された値から元データまでを逆向きにたどり、各地点で何が選別・変換・集計されたかを証拠とともに確認することです。その道筋を可視化するのがデータリネージュです。
最初に「同じ条件を比べているか」を固定する
調査の出発点はデータ基盤ではなく、比較条件の合意です。「4月の売上」と言っても、受注日・出荷日・売上計上日のどれを基準にするか、税・値引き・返品をどう扱うかで値は変わります。まず双方の数値について、指標名、対象組織、期間、粒度、通貨、抽出時刻、フィルター、除外条件を一枚の比較票に記録します。
| 不一致の現れ方 | 主な原因候補 | 最初に確認すること |
|---|---|---|
| 全体が一定率でずれる | 税、通貨換算、単位、配賦 | 表示単位と計算式、換算レートの適用日 |
| 特定部門だけずれる | 組織マスタ、権限制御、部門フィルター | 組織コードの版と集計対象 |
| 月末だけずれる | 締め処理、遅延到着、取消・再計上 | 締め時刻と増分取込の境界 |
| 明細件数は同じで金額が違う | 重複、丸め、計算列、結合条件 | 主キー単位の差分と中間計算 |
| 過去値が後日変わる | 履歴管理、マスタ上書き、再処理 | スナップショット方針と再計算範囲 |
| 閲覧者ごとに違う | 行レベル権限、個人フィルター、キャッシュ | 同一権限・同一条件での再現 |
比較条件を固定せずにSQLやパイプラインを調べ始めると、技術的には正しい二つの数字を延々と比較することになります。調査票には、問題を発見した画面のURL、スクリーンショット、実行日時、利用者、期待値と実績値も残します。
データリネージュは「数値の証拠経路」である
データリネージュは、データがどこで生まれ、どの処理を通り、どの成果物で使われたかという系譜です。BIでは一般に、レポート、セマンティックモデル、変換処理、DWH、連携処理、業務システムの順に上流へたどります。ツールが表示する接続図だけでなく、業務上の意味と責任者を結び付けることが重要です。
たとえばMicrosoft Power BIのリネージュビューは、ワークスペース内のレポート、セマンティックモデル、データフローと外部依存関係を確認でき、上流・下流の影響調査に利用できます。ただし、画面に接続が見えることと、指標の意味まで説明できることは別です。技術リネージュに、KPI定義、データ責任者、品質ルール、更新頻度を補完して初めて経営判断の根拠になります。
根拠を追跡する7つの手順
- 事象を再現する：同じ利用者権限、同じフィルター、同じ更新時刻で差を再現します。
- 表示式を確認する：BI側のメジャー、計算列、暗黙の集計、丸め、NULLの扱いを確認します。
- 粒度をそろえる：伝票、明細、顧客、日次など、比較する最小単位を決めて差分キーを抽出します。
- 中間地点で照合する：セマンティックモデル、データマート、DWH、ステージングの順に件数・金額・キーを比較し、差が生じた区間を狭めます。
- 変換規則を読む：結合、フィルター、名寄せ、配賦、履歴化、増分抽出の条件を処理時点の版で確認します。
- 元データと業務事実を照合する：業務システムの記録だけでなく、計上・取消など実際の業務ルールに合うかをデータ責任者と確認します。
- 原因と再発防止を登録する：修正箇所、影響範囲、再計算対象、恒久対策、責任者を問題管理台帳に残します。
差分を一度に全件調べる必要はありません。総額の差を説明できる代表キーを選び、上流へ同じキーをたどると効率的です。差分が発生した最初の地点が見つかれば、その地点の入力・出力と変換条件に調査を集中できます。
調査台帳に残すべき情報
| 項目 | 記録内容 | 目的 |
|---|---|---|
| 指標定義 | 計算式、基準日、対象・除外条件、単位 | 意味の違いを切り分ける |
| データ契約 | 提供元、スキーマ、更新頻度、遅延許容 | 入力条件を明確にする |
| 処理証跡 | ジョブID、実行時刻、コード版、入出力件数 | 再現可能性を確保する |
| 差分サンプル | 業務キー、各地点の値、最初に差が出た地点 | 原因区間を特定する |
| 影響範囲 | 下流レポート、利用部門、対象期間 | 訂正と周知の範囲を決める |
| 承認 | データ責任者、システム責任者、確認日 | 正しい値の根拠について合意する |
EAとDMBOKで「再発しにくい構造」に変える
エンタープライズアーキテクチャ（EA）の観点では、数字の不一致はデータだけの問題ではありません。業務アーキテクチャのKPI定義、データアーキテクチャのモデルと流通、アプリケーションアーキテクチャの責任分界、テクノロジーアーキテクチャの実行・監視がつながっているかを確認します。個別レポートの修正で終わらせず、どの業務能力がどのデータに依存するかまで整理すると、変更時の影響分析が可能になります。
DAMA-DMBOKの観点では、リネージュはメタデータ管理だけに閉じません。データガバナンスで意思決定権を定め、データ品質で判定基準を置き、データ統合で変換を管理し、参照・マスタデータ管理でコードの一貫性を保つ横断的な仕組みです。特に経営KPIに直結する重要データ項目を先に選び、責任者、データ管理担当者（データスチュワード）、品質ルール、リネージュを優先整備すると投資効果を説明しやすくなります。
再発防止の実務チェックリスト
- 同じKPIを複数レポートで再実装せず、承認済みのセマンティックレイヤーに集約する
- 指標カタログに定義、計算式、責任者、基準日、変更履歴を登録する
- パイプラインごとに入出力件数、重複、欠損、金額差を自動監視する
- スキーマや変換ロジックの変更時に下流影響を確認し、承認を記録する
- 重要レポートは更新時刻、データ鮮度、認定状態を利用者に表示する
- 障害後はDWH受入テストとデータ照合へ回帰テストを追加する
- セルフサービスBIのガバナンスとして、公開・認定・廃止のルールを定める
専門診断：数値不一致を6層に分解する
数値差をSQLの誤りだけで説明しようとすると、調査が長期化します。まず定義、識別、時点、変換、配信、権限のどこで差が生じたかを切り分けます。データリネージュは矢印の図ではなく、各層で値がどう作られたかを示すメタデータと実行証跡の集合です。
| 原因層 | 代表例 | 必要な証拠 |
|---|---|---|
| 業務定義 | 受注と請求、速報と確定、税・通貨が違う | 用語集、KPI定義、承認版 |
| 識別・粒度 | 顧客名寄せ、明細重複、履歴キーが違う | 論理モデル、キー対応、重複規則 |
| 時点 | 締め、タイムゾーン、遅延到着、訂正反映が違う | スナップショット時刻、更新履歴 |
| 変換 | 結合、除外、集約、丸め、SCD適用が違う | 列レベル変換、コード版、実行ID |
| 配信 | キャッシュ、更新失敗、抽出版が違う | 更新ログ、モデル版、配信時刻 |
| 権限 | RLSや組織範囲により母集団が違う | 利用者コンテキスト、権限ルール |
比較条件を一意に記録する
調査開始時に、指標、期間、組織、通貨、締め版、権限、抽出時刻を「比較コンテキスト」として固定し、調査IDにひもづけます。同じ画面でも条件が違えば、比較対象は異なります。この一枚を作るだけで、再現不能な口頭比較を減らせます。
リネージュを5種類のメタデータで構成する
| リネージュ | 表すもの | 利用場面 |
|---|---|---|
| ビジネス | KPIから業務用語・責任者への関係 | 定義差と責任者の確認 |
| データセット | ソース、テーブル、モデル、レポートの依存 | 変更影響・障害範囲 |
| 列レベル | 入力列、変換式、出力列の対応 | 値差の原因特定 |
| 実行 | 実行ID、時刻、コード版、件数、成否 | 当時状態の再現 |
| 統制 | 品質ルール、例外、承認、アクセス | 監査・受入・是正 |
自動収集できる技術リネージュと、業務担当者が管理する定義・責任を統合します。自動収集対象外の表計算や手作業を「存在しないこと」にせず、手動リネージュまたは統制された受渡し点として登録します。列レベル追跡は重要データ項目から優先し、全資産の完全自動化を開始条件にしません。
非機能要件：リネージュ自体の品質を測る
リネージュにもサービスレベルが必要です。重要KPIについて、ソースからレポートまでの被覆率、実行後に反映されるまでの鮮度、変更時の更新漏れ、検索応答、閲覧権限、履歴保持を定義します。表示される矢印が古ければ、誤った影響判断を生みます。
| 指標 | 定義例 | 運用アクション |
|---|---|---|
| 被覆率 | 重要KPIの経路で登録済みの資産・変換割合 | 未登録区間をバックログ化 |
| 鮮度 | パイプライン変更からメタデータ反映まで | 収集失敗を通知・再実行 |
| 整合性 | 実コードと登録変換の一致 | リリース時に差分検査 |
| 到達性 | 担当者が根拠へ到達する時間 | 用語・タグ・検索を改善 |
| 利用 | 影響分析・障害調査で参照された割合 | 不要資産と不足情報を見直す |
インシデントRACIと成熟度モデル
| 活動 | 業務責任者 | データ管理担当者 | データ開発 | BI運用 |
|---|---|---|---|---|
| 比較条件・正解定義 | A/R | C | I | C |
| 経路・変換調査 | I | C | R | R |
| 品質例外の判定 | A | R | C | C |
| 修正・再処理 | I | C | R/A | R |
| 利用者通知・終結 | A | C | I | R |
レベル1は担当者の記憶で追跡、レベル2は主要データセットの依存を文書化、レベル3は重要KPIの列・実行・品質を自動収集、レベル4は変更ゲートと影響分析へ統合、レベル5はインシデント実績からリネージュ被覆と検知を継続改善する状態です。
成果物テンプレートと90日ロードマップ
調査台帳には、調査ID、比較コンテキスト、差額・差分件数、差が最初に生じる資産、原因層、対象コード版、影響レポート、暫定対応、恒久対応、再処理範囲、承認者、終結条件を置きます。証拠には実行ログ、照合SQL、スクリーンショットではなく再実行可能なクエリと結果IDを優先します。
| 期間 | 実施内容 | 成果 |
|---|---|---|
| 0〜30日 | 重要KPIと頻発不一致を選び、比較票を標準化 | 原因分類と調査台帳 |
| 31〜60日 | 対象経路の資産・列・実行メタデータを接続 | 優先リネージュと影響一覧 |
| 61〜90日 | 変更ゲート、品質通知、調査演習を運用 | SLO、RACI、改善バックログ |
失敗パターンは、図を一度作って更新しない、資産レベルにとどまり、列単位の変換まで追えない、技術担当しか検索できない、機密データ名を過剰公開する、リネージュがあることを理由に品質検査を省くことです。データプロヴェナンスはデータの起源と履歴、インパクト分析は変更の下流影響、観測可能性は実行・品質・鮮度の状態を推測できる能力を指します。
再現可能な調査環境と終結条件
不一致発生後に本番テーブルが更新されると、当時の差を再現できなくなります。重要な集計には、データ時点、パイプライン実行ID、コードまたは設定の版、参照マスタ版、セマンティックモデル版、利用者権限を記録します。必要に応じて短期保持のスナップショットやタイムトラベルを使い、個人情報を含む調査データには保存期限とアクセス承認を設けます。
恒久対策は変換修正だけで終えず、同じ原因を早期検知する品質ルール、変更時に影響先を確認するゲート、利用者へ訂正値を伝える手順まで含めます。終結レビューでは、検知までの時間、原因特定までの時間、修復までの時間、影響を受けた意思決定、再発防止テストを記録し、次のリネージュ優先範囲を更新します。
証拠チェーンの完了条件
調査の品質は、原因を推測できたかではなく、第三者が同じ入力と版を使って差を再現し、修正後に消えたことを確認できるかで判定します。証拠を単なる添付ファイルにせず、調査IDを軸に次の要素を関連づけます。
| 証拠 | 最低限残す内容 | 不足時のリスク |
|---|---|---|
| 入力証拠 | ソース時点、抽出条件、件数、チェックサム | 同じ母集団を再現できない |
| 変換証拠 | コード版、パラメータ、実行ID、例外 | 修正箇所を特定できない |
| 出力証拠 | モデル版、権限、キャッシュ、照合結果 | 利用者の見え方を再現できない |
| 判断証拠 | 正解定義、許容差、業務承認、通知 | 技術的に一致しても、業務部門が調査を終結できない |
| 再発防止証拠 | 追加テスト、監視、変更ゲート、担当者 | 同じ原因を再び見逃す |
調査データの保存期間は、監査・障害分析の必要性とプライバシーを両立させます。保持期限後も必要な場合は、個人識別情報を最小化し、集計された品質・運用メトリクスへ変換して残します。証拠チェーンのテンプレートをインシデント管理へ組み込めば、担当交代後も説明可能性を維持できます。
まとめ：数字ではなく、数字の根拠を管理する
BIの数字が合わない問題は、最後の集計式だけを直しても再発します。比較条件を固定し、表示値から元データまでを同じ業務キーでたどり、差が初めて生じた地点を特定してください。その調査結果を指標定義、リネージュ、品質ルール、変更管理へ反映すれば、次回からは原因特定が速くなり、利用者への説明責任も果たしやすくなります。
BI・DWHの数字を信頼できる状態に整えませんか
Version株式会社では、EAとDMBOKをベースに、KPI定義、データリネージュ、品質管理、BI運用までを一体で整理します。部門ごとに数字が違う、調査に時間がかかるといった課題がある場合はご相談ください。
参考資料
- Microsoft Learn「Data lineage」
- DAMA International「What is Data Management?」
- ISO「ISO/IEC 25012:2008 Data quality model」
- Microsoft Learn：Data lineage user guide for Microsoft Purview Data Catalog
- Microsoft Learn：Data source impact analysis
- DAMA International：DAMA DMBOK 2.0 Revision
BI・DWH構想を、経営判断とデータ管理の両面から整理しませんか
Version株式会社は、意思決定とKPIの整理、データアーキテクチャ、DMBOKに基づくガバナンス、基盤選定、導入・刷新ロードマップを一体で支援します。
BI／DWHテーマクラスター：BI要件定義 ／ 経営ダッシュボード ／ セルフサービスBI統制 ／ DWH・データレイク・レイクハウス ／ DWH要件定義 ／ セマンティックレイヤー ／ BI数値不一致とリネージュ ／ レガシーDWH刷新 ／ BI CoE ／ DWH受入テスト
コメント