経営会議で使われないダッシュボードが量産される原因は、配色でもレイアウトでもUXでもなく、「意思決定プロセスとの非接続」にあります。渾身のダッシュボードを構築したにもかかわらず、会議の冒頭でPDF化されたExcel表が配布される光景、その横で誰も触らないBIツールのURLが読み上げられるだけの状況。この現象は個別チームの怠慢ではなく、ダッシュボード設計の構造的欠陥から生まれます。本記事では、量産サイクルのメカニズムを解きほぐし、「見る」ためではなく「決める」ためのダッシュボード設計に至るまでを整理します。
「使われないダッシュボード」の量産パターン
ダッシュボードが量産されては放置されるプロセスは、組織の多くで驚くほど似通っています。「可視化せよ」という経営層の号令で始まり、要件定義を経ずに制作、お披露目後2〜3ヶ月で閲覧ゼロ、そして次のダッシュボードが制作され始める、という無限ループです。このサイクルは個々の担当者が悪いわけではなく、組織側の「ダッシュボードを作れば意思決定が変わる」という素朴な期待が原因となっています。
| フェーズ | 活動 | 結果 | 根本原因 |
|---|---|---|---|
| 1. 発意 | 「データで経営判断を」と号令 | 構築プロジェクト始動 | 目的と意思決定が未定義 |
| 2. 要件 | 「見たい情報」を全部並べる | 50指標の巨大DB | 捨てる議論が未実施 |
| 3. 構築 | BIツールで画面を組み立てる | 初期版リリース | 意思決定プロセス未接続 |
| 4. お披露目 | 経営会議で紹介 | 拍手、しかし議論は続かず | 使用シーンが未設計 |
| 5. 停滞 | 2〜3ヶ月後、閲覧ゼロ | Excel配布に回帰 | データ鮮度・信頼性への不信 |
| 6. 再発 | 「新しいKPIダッシュボードを」 | 次のDB制作開始 | 原因分析の欠如 |
ダッシュボードが使われない4つの構造的理由
意思決定のタイミングと更新頻度のミスマッチ
経営会議は週次もしくは月次で開催されるのに、ダッシュボードのデータ更新は日次、場合によってはリアルタイムという設計を見かけます。会議体のリズムとデータ鮮度が合わないと、「このダッシュボードはいつ見ればいいのか」が曖昧になり、結局は誰も定期的に開かなくなります。逆に、営業現場で毎時判断したい指標が週次更新になっていると、現場はExcelに逃げていきます。
「見たい情報」と「載っている情報」のズレ
要件定義の段階で「何の意思決定のために使うのか」を問わず、「とりあえず見たい指標」を並べていくと、ダッシュボードは博物館の展示棚のようになります。情報は豊富だが、どの情報が何の判断に使うのかが不明で、会議で開いても「ふーん」で終わります。意思決定が先、指標は後、という順序を守れていないと必ずこの状態に陥ります。
データの信頼性への不信
「先月の営業会議でダッシュボードの数字とExcelの数字が合わなかった」という経験が一度あると、経営層の信頼は回復しません。データの整合性が疑われるダッシュボードは、たとえ見栄えが完璧でも意思決定には使われません。裏側のデータパイプラインの品質管理、および齟齬が起きたときの原因追跡の仕組みが整っていないと、この不信は必ず発生します。
既存の意思決定プロセスへの未統合
ダッシュボードを作っても、会議のアジェンダが変わらなければ誰も開きません。「毎週月曜の営業会議の冒頭5分でダッシュボードの該当タブを開く」というルールまで落とし込まれて、初めて定着します。ところが多くの組織では、ダッシュボードは作って終わりで、会議体との接続設計は後回しにされます。
【ダッシュボードが使われなくなるサイクル】
[経営が号令] --> [指標を並べる] --> [BIで構築] --> [お披露目]
^ |
| v
[Excel配布に回帰] <-- [閲覧ゼロ] <-- [数字の不一致発生]
^ |
| v
[新DB制作の発意] <---------- [原因分析なし]
※ 意思決定との接続がない限り、何度作っても同じ末路を辿る
「使われるダッシュボード」の設計原則
それでは、使われるダッシュボードはどう設計すべきでしょうか。5つの原則を提示します。
- 意思決定とセットで設計する:「どの会議で、どの判断のために、誰が見るか」を要件定義の冒頭に書く
- 最重要KPIを3つに絞る:最上段に3指標、それ以外はドリルダウンで配置
- アクションを示唆する設計:赤黄緑の閾値と「次の一手」のガイドをセットで表示
- データの鮮度と信頼性の担保:更新日時の表示、不整合検知の仕組みを実装
- 定期レビューでの活用を前提とする:会議アジェンダに組み込まれるところまで設計
| 観点 | 使われないダッシュボード | 使われるダッシュボード |
|---|---|---|
| 起点 | 「見たい情報」から発想 | 「決めたい判断」から逆算 |
| 指標数 | 20〜50指標を並列表示 | 最重要3指標+ドリルダウン |
| 更新頻度 | 何となく日次 | 意思決定のリズムに合わせる |
| 閾値 | 数字のみ表示 | 赤黄緑で即判断可能 |
| アクション | 解釈は閲覧者任せ | 「次の一手」のガイドを併記 |
| 運用 | 作って終わり | 会議アジェンダに組込み |
| 信頼性 | 数字の出所不明 | 更新時刻と定義を明示 |
【意思決定プロセスとダッシュボードの接続設計】
[月次経営会議]
| 議題1: 全社KPI進捗
| └── ダッシュボード「全社KPI」を開く
| └── 赤信号あり → 議題2へエスカレーション
|
| 議題2: 課題事業の深掘り
| └── ダッシュボード「事業別」ドリルダウン
| └── 次アクション: 責任者と期限を決める
|
| 議題3: 意思決定ログの更新
└── 決定事項をダッシュボードにメモ追記
※ ダッシュボードが会議の「道具」として定位置を持つこと
ダッシュボード断捨離のすすめ
既に大量のダッシュボードが散乱している組織では、新規設計に入る前に「棚卸し」が必要です。BIツールの管理画面から全ダッシュボードの利用ログを取得し、以下の基準で分類します。
- 廃止候補:3ヶ月以上閲覧ゼロ、または月間閲覧5回未満
- 統合候補:類似内容が他DBに存在、オーナーが不在
- 改修候補:利用はされているが意思決定との接続が不明
- 維持:会議アジェンダに明示的に組み込まれている
廃止候補にしたダッシュボードは、いきなり削除せず「一時アーカイブ」に移動し、60日間誰からも問い合わせがなければ本削除します。この期間を設けるのは、何か重要な判断が暗黙のうちに依存している可能性を潰すためです。断捨離を進めると、多くの組織で既存ダッシュボードの60〜80%が不要と判明します。驚くべき数字ですが、これが現実です。重要なのは、削除することそのものではなく、「なぜ使われていないか」の原因を次の新規設計にフィードバックすることです。
事例に見る「使われるダッシュボード」
事例A:EC事業の意思決定リズム再設計
あるEC事業では、12種類の経営ダッシュボードが存在し、いずれも閲覧数が月10回未満という状態でした。コンサルティング介入後、会議体を棚卸しし「週次営業会議」「月次経営会議」の2つに絞り、それぞれに対応するダッシュボードを1枚ずつ再設計しました。旧12ダッシュボードはすべてアーカイブ。新しいダッシュボードは会議冒頭5分の定型アジェンダに組み込まれ、3ヶ月後には週次閲覧数が40倍、会議時間は平均30分短縮されました。
事例B:店舗オペレーションへの組み込み
小売チェーンの店舗運営チームは、本部から配布される膨大な日次レポートを印刷して壁に貼るという運用を続けていました。店長の9割が「見ていない」と回答。本部は店舗の意思決定場面を観察し直し、「開店前のスタンドアップで2分だけ見る」ダッシュボードを設計しました。表示項目は在庫アラート、前日売上、本日の販促イベントの3点のみ。アクセスはタブレットから1タップ。導入後、店舗側の自発的閲覧率は12%から87%に上昇しました。
まとめ――ダッシュボードは「見る」ためではなく「決める」ためにある
使われるダッシュボードを作るための核心をまとめます。
- ダッシュボードは「可視化ツール」ではなく「意思決定の道具」である
- 設計の起点は「何の判断に使うか」、指標の選定はその後
- 最重要KPIは3つに絞り、情報量で価値を主張しない
- 会議アジェンダへの組み込みまでが設計範囲である
- 既存ダッシュボードの断捨離は、新規設計より先に行うべきである
DE-STKでは、意思決定プロセスの観察から、既存ダッシュボードの棚卸し、会議体への接続設計まで伴走しています。関連記事としてセルフサービスBIの落とし穴、KPIを100個設定した会社に起きたこと、データドリブンを掲げた会社がデータ疲れに陥るメカニズムもご覧ください。
よくある質問
Q1. ダッシュボードが使われない最大の原因は何ですか?
デザインの問題ではなく、意思決定プロセスに統合されていないことが最大の原因です。ダッシュボードは「何を見るか」ではなく「何を決めるか」から逆算して設計する必要があります。
Q2. 経営ダッシュボードに載せるべきKPIの数は?
最重要KPIは3つに絞ることを推奨します。情報過多のダッシュボードは「何も伝えないダッシュボード」と同義です。補足的な指標はドリルダウンで参照できる設計にします。
Q3. 使われないダッシュボードをどう整理すればよいですか?
まず全ダッシュボードの利用ログ(閲覧数・最終閲覧日)を取得し、3ヶ月以上未閲覧のものを「廃止候補」として棚卸しします。オーナーに確認の上、段階的にアーカイブ・削除します。