BI導入の要件定義――欲しい画面ではなく意思決定から考える

2026.08.02

BI導入プロジェクトで最初に集まりやすい要望は、「売上を一画面で見たい」「ドリルダウンしたい」「Excelに出したい」といった画面や機能の話です。しかし、そのまま一覧化しても、判断に使われないレポートが増えるだけです。BIの価値は、画面の美しさではなく、意思決定の速度と質を高め、次の行動につなげることにあります。

EXPERT EDITION読了目安約13分実務テンプレート・判断基準付き

FRAMEWORK

判断から逆算するBI要件の4層

画面要望を起点にせず、経営・業務の判断から情報、データ、提供・運用へ順に具体化することで、使われるBIの要件を一貫して設計します。

01意思決定を定義誰が、どの場面で、何を判断し、判断後にどの行動を取るのかを明文化する。

02問いとKPIへ展開判断に必要な業務上の問いを定め、KGI・KPI、比較基準、閾値を結びつける。

03データ要件を確定正本、粒度、履歴、鮮度、品質ルール、組織・商品などの共通マスタを決める。

04提供と運用を設計分析導線、権限、性能に加え、変更、問い合わせ、利用監視、廃止の責任まで定める。

OUTPUT目的・判断・KPI・データ・運用が追跡できる「BI意思決定要件マップ」

したがって要件定義の起点は、「何を表示するか」ではなく「誰が、どの場面で、どの問いに答え、何を決めるか」です。そこから必要な指標、比較軸、データ粒度、更新頻度、権限、運用責任を逆算します。本稿では、経営企画・BI責任者・データ基盤担当が共通言語で進められる実務手順を整理します。

この記事でわかること

画面要望を意思決定要件へ変換する方法
BI要件定義で合意すべき7つの論点
エンタープライズアーキテクチャとDMBOKを使った抜け漏れ防止
構築前のレビューに使えるチェックリスト

BI要件は「意思決定の設計図」である

同じ売上指標でも、経営会議と営業所の日次運営では用途が違います。経営会議では事業別の計画差と見通しを確認して投資配分を決め、営業所では案件別の停滞を見て担当者の次の行動を決めます。利用者、頻度、判断、必要な粒度が異なるため、同じ画面を配ればよいわけではありません。

要件を「KPIを表示すること」とだけ書くと、分母・分子、計上時点、取消処理、通貨、組織変更の扱いが後回しになります。要件は少なくとも次の因果で記述します。

要件の層	確認する問い	成果物の例
経営・業務目的	どの目標や課題に寄与するか	目的、対象業務、期待成果
意思決定	誰が、いつ、何を決めるか	会議・判断・アクション一覧
情報	判断に必要な指標と比較軸は何か	KPI定義、ディメンション、閾値
データ	どのデータを、どの粒度・時点で使うか	ソース、粒度、履歴、品質ルール
アプリケーション	どの導線・権限・性能で提供するか	画面、配信、認証、非機能要件
運用	誰がデータを更新し、要件変更を承認し、問い合わせに対応するか	RACI、SLA、変更・廃止手順

意思決定から逆算する7ステップ

1．対象となる経営・業務テーマを絞る

「全社の見える化」のような広い目的は、優先順位を決められません。「粗利悪化の兆候を週次で把握し、価格・原価・販売構成の打ち手を決める」など、変えたい判断と業務成果を具体化します。対象外も明記し、初期リリースの境界を守ります。

2．利用者と意思決定シーンを特定する

役職名だけでなく、会議、日次業務、例外対応などの利用場面を記述します。事前に閲覧するのか、会議中に掘り下げるのか、アラートを受けて動くのかによって、必要な鮮度や操作性は変わります。代理者や承認者も含めて責任の流れを確認します。

3．業務上の問い（Business Question）を定義する

画面を描く前に、答えるべき問いを列挙します。たとえば「売上は計画に対してどうか」だけでなく、「差異は価格・数量・構成のどこから生じたか」「放置した場合の着地はどうなるか」「誰がいつまでに対応するか」まで展開します。問いに答えないビジュアルは削除候補です。

4．KGI・KPI・比較軸・アクションをつなぐ

KPIには名称だけでなく、定義、計算式、単位、対象範囲、計上基準、更新時刻、責任者を持たせます。実績だけでは判断できないため、計画、前年、予測、閾値などの比較基準を決めます。さらに異常時の確認先、会議体、担当部署、標準アクションまで結びつけます。

5．データ要件を具体化する

ソースシステム、レコード粒度、履歴保持、遅延許容、欠損・重複・取消の処理、組織や商品のマスタを定義します。「リアルタイム」はコストも運用負荷も高めるため、判断期限に間に合う鮮度へ言い換えます。月次会議なら締め処理後、現場の在庫判断ならより短い間隔など、業務時間軸に合わせます。

6．分析導線と非機能要件を決める

トップ画面から原因、明細、業務システム上の処理へどう移るかを設計します。閲覧者・作成者の権限、行レベル制御、機密区分、同時利用、応答時間、モバイル利用、エクスポート、監査ログ、障害時の代替手段も要件です。平常時の応答速度だけでなく、締め日などのピーク条件を合意します。

7．運用・定着・廃止まで要件化する

データ障害とレポート障害の窓口、KPI変更の承認者、リリース手順、利用状況の確認、教育、定期棚卸しを決めます。レポートは作った瞬間から陳腐化が始まります。利用されないものを停止・統合できる条件を持つことで、BI資産の増殖を防げます。

要件定義書に最低限入れる項目

区分	必須項目	よくある曖昧さ
意思決定	利用者、場面、問い、判断、次の行動	「経営が見る」で止まる
KPI	式、粒度、時点、比較、責任者	部門ごとに売上定義が違う
データ	正本、履歴、鮮度、品質、リネージュ	抽出後の加工が追えない
体験	概要、例外、掘り下げ、業務への導線	全項目を一画面に詰め込む
統制	認証、権限、機密、監査、持ち出し	公開直前に権限を検討する
運用	所有者、SLA、変更、教育、廃止	開発チーム解散後の責任者がいない

EAとDMBOKで「画面の外側」を設計する

エンタープライズアーキテクチャの観点では、BIは単独の可視化ツールではありません。経営戦略と業務能力をビジネスアーキテクチャで捉え、必要な情報と正本をデータアーキテクチャへ、提供・連携の責任をアプリケーションアーキテクチャへ具体化します。このつながりを持つと、似たダッシュボードの重複や、CRM・ERP・DWH間の責任の空白を発見しやすくなります。

DAMA-DMBOKは特定製品の導入手順ではなく、データガバナンス、データ品質、メタデータ、データ統合、DWH／BIなどを横断して考えるための知識体系です。KPIの業務定義をビジネス用語集に、変換経路をリネージュに、品質ルールを重要データの受入条件に反映し、データ責任者とデータ管理担当者（データスチュワード）を任命します。画面要件とデータ管理を同時に設計することが、数字への信頼につながります。

構築に入る前のチェックリスト

対象となる意思決定と、決定後のアクションを説明できる
各KPIの定義・計算式・責任者が一意に決まっている
データの粒度、履歴、鮮度が判断期限に合っている
計画・前年・予測・閾値など比較基準がある
概要から原因・明細・業務処理までの導線がある
データ品質不良時の表示とエスカレーションが決まっている
権限、エクスポート、監査のルールがある
変更・問い合わせ・利用監視・廃止の責任者がいる
プロトタイプを実際の会議や業務シーンで検証した

専門家向け補論：要件を「意思決定契約」として固定する

複数部門が使うBIでは、要件書を画面仕様ではなく、利用者とデータ提供側の合意である「意思決定契約」として扱います。契約には、問い、指標、判断期限、比較基準、許容する遅延・誤差、異常時の代替手段、責任者を含めます。要件変更時は、画面だけでなくデータモデル、下流レポート、会議運営、権限への影響を確認します。

Business Contract

誰がどの会議・業務で何を決め、判断後にどのアクションを起こすか。

Data Contract

粒度、時点、定義、品質、配信期限、スキーマ変更、所有者をどう保証するか。

Service Contract

可用性、性能、問い合わせ、障害通知、変更・廃止をどの水準で運営するか。

要件決定記録のサンプル

決定項目	記載例	レビュー観点
Business Question	週次で粗利計画差の主要因を特定し、是正責任者を決める	画面を見た後の判断が一意か
指標契約	粗利＝売上計上額－標準原価。返品は計上月へ遡及	式、対象、時点、例外が明確か
時間契約	月曜7時までに前週日曜締めを提供	ソース確定から表示までの各遅延を含むか
品質契約	重要項目欠損時は値を隠さず警告し、担当へ通知	閾値超過時の判断と責任があるか
変更契約	定義変更は影響分析、承認、並行期間を経て適用	過去比較と下流資産を壊さないか

設計判断：リアルタイム化は目的ではありません。意思決定可能になる期限から、ソース確定、取り込み、変換、品質検査、セマンティックモデル更新、画面反映の時間予算を逆算します。値が速くても未確定なら、速報・確定の状態を分けて表示します。

要件のアンチパターンと是正

アンチパターン	なぜ失敗するか	是正する成果物
全社共通画面を一枚で作る	判断頻度と粒度が異なり、誰にも最適化されない	ペルソナ別意思決定シナリオ
KPI名称だけを合意する	計算、時点、除外、組織変更で数値が分裂する	メトリクス定義書と変更履歴
ソース項目をそのまま要件にする	業務概念と物理項目が一対一とは限らない	概念モデルと項目マッピング
プロトタイプを見た目だけで承認する	実データの欠損、性能、権限、例外を検証できない	代表データによる判断シナリオテスト
稼働後の変更を無償の小改修として扱う	定義と資産が制御なく増殖する	変更審査、優先度、廃止基準

BI要件定義のRACI

活動	業務責任者	データ責任者	BI／データチーム	EA・セキュリティ
問い・判断・KPIの承認	A/R	C	C	I
定義・正本・品質基準	C	A/R	R	C
モデル・画面・性能設計	C	C	A/R	C
権限・保持・監査	C	R	R	A
受入・効果確認・廃止	A/R	C	R	I

A＝最終責任、R＝実行責任、C＝協議、I＝共有。組織規模に応じて役割を兼任しても、責任の種類は分けます。

成熟度モデルと段階ロードマップ

段階	要件の状態	次に整える能力
レベル1 要望中心	画面・項目の一覧、個別担当者の暗黙知	意思決定シナリオとスコープ
レベル2 定義済み	KPI、粒度、鮮度、責任が文書化	用語集、品質基準、受入テスト
レベル3 統合	EA・DMBOK成果物と要件が追跡可能	影響分析、データ契約、再利用
レベル4 適応	利用・品質・成果に基づき継続改善	自動監視とポートフォリオ最適化

実装ロードマップ

0〜30日：重要な意思決定を3〜5件選び、既存会議・帳票・データ課題を棚卸しする。
31〜60日：KPI契約、概念モデル、粒度・履歴・鮮度、権限、RACIを合意する。
61〜90日：対象を絞ったエンドツーエンドの試作で、判断、性能、品質、権限、障害時表示を検証する。
稼働後：利用回数ではなく意思決定時間、アクション完了、品質基準違反と、重複資産の廃止状況を評価する。

用語解説

Business Question：分析で答えるべき業務上の問い。指標ではなく、判断へつながる疑問文で表す。
データ契約：提供者と利用者が、構造、意味、品質、配信、変更、責任について合意する仕組み。
粒度：一行が表す事実の単位。注文単位と注文明細単位を混在させない。
適時性：利用時点でデータが必要な新しさを満たす性質。単なる処理速度とは異なる。

要件受入シナリオを業務の言葉で作る

受入テストは、ボタンやフィルターが動くかだけでなく、判断の前提が崩れた条件を含めます。正常月だけではなく、締め遅延、返品、組織改編、欠損、重複、権限外データ、過去訂正を含む代表シナリオを用意し、利用者が誤判断せず次の行動を選べるかを確認します。

正常系：計画差の主要因を概要から明細まで追い、責任者と期限を決められる。
境界値：月末・年度跨ぎ、通貨換算、閾値直前・直後で表示と判定が一貫する。
不完全データ：未着・欠損・品質違反をゼロや前回値と混同せず、状態と影響範囲を示す。
変更：KPI定義、組織階層、ソーススキーマの変更時に下流影響と新旧比較を確認できる。
障害：更新停止時に最終成功時刻、利用可否、代替手段、復旧見込みが伝わる。

試験結果には、期待値だけでなく、判断者、根拠データ、許容差、証跡、未解決リスクを残します。これにより、業務受入と技術受入を別々に完了させず、意思決定サービスとして一つの稼働可否判断を行えます。

要件の完了条件：成果物が埋まったことではなく、業務・データ・技術の各責任者が、同じ判断シナリオを説明し、未確定事項、制約、例外、残余リスクを認識した状態を完了とします。仮定には検証期限と責任者を付け、設計中に判明したソース制約は業務側へ戻して優先度を再判断します。承認会議では、正常時のデモだけでなく、データ遅延、品質違反、権限拒否、定義変更を提示し、利用者が画面の状態を正しく解釈できるかを確認します。未解決事項は重要度、回避策、期限、受容者を決定記録へ残し、稼働判定後も追跡します。

まとめ：最初の成果物は画面ではなく「判断の連鎖」

BI要件定義の成否は、機能数ではなく「経営目的→問い→KPI→データ→分析→行動→効果確認」が切れずにつながっているかで判断します。まず重要な意思決定を一つ選び、利用者と60〜90分のワークショップで問い・比較・行動を言語化してください。その後にKPI定義と必要なデータを用意できるかを確認し、対象を絞ったプロトタイプで、判断が本当に変わるかを試します。

BI構想・要件定義を、経営とデータの両面から整理しませんか

Version株式会社は、意思決定設計、KPI定義、データアーキテクチャ、ガバナンス、導入ロードマップを一体で支援します。既存要件のレビューや短期ワークショップからでもご相談いただけます。

BI導入・要件定義について相談する

BI／DWHテーマクラスター：BI要件定義／経営ダッシュボード／セルフサービスBI統制／ DWH・データレイク・レイクハウス／ DWH要件定義／セマンティックレイヤー／ BI数値不一致とリネージュ／レガシーDWH刷新／ BI CoE ／ DWH受入テスト

参考資料

経営ダッシュボードの設計原則――KGI・KPI・アクションを一画面でつなぐ