【テンプレート付】BIツールの要件定義｜機能要件・非機能要件チェックリストと進め方

BIツールの要件定義とは

BIツールにおける要件定義とは、経営や製造現場の意思決定に必要なKPI・ダッシュボード・分析の要件を、データソース、データモデル、更新頻度、閲覧者の役割と権限まで含めて具体化する工程です。単なる帳票の置き換えではなく、基幹システムやIoTデータをどう統合し、どの粒度（製品別・ライン別・ロット別など）でドリルダウンするかまで定義します。BIは「作って終わり」ではなく継続的に育てる前提のため、誰がデータモデルとダッシュボードを保守するかの体制も要件に含めます。

なぜ要件定義でBIツール導入の成否が決まるのか

BIツールは導入後に「ダッシュボードは作ったが誰も見ない」「数字がシステムごとに食い違う」という形で失敗が表面化しますが、その原因のほとんどは要件定義段階でのKPI定義とデータソースの整合性の詰め不足にあります。

• 見たい指標を決めずにツールを選ぶと、ダッシュボードが乱立し「数字の正本」が不明になる
• 基幹システムのデータ品質（コードの揺れ・欠損）を確認せず、BI側のデータモデルで吸収しきれない
• データの更新頻度（リアルタイム/日次バッチ）と現場の意思決定サイクルが合わず、使われなくなる
• セルフサービスBIの権限設計を後回しにし、原価や利益データが見るべきでない人に共有される

要件定義で決める5つの範囲

1. データソース連携 — ERP・生産管理・MES・IoT・Excelなど、BIに取り込む対象システムと接続方式の範囲
2. データモデル/ETL — データ統合・クレンジング・スタースキーマ設計など、可視化前のデータ整備の範囲
3. ダッシュボード/レポート — 経営・製造・品質など役割別に作成するダッシュボードと帳票の範囲
4. セルフサービス分析 — 現場ユーザーが自らドリルダウン・アドホック分析を行う範囲と教育の範囲
5. ガバナンス/運用 — 権限管理、データの正本管理、ダッシュボードの保守・廃止ルールの範囲

BIは「データ取り込み（ETL）」と「可視化」のどちらまでをツールで賄い、どこを既存のデータ基盤（DWH等）に任せるかの線引きを最初に明確化することが重要です。

要件定義の進め方：5ステップ

ステップ	内容	アウトプット
①	経営課題と意思決定シーンを洗い出し、誰がどの判断のために何の数字を見るかを定義する	KPIツリー、利用シーン一覧、閲覧者の役割定義
②	対象データソースを棚卸しし、各システムの項目・更新頻度・データ品質を調査する	データソース一覧、項目定義書、データ品質チェック結果
③	KPIの計算ロジックと粒度を確定し、データモデル（ファクト/ディメンション）を設計する	指標定義書、データモデル図、ドリルダウン階層
④	役割別のダッシュボードと帳票のワイヤーフレーム、更新頻度、権限を定義する	ダッシュボード要件書、画面モックアップ、権限マトリクス
⑤	非機能要件・連携要件・運用保守体制を整理し、RFPと評価基準にまとめる	RFP、評価基準書、運用保守体制案

BIではKPIを「売上高」のような結果指標だけでなく、設備稼働率・直行率・在庫回転日数・リードタイムなど、製造現場が日々アクションできる先行指標まで含めて定義します。

機能要件チェックリスト（BIツールの核心）

BIツールに求める代表的な機能要件です。自社の状況に照らして「必須／任意／不要」を判断してください。

大分類	主な要件項目
データ接続/取り込み	ERP・生産管理システムへのDB直接接続, CSV/Excel取り込み, IoT・PLCデータ連携, クラウドアプリのAPI連携
データ統合/ETL	データのクレンジング・名寄せ, コード変換・マスタ統合, スケジュール更新（増分更新）, 複数ソースのブレンド（結合）
データモデリング	スタースキーマ設計, 計算フィールド・メジャー定義, 階層（年月日・製品分類）定義, リレーションシップ設定
可視化/ダッシュボード	グラフ・KPIカード・ヒートマップ, ドリルダウン/ドリルスルー, フィルタ・パラメータ操作, 地図・管理図など製造向け表現
分析機能	アドホック分析（セルフサービス）, 期間比較・前年比・予実対比, 異常値・閾値アラート, 簡易な予測・トレンド分析
レポート配信	定期スケジュール配信（メール）, PDF/Excelエクスポート, 帳票レイアウト（定型帳票）, Slack・Teamsへの通知連携
権限/セキュリティ	ロール別アクセス制御, 行レベルセキュリティ（部門別・工場別）, 列レベルでの原価情報の制御, SSO/IdP連携
データガバナンス	認定済みデータセットの管理, 指標定義の一元管理（データカタログ）, データ系統（リネージ）追跡, ダッシュボードのバージョン管理
モバイル/共有	モバイル端末での閲覧最適化, ダッシュボードの埋め込み（Embed）, 外部公開URL発行, コメント・注釈機能
管理機能	利用状況モニタリング, ライセンス・ユーザー管理, クエリパフォーマンスの監視, スケジュール処理の実行ログ

見落としがちな要件: 見落としがちなのは「行レベルセキュリティ」と「指標定義の一元管理」です。工場別・部門別に見える行を制御できないと原価データが漏れ、指標定義が散在すると同じ『稼働率』でも分母が異なり数字が食い違います。また増分更新（差分のみ取り込む）への対応可否は、大量の生産実績データを扱う製造業では性能を左右する必須要件です。

非機能要件で見落としがちなポイント

機能だけに目が向きがちですが、非機能要件こそ稼働後の満足度を左右します。

区分	確認すべき要件（目標値の例）
性能	ダッシュボード初期表示3秒以内、数千万行のファクトテーブルでもフィルタ応答が体感的に許容範囲（インメモリ/抽出活用）
可用性	経営会議や日次朝礼で使うため平日稼働時間の可用率99.5%以上、夜間バッチ失敗時の再実行・通知の仕組み
拡張性	閲覧ユーザーの増加（数十→数百名）やデータ量の増加に対し、ライセンス追加・スケールアウトで対応可能なこと
セキュリティ	行レベルセキュリティ、通信・保存データの暗号化、監査ログ取得、SSO/多要素認証への対応
運用保守	データモデルとダッシュボードの保守をベンダー依存せず内製できる学習コスト、更新処理の監視運用負荷
移行	既存のExcel帳票・旧BIからのダッシュボード移行範囲と並行稼働期間、過去データの取り込み範囲
コンプライアンス	原価・取引先など機微情報の閲覧範囲統制、内部統制（J-SOX）に必要なアクセスログと証跡の保管

特に性能は、生産実績のような大量明細データを扱う製造業BIで最も問題になりやすいため、抽出（エクストラクト）やインメモリエンジンの活用方針を要件段階で決めておきます。

基幹・周辺システムとの連携要件

どのシステムと、何を、どの方式（API/CSV/EDI）で、どの頻度で連携するかを定義します。

連携先	主な連携内容
ERP（SAP・OBIC7・GRANDIT等）	売上・原価・在庫・購買データを会計/販売モジュールから取得し、収益性ダッシュボードの基礎データとする
生産管理/MESシステム	生産計画・実績・進捗・不良データを取得し、稼働率・直行率・リードタイムを可視化する
IoTプラットフォーム/PLC・SCADA	設備の稼働信号やセンサーデータを収集し、設備総合効率（OEE）や予兆監視ダッシュボードに反映する
DWH/データレイク（BigQuery・Snowflake・Redshift等）	統合済みの分析用データをライブ接続または抽出で取り込み、BIの主要データソースとする
勤怠/人事システム	工数・労務費データを取得し、製造原価の労務費按分や人時生産性の分析に利用する
Excel/Googleスプレッドシート	マスタ補正値や手入力の計画値を取り込み、実績データと突き合わせて予実管理を行う
コラボレーションツール（Teams・Slack）	閾値超過アラートやレポートを自動配信し、現場の迅速なアクションにつなげる

製造業BIでは基幹系（ERP・生産管理）と制御系（IoT・PLC）という性質の異なるデータをどう一つのデータモデルに束ねるかが連携設計の肝になります。

RFP（提案依頼書）に盛り込むべき項目

要件が固まったら、ベンダーへの提案依頼書（RFP）にまとめます。最低限、次の項目を含めます。

• 導入目的・対象KPI・主要ダッシュボードのイメージと閲覧者の役割
• 接続が必要なデータソース一覧と各システムの接続方式・データ量・更新頻度
• 機能要件一覧（データ統合・モデリング・可視化・権限・ガバナンス）と必須/任意の区分
• 非機能要件（性能目標・行レベルセキュリティ・可用性・監査ログ）
• ライセンス体系（閲覧者/作成者別）と想定ユーザー数での総保有コスト（TCO）
• 導入支援・データモデル設計支援・内製化教育・保守サポートの範囲

ライセンスは閲覧者と作成者で単価が大きく異なるため、想定ユーザー構成を明示して5年程度のTCOで比較できるよう依頼します。

ベンダーを横並び比較する評価マトリクス

ベンダー評価は、データソース連携の実現性とデータモデリングの柔軟性を最重視し（合わせて50%程度）、可視化表現力・セルフサービス性・ガバナンス機能（30%程度）、TCOと内製化支援・サポート体制（20%程度）といった重み付けで多角的に評価します。

デモは自社の実データの一部を渡してダッシュボードを試作させるPoCで、性能と表現力を実際に確認することが重要です。

BIツール導入でよくある失敗と回避策

よくある失敗	原因	回避策
ダッシュボードを大量に作ったが誰も使わない	意思決定シーンとKPIを定義せず、現場の見たい数字とずれた帳票を量産した	要件定義で利用シーンとKPIツリーを確定し、各ダッシュボードに対応する意思決定を紐づける
システムごとに数字が食い違い信頼されない	指標の計算ロジックや分母の定義が統一されず、データの正本も決まっていない	指標定義書で計算ロジックと粒度を一元管理し、認定済みデータセットを正本として運用する
大量データでダッシュボードが重く実用に耐えない	数千万行の生産実績にライブ接続し、毎回フルスキャンが走る設計にした	抽出（インメモリ）と増分更新を前提にデータモデルを集約し、性能を要件段階で検証する
導入後に改修できずベンダー任せで形骸化する	データモデルとダッシュボードの保守を内製化する体制・教育を要件に入れなかった	管理者・作成者の育成計画と社内のBI推進担当（データスチュワード）を要件に明記する

チェックリストの使い方（テンプレートとして使う）

本記事の機能要件・非機能要件・連携要件・評価マトリクスの各表は、そのまま要件定義の雛形（テンプレート）として使えます。表をコピーして自社に必要な項目の「要否」「優先度」を記入し、ベンダー回答を並べて比較してください。

1. 各表で自社に必要な項目の要否（必須/任意/不要）と優先度を記入する
2. 不足する自社固有の要件を追記する
3. ベンダー回答（○標準/△設定・追加開発/×不可）を記入する
4. 評価マトリクスで重みと評点を入れ、加重スコアで横並び比較する

※ 記入と加重スコアの自動集計ができるExcelテンプレート（ダウンロード版）は近日公開予定です。