「ダッシュボードは作ったんですが、誰も見てないんですよね」
正直に言うと、この相談は珍しくありません。要件を聞き取り、指標を並べ、色まで整えて納品したダッシュボードが、数ヶ月後には誰にも開かれなくなっている——GTMエンジニアリングやSalesforce実装の現場で、何度も見かける光景です。原因は見た目でも技術力でもなく、たいてい設計の入り口にあります。
設計の3原則
- 1. 視聴者を1人（1役割）に絞る
- 経営層向け・現場マネージャー向け・現場担当者向けでは、必要な粒度も更新頻度もまったく異なる。「全員向け」のダッシュボードは、結局誰にも刺さらない
- 2. 見た人が次に取るアクションが決まっている
- 「この数値がこの範囲を下回ったら、この人が、この対応をする」まで設計されているか。眺めるだけで終わる数値の羅列は、ダッシュボードではなくレポートに過ぎない
- 3. 更新頻度と意思決定の頻度を一致させる
- 週次で意思決定する指標を月次でしか更新しないダッシュボードは使われなくなる。逆に、月次でしか動かせない指標をリアルタイム更新にするのは開発コストの無駄
経営層向け・現場向けダッシュボードの違い
「詳細度」と「更新頻度」の2軸で位置づけを整理すると、視聴者ごとに求められるダッシュボードの形がまったく違うことが分かります。
案件単位の詳細＋週次更新。ボトルネックの特定に使う
個人のタスク単位の詳細＋日次更新。日々の実行管理に使う
全社サマリー＋月次更新。トレンドと意思決定に使う（最も設計を誤りやすい象限）
異常検知のサマリー＋リアルタイム更新。閾値超過の通知に使う
経営層向けダッシュボードに現場の詳細データをそのまま詰め込むと、情報過多で本来の「意思決定の道具」という機能を失います。経営層には、KPIツリーの上位2〜3層程度に絞ったサマリーで十分な場合がほとんどです。
ここで、先に反論しておきます。「経営層はデータに強いのだから、詳細まで見せた方が親切では」と思うかもしれません。実際、そう言われて詳細画面をそのまま経営会議に出したことのある人も多いはずです。ですが、経営層に求められているのは現場の詳細を読み解く時間ではなく、限られた会議時間の中で次の意思決定を下すことです。詳細を見せる余地はドリルダウンとして残しておけば十分で、トップ画面を詳細で埋める必要はありません。
指標の粒度とドリルダウン設計
- トップ画面はサマリー指標（KPIツリーの頂点〜第2層）のみに絞る
- 「なぜこの数字なのか」を確認したい場合に、クリックして下位層（部門別・案件別）へドリルダウンできる設計にする
- ドリルダウンの階層は、実際のKPIツリーの階層構造と一致させる（ダッシュボードの階層とKPIツリーの階層がズレていると、見ている人が迷子になる）
Vanity Metrics（見せかけの指標）を避ける
「増え続けるが意思決定に使えない指標」（累計登録者数、PV数など）はVanity Metricsと呼ばれます。見栄えは良いものの、それを見て次に何をすべきかが分からない指標は、ダッシュボードのトップに置くべきではありません。判断基準はシンプルです。「この数値が今より10%動いたら、誰が、何をするか」を即答できない指標は、トップ画面から外す候補です。
数値だけ並んだダッシュボードは、健康診断の結果表を受け取ったまま棚にしまい込むのに似ています。数値そのものは正確でも、「この値ならこう動く」という基準が本人の中になければ、次の行動にはつながりません。ダッシュボードも同じで、正確な数字を表示できているかどうかより、見た人の次の一手が決まっているかどうかで価値が決まります。
よくあるアンチパターン
- 指標の定義が画面ごとに違う
- 同じ「アクティブ顧客数」という名前でも、部門ごとに定義が違うと数字が合わず信頼を失う。「収益指標・RevOpsガイド」で触れたメトリクス辞書を先に整備してからダッシュボードを作る順序が安全
- 1画面に指標を詰め込みすぎる
- 「せっかく作るなら全部見せたい」という要望に応えた結果、視聴者が自分に関係する数字を探すのに時間がかかるダッシュボードになる。1画面1目的が基本
- 作った後の運用者がいない
- ダッシュボードは作って終わりではなく、データソース側の仕様変更（CRMの項目名変更等）に追従するメンテナンスが必要。運用担当が決まっていないダッシュボードは、半年後には数字がずれたまま放置されがち
今週やる：ダッシュボード構築の手順
この記事の原則を、実際に1枚のダッシュボードを作る作業に落とすと次の順序になります。
「経営層」「現場マネージャー」等の役割を1つだけ選び、その人が週に何回・何のために見るかを書き出す
選んだ視聴者が、詳細度×更新頻度のどの象限に該当するかをQuadrantDiagramの4象限で確認し、粒度と更新頻度のズレがないか点検する
「この数値がこの範囲を下回ったら、誰が、何をするか」を指標ごとに1文で書く。書けない指標はトップ画面の候補から外す
「10%動いたら誰が何をするか」を即答できない指標（累計登録者数等）をリストから削る
使う指標の定義が部門間で揺れていないか、既存の指標定義書と突き合わせる。なければ先に定義を1行で書いてから実装する
データソース側の仕様変更に追従する担当者を1人決めてから公開する
「アクションを先に定義する」ステップは、そのままコピーして埋められるフォーマットです。
| 指標名 | 閾値条件 | 対応者 | アクション |
|---|---|---|---|
| 記入例パイプラインカバレッジ | 記入例目標の3倍を下回ったら | 記入例セールスマネージャー | 記入例獲得チャネル別に商談創出施策を追加投入する |
よくある質問
- BIツールは何を選べばいいですか
- 特定のツールより、まず「誰が・何を・どの頻度で見るか」を決める設計作業が優先です。Salesforce標準レポートで十分な場合も多く、Tableau・Looker等の専用BIツールが必要になるのは、複数システムを横断した集計や高度な権限管理が必要になってからで十分なケースがほとんどです
- 経営層から『とりあえず全部見せて』と言われたらどうすればいいですか
- サマリー画面をまず見せた上で、必要な数字にはドリルダウンでいつでもアクセスできる設計になっていることを説明するのが実務的な対応です。全指標を1画面に並べることと、全指標にアクセスできることは同じではありません
問い
今あるダッシュボードを1枚思い浮かべてください。そこに並ぶ指標のうち、「この数字がこう動いたら、自分はこう動く」と即答できるものはいくつあるでしょうか。答えられない指標が半分を超えているなら、それはダッシュボードではなく、まだレポートのままかもしれません。