「分析」を不要にする。現場がすぐに動ける「診断型」ダッシュボードを作った話

こんにちは！株式会社タイミーでデータアナリストをしている shun です。

普段は、プロダクトや事業の意思決定を支援するためのデータ分析を行っています。

本記事では「現場で本当に使われるダッシュボード」について、私の失敗談と改善の実践録をご紹介します。

なお、この記事は Timee Advent Calendar 2025 Series 2 の 7日目の記事です。

はじめに：使われなくなるダッシュボードは「目的」が混在している

本題に入る前に、ダッシュボードの分類を整理しておきましょう。

誰しも経験がある「気合いを入れて作ったのに、現場で使われない...」そんな悲しいダッシュボードが生まれる最大の原因は、「誰に・何のために」という目的の型が混在していることにあると考えています。

デジタル庁が公開している『ダッシュボード構築・運用ガイドブック』などを参考に、私はダッシュボードを以下の3つに分類して考えています。

分類	① 提示型	② 業務型	③ 探索型
主な利用者	経営層・マネジャー	現場担当者	アナリスト
目的	主要指標のモニタリング	今のステータス確認	要因解析・仮説検証
粒度	概況（サマリ）	詳細（個別の明細）	概況 → 詳細（ドリルダウン）
ネクストアクション	意思決定	改善アクション（即時対応）	施策立案

今回、私がフォーカスするのは真ん中の「② 業務型」です。

ここを履き違えて、現場向けなのに「探索型」のような複雑なフィルタ機能や多角的なグラフを入れてしまうことが、失敗の始まりでした。

課題感：何をすべきか不明瞭な現場、原因解明に追われるアナリスト

以前の私は、現場に対して「探索型」に近い、情報てんこ盛りのダッシュボードを提供していました。その結果、現場とアナリストの間で、以下のような「負のループ」が発生していました。

現場：指標が悪化するが、ダッシュボードの情報量が多すぎて「どこが悪いか」特定できない。
アナリスト：現場から「数字が悪い理由を調べて」と依頼が飛んでくる。
アナリスト：他のタスクを止めて原因分析（探索）を行う。原因が特定できた頃には数日が経過している。
現場：原因はわかったが、「で、具体的に今日何をすればいいの？」というアクションがわからず、手が止まる。

つまり、「分析すること」自体に工数が取られ、肝心の「リカバリーのアクション」が後回しになっていたのです。

現場ヒアリングを通じてわかったのは、彼らに必要なのは「なぜ悪いか（Why）」の詳細な解説ではなく、「今すぐに何をすべきか（What）」の指示でした。

コンセプト：目指したのは「見てすぐに動ける診断表」

この負のループを断ち切るために、現場へのヒアリングを通じてダッシュボードの設計思想を根本から変えました。

目指したのは、データを探索させるツールではなく、健康診断のように「悪い箇所（診断）」と「処方箋（アクション）」が一目でわかる「診断表」です。

具体的に設計・構築で意識したポイントは以下の2点です。

1. 情報量は「PC1画面」サイズに収める

「スクロールが必要な時点で、現場は見なくなる」と決め打ちました。

情報はあればあるほど安心しますが、忙しい現場にとってはノイズでしかありません。

「念のため」置いていた予備のグラフや、推移を確認するためだけのチャートは全削除。
ファーストビューですべての「異常」が検知できるレイアウト。
徹底的に情報を断捨離し、ノートPCの1画面で完結させるUIにこだわりました。

2. 指標が悪いときの「初手」を決められる

これが今回の最大の肝です。

単に「数字が下がっています」とアラートを出すだけでは不十分です。

タイミーの現場における「指標悪化のパターン」を洗い出し、それに対応する「初手のアクション」をダッシュボード上に明記しました。

このように、ユーザーにグラフを読み解かせるのではなく、システム側でロジック判定を行い、「次はこれをやるべき」という推奨アクションまでを表示させるようにしました。

下記はダッシュボードのモックのイメージです

実装の工夫：分析結果はダッシュボードの「裏側」に込める

「見てすぐに動ける」を実現するためには、ダッシュボードの表側（UI）をシンプルにする分、裏側（ロジック）にアナリストの知見を詰め込む必要があります。

具体的には、以下の2点を意識して実装を行いました。

1. 指標悪化の「代表パターン」を網羅する

診断型ダッシュボードの生命線は、診断の精度の高さです。もし「診断結果: 周辺のユーザー不足」と出たのに、本当の原因が「掲載時間が短い」だった場合、現場は誤ったアクションをとることになり、ダッシュボードへの信頼は落ちてしまいます。

そこで実装前には、過去の指標とその課題カテゴリの関係性を徹底的に行い、指標が悪化する原因の大部分をカバーできるように設計しました。

もちろん個別の「レアケース」までは網羅できないので、発生頻度の高い「代表的な悪化パターン」を網羅することに注力しています。

2. 過去データに基づいた「閾値」設計

「どこからを要対応（赤色）とするか」の閾値決めも、アナリストの腕の見せどころです。

適当な基準で「要対応（赤色）」とするのではなく、過去のデータを分析し「このラインを割ったら、指標の悪化が顕著になる」というラインを算出して設定しました。

これにより、できるだけ「本当にヤバいときだけアラート」を出したり、要対応（赤色）になっている理由を聞かれたときに返答できるようにしています。

運用の工夫：他部署連携の「共通言語」として利用する

どれだけ良いダッシュボードを作っても、ダッシュボードの存在を認知してもらい、適切なユースケースで利用してもらう行動習慣をつくることは困難です。

そこで、このダッシュボードを単なるモニタリングツールではなく、他部署へアクションを依頼する際の「公式なコミュニケーションツール」として位置付けようとしています。

スクリーンショットを「依頼の切符」にする

業務の中で、営業がマーケティング部やデータアナリティクス部に協力を仰ぐ場面（例：マーケティングの対策をしてください）があります。

その際、チャットツール等での依頼には「ダッシュボードの診断結果のスクリーンショット」を貼ることをルール化しようとしています。

Before: 「最近稼働率が悪いからインストール数が下がっているから、広告出稿を増やしてほ欲しい」→「確かに数字は落ちているけど、本当に広告出稿不足が原因かな？広告費をかける前に、もう少し確証が欲しいな」というやりとりになる。
After: 「ダッシュボードで『エリアのワーカー不足「応募が集まりにくい状況」型』と診断が出ています（スクショ添付）。推奨アクションに従い、広告出稿をお願いします」

このように運用することで、ダッシュボードが「依頼の正当性」を証明する切符の役割を果たします。

ここからは、現在試行錯誤中ですが、「ダッシュボードでこう出ているから、XXをやってほしい」。というコミュニケーションフローを確立し、ダッシュボードを「見るもの」から「組織を円滑に動かすための武器」へと進化させていければなと思っています。