DWH構築の手戻りは、製品の機能不足よりも、要件の曖昧さから生じることが少なくありません。「売上を見たい」という要望だけでは、受注明細と請求のどちらを売上とするのか、日次か月次か、組織変更前の実績を当時組織と現在組織のどちらで見るのかを設計できません。
画面要望を並べるのではなく、業務判断から粒度・履歴・鮮度を導き、品質保証と運用まで検証可能にします。
DWHの要件定義では、レポート画面の項目だけでなく、データの粒度、履歴、更新頻度、品質、権限、性能、運用を検証可能な受入条件として残す必要があります。本記事では、業務部門とIT部門が同じ表を見ながら合意できるチェックリストを示します。
この記事でわかること
- DWH要件を意思決定から導く手順
- データ粒度、履歴、更新頻度を決める具体的な質問
- 品質、メタデータ、セキュリティ、運用の確認項目
- 要望を検証可能な受入条件へ変換する方法
要件定義の出発点は「何を見るか」ではなく「何を決めるか」
最初に、利用者、意思決定、判断の頻度、判断後のアクションを一文で記述します。たとえば「営業部長が毎週月曜日に、案件停滞と着地見込みを確認し、支援対象と担当変更を決める」という形です。これにより、必要な案件段階、担当組織、基準日、更新期限が明らかになります。
| 確認項目 | 質問例 | 成果物・受入証跡 |
|---|---|---|
| 意思決定 | 誰が、いつ、何を決めるか | ユースケース記述、責任者の承認 |
| 指標 | 何を良い・悪いと判断するか | KPI定義書、計算例 |
| 分析軸 | 組織、商品、顧客、地域、時間をどの階層で見るか | ディメンション定義、サンプル集計 |
| アクション | 結果を見た後、どの業務を変えるか | 会議・業務プロセスとの対応表 |
ダッシュボードから検討を始める場合も、経営ダッシュボードの設計原則に沿ってKGI・KPI・アクションをつなげ、データ要件へ逆算します。
チェック1：データ粒度を一文で固定する
粒度とは、1行が表す業務上の事実の細かさです。Microsoftの公式モデリングガイドでも、ファクトテーブルは一貫した粒度でロードすることが重要とされています。粒度が混在すると、合計時の二重計上や、レポートごとの数値差につながります。
粒度を決める質問
- 1行は、受注、受注明細、出荷、請求、入金のどのイベントを表すか
- 時間は秒、日、週、月のどこまで必要か
- 顧客、商品、組織はどの最小単位で分析するか
- 数量、金額、残高、率のうち、どれが加算可能か
- 明細を保持する期間と、集約後だけ残す期間は何年か
- 異なる粒度の計画値と実績値を、どの共通軸で比較するか
要件書には「売上ファクトの1行は、1受注明細・1出荷日・1通貨を表す」のように明記します。月次予算と日次実績を同じ表に無理に格納せず、異なるファクトとして共通ディメンションにつなぐことも検討します。
チェック2：履歴は「過去をどう見たいか」から決める
履歴要件には、取引そのものの履歴と、顧客属性や組織所属などディメンションの変更履歴があります。現在値だけを上書きすると、過去の売上が現在の組織へ付け替わり、当時の業績を再現できないことがあります。
| 履歴方式 | 向く問い | 要件定義上の注意 |
|---|---|---|
| トランザクション | どの明細・イベントが発生したか | 訂正、取消、重複、遅延到着の扱いを決める |
| 定期スナップショット | 月末在庫や日次残高がどう推移したか | 締め時点、再作成、欠測日の扱いを決める |
| 累積スナップショット | 案件や注文が各工程をいつ通過したか | マイルストーンと完了前の未設定値を決める |
| SCDタイプ1 | 常に最新属性で見ればよいか | 上書きにより過去状態を復元できない |
| SCDタイプ2 | 当時の組織・顧客区分で分析するか | 有効開始・終了、現行フラグ、代理キーが必要 |
すべての属性を履歴化するとデータ量と運用負荷が増えます。属性ごとに「当時値が必要」「最新値で再集計」「変更前後の両方が必要」を分類し、法令・監査・業務上の保存期間も合わせて決めます。
チェック3：更新頻度をエンドツーエンドで定義する
「日次更新」だけでは受入条件になりません。利用者が必要とするのは、データ発生から分析可能になるまでの鮮度です。ソース確定、抽出、転送、変換、品質検査、DWH反映、セマンティックレイヤー更新、レポートキャッシュまでを分解します。
- 対象業務は何時に締まり、ソースデータはいつ確定するか
- 発生から利用可能までの許容遅延は何分・何時間か
- バッチ失敗時の再実行期限と、利用者への通知方法は何か
- 遅れて届くデータや訂正データを、何日前まで再処理するか
- ピーク時間のデータ量と同時実行数はどの程度か
- リアルタイム化によって変わる意思決定と、その価値は明確か
更新要件は、「前営業日24時までに確定した受注を、翌営業日7時までに利用可能にする。未達時は7時15分までに利用部門へ通知する」のように、対象範囲、期限、例外対応を一体で記述します。
チェック4：品質と照合を受入基準にする
DAMA-DMBOKでは、データ品質はメタデータ、モデリング、マスターデータ、統合、ガバナンスなどと接続する領域です。DWH要件では、重要データ項目ごとに品質ルール、閾値、責任者、例外処理を定義します。
- 完全性：必須項目の欠損をどこまで許容するか
- 一意性：顧客や取引の重複をどう判定するか
- 妥当性：日付、コード、値域、参照整合性のルールは何か
- 整合性：会計、販売、CRMなど複数ソース間を何で照合するか
- 適時性：必要な時点までにデータが到着しているか
- 正確性：業務上の正解と照合できるサンプル・母集団は何か
件数一致だけでなく、金額合計、キー別集計、履歴、有効期間、例外レコード、再実行後の冪等性を受入テストに含めます。詳しくはDWH受入テストとデータ照合も参照してください。
チェック5：メタデータとリネージュを成果物にする
テーブルを作るだけでは、利用者は数値の意味や根拠を判断できません。業務用語、項目定義、計算式、データ責任者、更新時刻、品質状態、ソースからレポートまでの変換経路を管理対象にします。
- 業務用語と物理項目を対応づけているか
- 指標の計算式、粒度、対象・除外条件が記録されているか
- データセット、パイプライン、レポートの責任者が明確か
- 変更時に影響を受ける下流資産を追跡できるか
- 利用者が定義と品質状態を検索できるか
数値不一致の調査方法は、BIの数字が合わない原因とデータリネージュで詳しく解説しています。
チェック6：セキュリティ、性能、運用を後回しにしない
| 領域 | 最低限決めること | 受入条件の例 |
|---|---|---|
| セキュリティ | 機密区分、行・列のアクセス、職務分離、監査ログ、保存・削除 | 権限別テスト利用者で閲覧範囲を確認 |
| 性能 | 代表クエリ、データ量、同時利用、更新競合、拡張見込み | 基準データ量と同時数で応答時間を測定 |
| 可用性 | 利用時間、復旧時間、復旧時点、バックアップ、災害対策 | 復旧手順を実行し、結果と所要時間を記録 |
| 運用 | 監視、通知、再実行、変更、リリース、問い合わせ、廃止 | 障害シナリオで役割・連絡・再開を確認 |
| コスト | 保存、計算、転送、ライセンス、運用工数、予算アラート | 月次見積りと実績の差異を追跡可能 |
そのまま使える要件レビューの最終確認
- 優先ユースケースと意思決定者が承認されている
- 各ファクトの粒度が一文で定義され、混在していない
- 指標の加算可否、通貨、税、締め、取消が定義されている
- 属性ごとの履歴方式と保存期間が決まっている
- 発生から利用可能までの鮮度目標が決まっている
- 重要データ項目の品質ルール、閾値、責任者が決まっている
- 用語、項目、リネージュの管理方法が決まっている
- 権限、性能、復旧、監視、再実行の受入試験がある
- 変更要求の承認者と下流影響の確認手順がある
- 廃止条件とデータ保管・削除方法がある
EAとDMBOKを要件表へ組み込む
EAの観点では、業務能力・プロセスから必要な情報を導き、その情報を生成するアプリケーション、格納・提供するデータ基盤、実行する技術へつなぎます。この対応関係があれば、ソース変更や組織再編の影響を判断しやすくなります。
DMBOKの観点では、DWH／BIだけでなく、ガバナンス、アーキテクチャ、モデリング、統合、品質、メタデータ、セキュリティを要件表の見出しにします。各項目に業務責任者、技術責任者、受入証跡を置けば、設計文書が完成して終わるのではなく、運用できる合意になります。
専門家向け補論：DWH要件を「データ契約」と「検証可能なSLO」へ具体化する
DWH要件は、テーブル一覧や更新ジョブ一覧ではありません。各データセットについて、一行の意味、業務時点、履歴、配信期限、品質、変更、責任を利用者と提供者が合意したデータ契約です。さらに、その契約を検証可能な閾値として定めたものが受入基準です。要件、実装、テスト、運用監視を同じ識別子で追跡できる状態を作ります。
粒度契約の成果物サンプル
| 項目 | 記載例 | 曖昧な記載 |
|---|---|---|
| 業務イベント | 確定した受注明細の状態変化 | 売上データ |
| 一行の粒度 | 受注番号×明細番号×履歴版 | 受注単位 |
| 識別キー | ソースID、自然キー、代理キーの対応 | IDで結合 |
| 業務時点 | 有効開始・終了、発生日、計上日 | 日付 |
| 到着時点 | 取得、処理、公開、再処理の時刻 | 更新日 |
| 加算性 | 数量・金額は商品と期間で加算可能 | 数値項目 |
| 訂正 | 取消行を追加し、元明細との参照を保持 | 上書きする |
履歴方式を属性単位で決める
| 方式 | 適する要件 | 注意点 | テスト |
|---|---|---|---|
| 上書き | 常に最新値だけを使う訂正情報 | 過去時点を再現できない | 旧値が残らず最新値へ統一 |
| 版管理 | 組織・顧客区分等の変化を当時値で分析 | 有効期間重複、遅延到着 | 任意時点で一つの版へ解決 |
| トランザクション追記 | 取消・返金・仕訳など監査可能な事実 | 相殺と元取引の参照 | 再集計でソース残高と一致 |
| 周期スナップショット | 日次在庫、月次残高、案件状態 | 未取得日、再作成、時間方向の非加算 | 基準時点の完全性と重複なし |
| 累積スナップショット | 受注から出荷等のマイルストーン分析 | 更新順序と未到達状態 | 各節目の日時と所要時間を再現 |
更新頻度をデータ鮮度のSLOへ分解する
「毎時更新」だけでは、データがどの時点までの事実を含むか分かりません。ソース確定、抽出開始、取り込み完了、変換完了、品質合格、公開時刻を分け、エンドツーエンドの遅延予算を定義します。再処理中、部分成功、ソース休止時に利用者へ何を表示するかも要件です。
| 区間 | SLO例 | 監視・証跡 |
|---|---|---|
| 発生元の確定遅延 | 業務確定から抽出可能まで30分 | ソース確定時刻 |
| 取り込み遅延 | 抽出可能からRaw着地まで15分 | 件数、チェックポイント、再送 |
| 処理遅延 | Raw着地からCurated公開まで30分 | ジョブ依存、処理版、品質結果 |
| 提供遅延 | 公開からセマンティック反映まで15分 | モデル更新、キャッシュ状態 |
| 復旧 | 失敗検知から代替・復旧判断まで20分 | アラート、運用手順書、責任者 |
品質基準を業務影響と結びつける
| 品質次元 | ルール例 | 重大度 | 処置 |
|---|---|---|---|
| 完全性 | 重要顧客IDの欠損なし | 重大（公開停止） | 公開停止、隔離、所有者通知 |
| 一意性 | 受注×明細×版が重複しない | 重大（公開停止） | 安易に重複排除せず、原因を解消する |
| 妥当性 | 終了日は開始日以降 | 高 | 例外表へ隔離し影響表示 |
| 整合性 | 明細合計とヘッダ金額が許容差内 | 高 | 照合差を記録し承認 |
| 適時性 | 締め時刻までに対象日を100％反映 | 用途別 | 速報表示または前回値へ切替 |
| 正確性 | 正本データ・証憑との標本照合 | 用途別 | 訂正と再発防止を追跡 |
すべての違反で公開を止めると可用性を損ない、すべて警告にすると信頼を失います。重要データ項目（CDE）と意思決定影響に基づき重大度を分け、停止、隔離、警告、期限付き許容の処置を決めます。例外の承認者と有効期限を必ず残します。
受入テストの追跡マトリクス
| 要件ID | 試験観点 | 代表条件 | 合格証跡 |
|---|---|---|---|
| GRN-01 | 粒度・重複 | 分割、取消、再送、同一キー | キー一意性と件数差の結果 |
| HIS-02 | 履歴 | 遅延到着、過去訂正、組織変更 | 任意時点の期待値比較 |
| FRS-03 | 鮮度・復旧 | ピーク、ソース遅延、ジョブ失敗 | 区間別時刻と運用手順書実績 |
| DQL-04 | 品質 | 欠損、重複、参照不整合、異常値 | 検知、隔離、通知、再処理 |
| SEC-05 | 権限・監査 | 閲覧を許可する利用者・許可しない利用者、出力、サービスID | アクセス結果と監査ログ |
| PRF-06 | 性能 | 代表クエリ、同時実行、最大期間 | 分位値、資源、クエリ計画 |
RACIと成熟度
| 活動 | 業務責任者 | データ責任者 | DWHチーム | 運用・セキュリティ |
|---|---|---|---|---|
| 粒度・履歴・KPI定義 | A/R | R | C | I |
| 品質閾値・例外承認 | C | A/R | R | C |
| パイプライン・モデル・試験 | C | C | A/R | C |
| SLO監視・障害復旧 | I | C | R | A/R |
| 権限・保持・廃棄 | C | A | R | R |
| 段階 | 要件の状態 | 次の能力 |
|---|---|---|
| レベル1 ジョブ中心 | 処理時刻とテーブル一覧が中心 | 粒度・履歴・利用目的 |
| レベル2 テスト可能 | 品質・鮮度・性能に合格値がある | 責任、例外、運用手順書 |
| レベル3 契約型 | データ契約とリネージュで変更を管理 | 自動契約テストと影響分析 |
| レベル4 適応型 | 利用価値とリスクでSLO・保持を最適化 | 品質問題の予防と継続的再設計 |
段階ロードマップ
- 定義：意思決定、粒度、時点、履歴、品質、SLO、責任をデータ契約へまとめる。
- 実現性検証：ソースの履歴・変更捕捉・キー・確定時刻をプロファイリングする。
- 縦切り構築：代表データで取り込みから消費までを作り、失敗・再処理も試す。
- 受入：追跡マトリクスに沿い業務・データ・性能・権限・運用を承認する。
- 運用：SLO、品質、例外、利用、費用を監視し、契約と保持を定期的に見直す。
用語解説
- Fact Grain：ファクト表の一行が表す業務事実の単位。
- SCD：Slowly Changing Dimension。属性変更を上書きまたは版管理する設計。
- Late-arriving Data：業務発生後、想定より遅れてDWHへ到着するデータ。
- データ鮮度のSLO（Freshness SLO）：データが利用可能になるまでの新鮮さについて合意したサービス目標。
- Quarantine：品質違反データを正常系から隔離し、調査・是正する領域。
まとめ
DWHの要件定義で最も重要なのは、曖昧な要望を、粒度・履歴・鮮度・品質・権限・性能・運用という検証可能な条件へ変換することです。Version株式会社では、ビジネス要求からデータアーキテクチャ、受入基準までを一貫して整理するDWH構想・要件定義をご支援しています。既存の要件書の抜け漏れ確認やプロジェクト立て直しについては、お問い合わせください。
参考資料
- Microsoft Learn：Load tables in a dimensional model
- Microsoft Learn：Fabric governance documentation
- Microsoft Learn：Impact analysis in Microsoft Fabric
- Microsoft Learn：Understand star schema and the importance for Power BI
- Microsoft Learn：Modeling fact tables in Microsoft Fabric Warehouse
- Microsoft Learn：Modeling dimension tables in Microsoft Fabric Warehouse
- DAMA International：DAMA DMBOK 2.0 Revision
- The Open Group：The TOGAF Standard
BI・DWH構想を、経営判断とデータ管理の両面から整理しませんか
Version株式会社は、意思決定とKPIの整理、データアーキテクチャ、DMBOKに基づくガバナンス、基盤選定、導入・刷新ロードマップを一体で支援します。
BI／DWHテーマクラスター：BI要件定義 ／ 経営ダッシュボード ／ セルフサービスBI統制 ／ DWH・データレイク・レイクハウス ／ DWH要件定義 ／ セマンティックレイヤー ／ BI数値不一致とリネージュ ／ レガシーDWH刷新 ／ BI CoE ／ DWH受入テスト
コメント