そのダッシュボード、誰のどの判断に使いますか — 作る前に決めること | GH Media
URLがコピーされました

そのダッシュボード、誰のどの判断に使いますか — 作る前に決めること

URLがコピーされました
そのダッシュボード、誰のどの判断に使いますか — 作る前に決めること

管理画面のトップに、売上、受注件数、稼働率、在庫、問い合わせ数が並んでいる。グラフは綺麗で、数字はリアルタイムで更新される。そして3ヶ月後、開いているのは作った本人だけです。

制作会社に頼んで作ったダッシュボードが使われなくなるとき、後から出てくる感想はだいたい同じです。「見ても、それで何をすればいいのか分からなかった」。グラフの見た目の問題ではありません。画面が答えている問いが、誰の問いでもなかったという問題です。

Smashing Magazine が2026年8月26日に公開した記事で、Meriem Benhabiles 氏はデータ可視化を「データとデザインという、ふだん会話しない2つの領域の交差点」と位置づけ、ツールを開く前に問いを立てることから始めるべきだと書いています。発注する側にとっても、この順番は同じです。

「見たい数字」から始めると、全部載る

要件を詰める打ち合わせで、こういう進み方をすることがあります。

「どの数字が見たいですか」と聞かれる。関係者がそれぞれ答える。営業は受注件数、経理は入金状況、現場は稼働率。全部を並べると誰も反対しないので、そのまま要件になる。

この進め方の問題は、載せない理由が最後まで出てこないことです。 誰かが挙げた以上、外すには「要らない」と言う必要がある。角が立つので誰も言わない。結果、1画面に15個のカードが並びます。

開いた人は、まずどこを見ればいいのか分からない。 分からない画面は、2回目に開かれません。

起点を「数字」から「判断」に置き換える

代わりに立てる問いは1つです。「この画面を見た人は、そのあと何をするのか」。

たとえば受注件数のグラフがあるとします。これを見て何をするのか。答えが「今週の営業の追い込み先を決める」なら、必要なのは全社の合計推移ではなく、担当者ごとの進捗と、締めまでの残日数です。同じ「受注件数」でも、判断が違えば必要な形が変わります。

答えが出てこない数字もあります。「見ておきたいから」としか言えないもの。それはダッシュボードではなくレポートの領域です。月次で PDF に出せば足ります。常時表示する画面に置くと、判断に使う数字を埋もれさせるだけです。

Nielsen Norman Group は、ダッシュボードを時間の制約がある判断を素早く支える運用型と、傾向を探索して発見するための分析型に分けて論じています。この2つは求められる情報密度も更新頻度も違います。1画面に両方を詰めようとした時点で、どちらの用途にも中途半端になります。

ダッシュボードの要件を「見たい数字」から積み上げた場合と「判断」から逆算した場合で、画面に載る要素がどう変わるかを対比した図

1画面1判断に寄せる

実務で扱いやすいのは、画面を判断の単位で分けるやり方です。

  • 今日動くべき案件を決める画面(運用型・毎日開く)
  • 今月の着地を見積もる画面(運用型・週次)
  • どの商材が伸びているかを探る画面(分析型・月次)

分けると、1画面に載る要素は3〜5個に落ち着きます。多くの人が「情報が減った」と感じますが、実際に減ったのは判断に関係しない情報だけです。

このとき、画面ごとに「誰が」「どの頻度で」開くかも一緒に決めます。毎日開く画面と月に一度の画面では、置き場所も、必要な読み込み速度も変わります。月次レポートをどこに置くかという判断と同じ話が、ここでも効いてきます。

リアルタイム更新は、要件になる前に費用を聞く

発注時に見落とされやすいのが更新頻度です。「リアルタイムで見たい」という要望は自然に出ますが、これは実装コストと運用コストの両方を大きく動かします。

日次のバッチ更新なら、夜間に集計して静的に配れば済みます。リアルタイムとなると、集計処理が常時走り、基幹側への問い合わせが増え、負荷対策が必要になります。画面の見た目は変わらないのに、費用は変わります。

判断の頻度から逆算するのが確実です。週に1回しか使わない判断のために、常時更新の仕組みを作る必要はありません。 逆に、当日の出荷可否を決める画面なら、遅延は致命的です。ここは要件を出す側が決めるべきところで、制作側からは決められません。

受け入れ条件は「開けること」ではない

納品時のチェックが「画面が表示され、数字が正しい」で終わると、使われるかどうかは検証されないまま終わります。

代わりに置ける条件があります。実際の担当者が、その画面だけを見て、想定した判断を下せるか。 開発中に一度、判断する当人に触ってもらい、「これを見て次に何をしますか」と聞く。答えが詰まるなら、載せる情報か並べ方が合っていません。

外部システム連携の受け入れ条件を先に文章にしておくのと同じで、曖昧なまま進むと、直す根拠が後から作れなくなります。 「使いにくい」は仕様変更の理由になりにくく、「想定した判断ができない」は理由になります。

作らずに済ませられる場合もある

判断が1つか2つで、関係者も数人という規模なら、専用のダッシュボードを作らずに済むこともあります。スプレッドシートに日次で書き出すだけで足りる、というケースは実際にあります。ノーコードで業務アプリを立てる選択肢も同じ位置づけです。

判断の数が増え、見る人が部署をまたぎ、手作業の集計が追いつかなくなったときが、作る意味が出てくる分岐点です。そこに達していない段階で作ると、使われないまま保守費だけが残ります。

次にやること

まず、社内で今いちばん頻繁に行われている数字を見る判断を1つ、名前を付けて書き出してください。 「毎週月曜に、今週訪問する先を決めている」といった粒度で構いません。その判断に、いま何分かかっているかも一緒に測ります。

そのうえで、その判断に必要な数字だけを紙に書き出してください。 3個で足りるなら、作るべき画面は3個の数字が載った画面です。ここで15個並ぶなら、判断がまだ1つに絞れていません。

業務システムの管理画面設計、データの集計基盤、既存システムからのダッシュボード構築については、グリームハブの開発・AI・自動化のご相談で承っています。判断の種類とデータの持ち方によって適切な構成が変わるため、個別にご相談ください。お問い合わせからどうぞ。

Sources

無料ダウンロード

Web制作 費用・発注・集客 完全ガイド【2026年版】

費用相場・制作会社の選び方・集客戦略まで、中小企業のWeb担当者が知っておくべき全知識をPDFにまとめました。

メルマガにも登録されます。いつでも解除可能です。

URLがコピーされました

グリームハブ株式会社は、変化の激しい時代において、アイデアを形にし、人がもっと自由に、もっと創造的に生きられる世界を目指しています。

記事を書いた人

鈴木 翔

鈴木 翔

技術の可能性に魅了され、学生時代からプログラミングとデジタルアートの分野に深い関心を持つ

関連記事

「WEB」の記事一覧を見る