DWHの受入テストで「ソースとターゲットの件数が一致したから合格」としていないでしょうか。件数が同じでも、金額が丸められた、顧客コードが誤変換された、取消伝票が集計に残った、履歴の有効期間が重なった、といった問題は見逃されます。BIの画面が開くことと、経営判断に使えるデータであることも別です。
移送完了ではなく、利用目的を満たすことを証明します。重要データを起点に、技術・業務・非機能の品質を検証し、証跡を合否判定と本番監視へつなぐ受入フレームです。
DWHの品質保証では、技術的にデータを移送できたか、データの意味、業務ルール、集計結果、非機能、運用可能性を層に分け、利害関係者が合意した基準で判定します。本記事では、移行と新規構築の双方に使える受入テストの設計方法を解説します。
受入基準は業務リスクから決める
すべての列を同じ深さで検証するのは現実的ではありません。まず、決算、法令報告、顧客請求、在庫、経営KPIなど、誤りが重大な影響を及ぼすデータを重要データ項目として特定します。各項目について、責任者、定義、ソース、変換、利用先、品質ルール、許容差、検証頻度を記録します。
品質は抽象的な「正しさ」ではなく、利用目的に照らして定義します。ISO/IEC 25012は、構造化データの品質要求、測定、評価を計画するための一般的なデータ品質モデルを示しています。自社の受入では、正確性、完全性、一貫性、最新性など必要な特性を選び、測定可能な条件として定義します。
| 業務要求 | 受入基準の例 | 承認者 |
|---|---|---|
| 月次決算の売上 | 承認済み元帳との総額差がゼロ、取消・調整を含む | 経理データ責任者 |
| 日中の在庫可視化 | 所定の鮮度内で更新され、負在庫ルール違反がない | 在庫業務責任者 |
| 顧客別分析 | 顧客統合キーが一意で、未割当の割合が合意範囲内 | 顧客データ管理担当者（データスチュワード） |
| 監査証跡 | ソース、処理時刻、変換版、承認履歴を追跡できる | 内部監査・システム責任者 |
許容差を設ける場合は、理由と対象を明記します。浮動小数や通貨丸めに許容差が必要でも、主キー欠損や不正な権限には原則として許容差を置きません。「全体で1％以内」のような一律基準は、特定顧客の大きな誤りを平均で隠すため注意が必要です。
件数の先にある10のテスト層
| テスト層 | 主な確認内容 | 代表的な証跡 |
|---|---|---|
| 1. スキーマ | 列、型、長さ、NULL可否、キー、制約 | 定義差分、DDL版 |
| 2. 完全性・件数 | 全件・増分・削除、期間別件数、欠落ファイル | 入出力件数、処理ログ |
| 3. 値 | 金額、数量、日付、文字化け、精度、丸め | キー単位差分、ハッシュ |
| 4. 一意性・参照整合 | 重複、孤児レコード、マスタ未割当 | 違反キー一覧 |
| 5. 変換・業務ルール | コード変換、税、通貨、配賦、取消、除外 | 期待値付きテストケース |
| 6. 履歴・時系列 | 有効期間、遅延到着、再処理、締め境界 | 境界日前後の履歴 |
| 7. 集計・BI | 階層別総額、明細へのドリル、KPI式、フィルター | 承認済み基準帳票との照合 |
| 8. 性能・鮮度 | 処理時間、同時利用、応答、更新期限 | 負荷試験と監視記録 |
| 9. セキュリティ | 行・列権限、機密化、監査ログ、職務分離 | 役割別アクセス結果 |
| 10. 運用・復旧 | 再実行、重複防止、障害通知、バックアップ、復元 | 運用訓練と復旧結果 |
この層をすべて同じ件数のケースで実施するのではなく、リスクに応じて深さを変えます。重要データは全件照合または決定的なハッシュ比較を検討し、その他は層別サンプリングを利用します。サンプルは正常値だけでなく、NULL、重複、月末、年度跨ぎ、取消、遅延到着、最大桁、未知コードなどの境界・異常を含めます。
データ照合は「総額→分解→キー」の順で狭める
差分調査は、全体の件数と金額、日・部門・商品などの集計、最後に業務キー単位へ分解すると効率的です。総額が合っても、プラスとマイナスの誤りが相殺されている可能性があるため、複数の切り口で照合します。
- 比較条件を固定する：ソースの抽出時点、タイムゾーン、締め状態、対象期間、フィルターを記録します。
- 完全性を確認する：ファイル、パーティション、テーブル、期間別の件数と処理状態を確認します。
- 統制合計を比較する：金額、数量、ユニークキー数、NULL数、最小・最大日を比較します。
- 業務軸で分解する：会社、部門、商品、日付、ステータス別に差が集中する区間を探します。
- キー単位で追跡する：代表的な差分キーをステージング、DWH、セマンティックモデル、BIまでたどります。
- 原因を分類する：要件、ソース品質、変換、実装、テストデータ、環境、タイミングのどれかを記録します。
Microsoftの移行ガイダンスでも、行数は迅速な確認に使える一方、より深い検証にはチェックサムやハッシュによる比較が挙げられています。ただしハッシュ一致は「同じ入力が同じ形で移った」ことの証拠であり、業務定義そのものの正しさを保証しません。業務期待値を別に用意する必要があります。
数字が合わないときの調査方法は、データリネージュで根拠を追跡する手順も参照してください。
期待値は本番ロジックから自動生成しない
テスト対象と同じ変換コードで期待値を作ると、同じ誤りが両方に入り、テストが通ります。重要な業務ルールは、業務担当者が理解できる小さな入力セットと手計算可能な期待値を用意します。複雑な配賦や履歴では、条件ごとに入力、期待出力、根拠となる規程や定義、承認者を記録します。
最低限含めたい業務シナリオ
- 新規、更新、削除・取消が正しく反映される
- 締め前後、月末、年度跨ぎで基準日が正しい
- マスタ変更前後の履歴が分析意図どおりに見える
- 遅れて到着したデータを再処理しても重複しない
- 未知コード、欠損、異常値が隔離・補完・エラーの決定ルールに従う
- 権限の異なる利用者が許可された行・列だけ閲覧できる
- 障害後の再実行で途中結果が残らず、同じ入力から同じ結果を得られる
合否判定は重大度、残課題、運用準備を含める
テスト完了率100％でも、重大障害が一件残れば受入できません。障害の重大度を業務影響で定義し、各重大度の未解決件数、回避策、再テスト結果をGo／No-Go基準へ組み込みます。
| 重大度 | 判定例 | 受入時の扱い |
|---|---|---|
| 重大 | 決算値の誤り、データ漏えい、復旧不能、主要業務停止 | ゼロ件になるまで受入不可 |
| 高 | 主要KPIの誤り、更新期限超過、重要機能の欠落 | 原則解消。例外は業務責任者の明示承認 |
| 中 | 限定条件での誤り、実用的な回避策あり | 期限・責任者・影響範囲を登録して判断 |
| 低 | 表示、文言、軽微な操作性 | 改善計画へ登録し、総合判断 |
受入判定資料には、テスト範囲、未実施範囲、結果、差分、残課題、品質指標、性能、セキュリティ、復旧訓練、運用手順、教育状況をまとめます。業務責任者はデータの意味と利用適合性、ITは技術品質と運用性、セキュリティ・監査は統制を承認します。誰か一人に全責任を集めないことが重要です。
受入テストを本番の継続的品質管理へ引き継ぐ
受入時に作ったテストを捨てると、ソースや変換の変更で同じ問題が再発します。重要な照合を回帰テストと本番監視へ移し、入出力件数、重複、欠損、参照整合、統制合計、鮮度を定期測定します。ルール違反時は、単にジョブを止めるのか、隔離して続行するのか、利用者へ警告するのかを重要度別に決めます。
DWH要件定義の段階から受入基準を定め、要件、設計、テスト、監視を一つのトレーサビリティで結ぶと、後工程での解釈違いを減らせます。BI側の利用シナリオはBI要件定義と連携させます。
EAとDMBOKで品質の責任分界を明確にする
EAでは、業務要求からデータ、アプリケーション、技術までを追跡し、各層の受入条件を整合させます。たとえば「翌朝の経営会議までに前日実績を確認できる」という業務要求を、更新締切、処理性能、監視、レポート表示のテストへ展開します。これにより、データベース単体の合格と業務上の合格が分離するのを防ぎます。
DAMA-DMBOKでは、データ品質を独立したテスト工程ではなく、ガバナンス、メタデータ、統合、マスタ、DWH／BIと結び付けます。データ責任者が品質要求と許容するリスクを決め、データ管理担当者がルールと問題を管理し、開発・運用が測定と修正を実行する責任分界を明文化します。品質問題の原因と対応コストを蓄積すれば、どの上流プロセスを改善すべきか判断できます。
専門設計：品質保証をテストピラミッドで組み立てる
DWHの受入テストは、最終集計を人が確認するだけでは遅く、原因特定も困難です。変換単体、データ契約、統合、業務シナリオ、非機能、運用復旧を層に分け、下層ほど頻繁に自動実行します。最終受入は、下層の証拠を束ねて利用目的を満たすことを業務責任者が判断する工程です。
| テスト層 | 主な検証 | 自動化 | 実行タイミング |
|---|---|---|---|
| 変換単体 | 式、型、境界、空値、重複、冪等性 | 高 | コード変更ごと |
| データ契約 | スキーマ、鮮度、品質、互換性 | 高 | 取り込み・公開ごと |
| 統合 | キー、参照整合、SCD、遅延到着 | 高 | パイプライン実行ごと |
| 業務シナリオ | 締め、取消、訂正、通貨、組織変更 | 中 | リリース候補ごと |
| 非機能 | 性能、並行、復旧、権限、監査 | 中 | 主要変更・定期 |
| 利用者受入 | 意思決定、操作、例外、説明可能性 | 低 | 本番判定前 |
期待値を独立させる
本番変換と同じコードから期待値を生成すると、同じ誤りを正解としてしまいます。小さなゴールデンデータセットを業務ルールから手作業で確定し、代表母集団は旧システム、会計、契約証跡など独立ソースと照合します。期待値の作成者、承認者、版、有効期間を保持します。
重要データ項目と許容差をリスクから決める
すべての列を同じ強度で検査せず、経営報告、法令、請求、顧客対応に影響する重要データ項目（CDE）を優先します。ISO/IEC 25012は構造化データの品質要件・測定・評価に使える一般モデルを示しています。自社では正確性、完全性、一貫性、適時性などを業務リスクへ対応づけます。
| 許容差方式 | 向くデータ | 例 | 注意点 |
|---|---|---|---|
| 完全一致 | キー、契約状態、会計確定値 | 不一致ゼロ | 丸め・時点を事前固定 |
| 絶対差 | 少量の欠損・遅延を管理する件数 | 差分件数の上限 | 母集団規模も併記 |
| 相対差 | 大規模集計、推定・換算 | 基準値に対する割合 | 小さい分母に注意 |
| 時間差 | 鮮度、遅延到着 | 発生から利用可能まで | 営業時間・締めを定義 |
| 分布差 | カテゴリ、価格、異常傾向 | 比率・分位の変化 | 季節性と構成変化を区別 |
| 例外承認 | 既知欠陥・移行残課題 | 対象、期限、代替統制 | 恒久化を防ぐ期限が必要 |
閾値は「業界標準」ではなく、許容できる最大の業務影響、検知・訂正に必要な時間、代替統制から決めます。重大度は差分量だけでなく、機密性、意思決定期限、影響利用者、再処理可能性を含めます。
非機能・運用テストを本番条件で行う
| 領域 | テストシナリオ | 合格証拠 |
|---|---|---|
| 性能・並行 | ピーク量、同時クエリ、更新競合、キャッシュなし | 応答分布、終了時刻、資源・コスト |
| 可用性 | ジョブ失敗、再実行、部分完了、依存停止 | RTO、データ欠損なし、通知履歴 |
| 災害復旧 | バックアップ復元、リージョン・基盤障害 | RPO、復旧手順、業務承認 |
| セキュリティ | 権限別閲覧、職務分離、サービスID、持出し | 許可・拒否の双方を確認するテストと監査ログ |
| 監視 | 鮮度低下、品質違反、長時間クエリ、容量逼迫 | 検知時間、通知、Runbook起動 |
| 変更・互換 | 列追加、型変更、メジャー変更、下流影響 | 契約検査、影響一覧、移行通知 |
性能テストは平均値だけでなく、遅い側の分布と長時間クエリを追います。運用監視で取得できる実行履歴、失敗、キャンセル、CPU・メモリ・容量などの逼迫状況を、受入時に想定した基準と比較し、本番後の継続的品質管理へ引き継ぎます。
欠陥判定RACIと品質成熟度
| 活動 | 業務責任者 | 品質責任者 | 開発 | 運用／セキュリティ |
|---|---|---|---|---|
| 品質要件・重大度 | A | R | C | C |
| 期待値・試験設計 | C | A/R | R | C |
| 原因分析・修正 | I | C | A/R | R |
| 例外受入 | A | R | C | C |
| 本番移行・受入完了 | A | R | R | R |
成熟度1は件数・目視中心、2は重要集計とシナリオを標準化、3は契約・単体・統合テストを自動化、4はリネージュと変更パイプラインへ品質ゲートを統合、5は本番インシデントと利用実績からテスト資産を継続改善する状態です。
受入証拠パッケージと段階導入
成果物テンプレートには、要件ID、業務リスク、対象CDE、ソース時点、テストデータ版、期待値の根拠、実行ID、実績、差分、重大度、原因、修正・再試験、残課題、例外期限、承認者を含めます。サマリーだけでなく、再実行可能なクエリ、ログ、コード版、リネージュを束ねます。
| 段階 | 重点 | 出口条件 |
|---|---|---|
| 要件 | 業務リスク、CDE、品質特性、許容差 | 責任者が判定基準を承認 |
| 設計 | テスト層、期待値、データ、環境、RACI | 本番ロジックと独立した証拠を確保 |
| 自動化 | 単体、契約、統合、回帰をパイプライン化 | 失敗時にリリースを停止 |
| 受入 | 業務・非機能・運用シナリオを実行 | 重大欠陥ゼロ、例外を期限付き承認 |
| 本番移管 | 監視、Runbook、品質SLO、定期回帰 | 運用者が検知・復旧を演習 |
失敗パターンは、旧DWHを無条件に正解とする、件数と総額だけで明細・履歴を見ない、本番と違う小規模条件だけで性能を測る、欠陥を「データの問題」として責任の所在を曖昧にする、例外を期限なしで受け入れることです。テストオラクルは期待結果を判定する根拠、ゴールデンデータセットは承認済みの小さな基準データ、冪等性は再実行しても結果が重複・変質しない性質です。
まとめ：一致確認から「利用目的を満たすことの証明」へ
DWHの受入は、データが移ったことを確認する作業ではありません。重要データを選び、業務リスクに応じた品質基準を定め、値、履歴、業務ルール、集計、性能、権限、復旧まで証拠を残して確認する品質保証です。受入テストを本番監視へ引き継ぎ、データの変更後も信頼を維持できる仕組みにしてください。
DWHの品質保証を要件段階から設計します
Version株式会社では、EAとDMBOKをベースに、重要データの特定、品質ルール、照合テスト、受入判定、継続監視までを支援します。移行後の数値に不安がある場合や、テスト観点に漏れがないか確認したい場合はご相談ください。
参考資料
- ISO「ISO/IEC 25012:2008 Data quality model」
- DAMA International「DAMA DMBOK Revision」
- Microsoft Learn「Execute migration to cloud」
- Microsoft Learn「Azure Database Migration Service FAQ」
- Microsoft Learn：Monitoring in Fabric Data Warehouse overview
- Microsoft Learn：Power BI usage scenario—Enterprise content publishing
BI・DWH構想を、経営判断とデータ管理の両面から整理しませんか
Version株式会社は、意思決定とKPIの整理、データアーキテクチャ、DMBOKに基づくガバナンス、基盤選定、導入・刷新ロードマップを一体で支援します。
BI／DWHテーマクラスター：BI要件定義 ／ 経営ダッシュボード ／ セルフサービスBI統制 ／ DWH・データレイク・レイクハウス ／ DWH要件定義 ／ セマンティックレイヤー ／ BI数値不一致とリネージュ ／ レガシーDWH刷新 ／ BI CoE ／ DWH受入テスト
コメント