売上、案件数、在庫、問い合わせ件数、業務進捗などを一画面で確認するために、ダッシュボードを開発したいと考える企業は少なくありません。
しかし、ダッシュボード開発では、
「とりあえずグラフを並べる」
という進め方をすると、見た目はきれいでも実際の業務ではほとんど使われない画面になってしまうことがあります。
重要なのは、グラフのデザインより先に、
- 誰が見るのか
- 何を判断したいのか
- どの指標を見るのか
- どのデータから計算するのか
- 異常を見つけた後に何をするのか
を整理することです。
例えば営業ダッシュボードであれば、単純に「今月の売上」を表示するだけではなく、
売上が目標を下回っている
↓
どの担当者・商品・案件が原因なのか確認
↓
対象案件を開く
↓
次の対応を決める
というところまで考える必要があります。
つまり、使われるダッシュボードとは「数字を見る画面」ではなく、「判断して次の行動につなげる画面」です。
この記事では、業務システムにおけるダッシュボード開発の進め方を、指標設計、データ整理、グラフ、画面設計、権限管理まで具体的に解説します。
ダッシュボードとは
ダッシュボードとは、複数のデータや指標を一つの画面にまとめて表示し、業務状況を把握できるようにした画面です。
例えば営業部門であれば、
- 今月の売上
- 売上目標
- 商談件数
- 受注件数
- 受注率
- 担当者別売上
- 失注案件
- 対応期限超過案件
などを表示できます。
在庫管理なら、
- 総在庫数
- 在庫金額
- 在庫切れ商品
- 発注点以下の商品
- 入庫数
- 出庫数
- 商品カテゴリ別在庫
などです。
ダッシュボードによって、それまでExcelを集計しなければ分からなかった情報をリアルタイムまたは定期更新で確認できるようになります。
ダッシュボード開発で最も重要なのは指標設計
ダッシュボード開発ではデザインに注目しがちですが、最初に決めるべきなのはKPIや指標です。
例えば営業ダッシュボードを作るとき、
「何か売上のグラフを表示したい」
では要件として不十分です。
まず、
「このダッシュボードを見て何を判断したいのか」
を考えます。
例えば、
売上目標を達成できそうか知りたい
という目的なら、
- 売上実績
- 売上目標
- 達成率
- 受注予定金額
- 商談中金額
などが候補になります。
一方、
営業活動が停滞している案件を見つけたい
のであれば、
- 長期間更新されていない案件
- 次回対応日超過
- 商談ステータス
- 担当者別案件数
などが重要です。
目的によって必要な指標は変わります。
KPIと単なる集計値を混同しない
ダッシュボードには、表示できる数字を何でも載せればよいわけではありません。
例えば、
- 登録顧客数
- 商品数
- ログインユーザー数
- 過去の全案件数
などは取得できても、日常的な意思決定に使わないのであれば優先度は低い可能性があります。
KPI（重要業績評価指標）は、目標達成状況を判断するための重要な指標です。
例えば営業なら、
売上目標
↓
売上実績
↓
達成率
という関係があります。
さらに売上を作るための先行指標として、
- 商談数
- 見積提出数
- 受注率
- 平均案件単価
などを追うこともできます。
ダッシュボードでは、
「見られる数字」
ではなく、
「判断に使う数字」
を優先することが重要です。
ダッシュボード開発の基本的な進め方
ダッシュボード開発は、次のような流れで進めると整理しやすくなります。
- 利用目的を決める
- 利用者を整理する
- KPI・指標を決める
- データの取得元を整理する
- 指標の計算ルールを決める
- 画面構成を設計する
- グラフ・表現方法を選ぶ
- 詳細データへの導線を作る
- 権限を設計する
- 実際に利用して改善する
それぞれ詳しく見ていきます。
1．ダッシュボードの利用目的を決める
最初に、
「なぜダッシュボードが必要なのか」
を整理します。
例えば、
営業
毎朝、営業状況を確認したい
経営者
会社全体の売上・利益・案件状況を確認したい
在庫担当
欠品しそうな商品を早く発見したい
カスタマーサポート
対応漏れや問い合わせ増加を確認したい
といった目的です。
同じデータを使っていても、目的が異なればダッシュボードの構成も変わります。
2．誰がダッシュボードを見るのか決める
ダッシュボードは利用者によって必要な情報が異なります。
例えば営業システムなら、
営業担当者
- 自分の案件
- 今日対応すべき案件
- 自分の売上
- 次回対応日
営業マネージャー
- チーム売上
- 担当者別実績
- 受注率
- 停滞案件
経営者
- 全社売上
- 売上目標
- 受注見込み
- 部門別実績
など、見たい情報が異なります。
一つの画面に全情報を詰め込むより、役割ごとに必要な情報を分けた方が分かりやすくなる場合があります。
3．表示するKPI・指標を決める
目的と利用者が決まったら、具体的な指標を決めます。
例えば案件管理ダッシュボードなら、
- 案件総数
- 新規案件数
- 受注件数
- 失注件数
- 受注率
- 売上見込み
- 期限超過案件数
などです。
在庫管理なら、
- 商品数
- 総在庫数
- 在庫金額
- 在庫切れ数
- 発注点以下の商品数
- 入庫数
- 出庫数
が考えられます。
指標は多ければよいわけではない
例えば20個の数字を一画面に表示しても、
「結局どこを見ればよいのか分からない」
となる可能性があります。
重要度の高い指標を上部に配置し、詳細は下位画面で確認できるようにするなど、情報に優先順位を付けます。
4．データがどこにあるか整理する
表示したい指標が決まったら、その数字をどこから取得するのか確認します。
例えば売上ダッシュボードでも、
顧客情報
→ CRM
案件情報
→ 案件管理システム
請求情報
→ 会計システム
目標値
→ Excel
となっていることがあります。
この場合、一つのダッシュボードを作るために複数システムからデータを取得する必要があります。
方法としては、
- API連携
- データベース連携
- CSV取込
- スプレッドシート連携
- バッチ処理
などがあります。
ダッシュボードの画面を考える前に、
「必要なデータを取得できるのか」
を確認することが重要です。
5．指標の計算ルールを明確にする
ダッシュボード開発では、意外と問題になりやすいのが指標の定義です。
例えば「今月の売上」といっても、
- 受注日ベース
- 契約日ベース
- 請求日ベース
- 入金日ベース
では数字が変わります。
「案件数」も、
- 登録された全案件
- 商談中のみ
- 受注済みを含む
- 失注を含む
など定義によって異なります。
そのため、
売上実績
対象：ステータスが受注済み
基準日：受注日
対象期間：毎月1日〜末日
など、計算ルールを具体的に決めます。
ダッシュボードの数字が正しくても、利用者が想定している定義と違えば「数字がおかしい」と判断されてしまいます。
指標定義書を作ると認識違いを防ぎやすい
ダッシュボードに複数のKPIを表示する場合は、指標定義を一覧にすると便利です。
例えば、
| 指標 | 定義 | データ元 | 更新頻度 |
|---|---|---|---|
| 月間売上 | 当月受注金額合計 | 案件 | リアルタイム |
| 受注率 | 受注件数÷商談終了件数 | 案件 | リアルタイム |
| 未対応件数 | 対応期限超過かつ未完了 | タスク | 1時間ごと |
のように整理します。
この定義を決めておくと、後から数字の意味が分からなくなることを防ぎやすくなります。
6．画面上部には重要な数字を配置する
ダッシュボードでは、画面を開いた瞬間に状況を把握できる構成が重要です。
例えば営業ダッシュボードなら、
売上実績
売上目標
達成率
受注見込み
期限超過案件
などを上部に表示します。
その下に、
- 売上推移
- 担当者別実績
- ステータス別案件数
- 最近の案件
などを配置します。
大まかな構成として、
重要KPI
↓
変化・推移
↓
内訳
↓
具体的な対象データ
という順番にすると理解しやすくなります。
7．グラフは目的に応じて選ぶ
ダッシュボードでは、グラフを増やせば見やすくなるわけではありません。
確認したい内容に応じて表現方法を選びます。
数値カード
現在値を確認したい場合
例：
- 月間売上
- 問い合わせ件数
- 在庫切れ数
折れ線グラフ
時間による変化を見る場合
例：
- 月別売上
- 日別アクセス数
- 問い合わせ件数推移
棒グラフ
項目を比較する場合
例：
- 担当者別売上
- 商品カテゴリ別販売数
- 拠点別在庫
円グラフ・ドーナツグラフ
構成比を見る場合
例：
- 案件ステータス比率
- 売上カテゴリ構成
ただし項目数が多い場合は、棒グラフなどの方が比較しやすいことがあります。
テーブル
具体的な対象を確認したい場合
例：
- 期限超過案件
- 在庫不足商品
- 未対応問い合わせ
業務ダッシュボードでは、グラフだけでなくテーブルも非常に重要です。
グラフを見た後の行動まで設計する
例えばダッシュボードに、
「期限超過案件：12件」
と表示したとします。
数字だけ確認できても、
「その12件は何なのか」
が分からなければ、別画面から検索する必要があります。
そこで、
期限超過案件：12件
↓
クリック
↓
期限超過案件一覧
↓
案件詳細
↓
担当者が対応
という導線を作ります。
ダッシュボードは情報を眺めるためだけではありません。
「異常を発見し、詳細を確認し、対応する」
ところまでつなげることが重要です。
8．比較対象を表示する
現在の数字だけでは、良い状態なのか悪い状態なのか分からない場合があります。
例えば、
今月売上：800万円
とだけ表示されても、評価できません。
そこで、
今月売上：800万円
目標：1,000万円
達成率：80％
前年同月：750万円
など、比較対象を表示します。
よく使われる比較には、
- 目標比
- 前月比
- 前年同期比
- 前週比
- 平均値
などがあります。
重要なのは、業務判断に必要な比較だけを表示することです。
9．色だけに頼らず状態を伝える
ダッシュボードでは、
達成
→ 緑
未達
→ 赤
など、色を使って状態を表すことがあります。
色は直感的ですが、色だけで情報を伝えると分かりにくい場合があります。
例えば、
達成率 105％
「目標達成」
達成率 72％
「目標未達」
のように、数値やテキストも組み合わせます。
また、画面全体で色を使いすぎると、本当に重要な警告が目立たなくなります。
色には役割を持たせることが重要です。
10．フィルターを用意する
管理者が利用するダッシュボードでは、
- 期間
- 部署
- 担当者
- 商品カテゴリ
- 拠点
- 顧客
などで絞り込みたい場合があります。
例えば、
全社売上
↓
東京支店だけ
↓
営業担当Aだけ
というように確認できます。
ただしフィルターを増やしすぎると操作が複雑になります。
最も利用頻度が高い条件を優先します。
ダッシュボードの更新頻度を決める
すべてのダッシュボードがリアルタイムである必要はありません。
例えば、
リアルタイム性が高い方がよいもの
- システム障害
- 在庫切れ
- 問い合わせ状況
- 現場稼働状況
1時間ごとでも問題ないもの
- 営業進捗
- 案件集計
- 業務処理件数
1日1回でも問題ないもの
- 経営レポート
- 月間売上集計
- KPIレポート
リアルタイム処理を増やすほど、システム負荷や開発コストが増える場合があります。
「どのくらい最新であれば業務上困らないか」
を確認して設計することが重要です。
大量データでは集計方法も考える
データが少ない段階では、画面を開くたびにデータベースから集計しても問題ない場合があります。
しかし、
顧客10万件
案件100万件
操作履歴数千万件
などになると、その場で毎回集計すると表示が遅くなる可能性があります。
そのためシステム規模によって、
- インデックス
- キャッシュ
- 集計テーブル
- バッチ集計
- データウェアハウス
などを検討します。
ダッシュボード開発では、UIだけでなくデータ処理方法も重要です。
ダッシュボードとBIツールのどちらを使う？
データを可視化するとき、
「Webシステムにダッシュボードを開発するか」
「BIツールを使うか」
で迷うことがあります。
大まかな違いは次の通りです。
| 項目 | Webシステム内ダッシュボード | BIツール |
|---|---|---|
| 業務システムとの一体感 | ◎ | ○ |
| 独自UI | ◎ | ○ |
| 開発自由度 | ◎ | ○ |
| 分析の柔軟性 | ○ | ◎ |
| 初期構築 | △ | ◎ |
| 業務処理との連携 | ◎ | △〜○ |
例えば、
売上を分析したい
複数の角度から自由に集計したい
という目的ならBIツールが向いている場合があります。
一方、
期限超過案件を確認
↓
そのまま案件詳細を開く
↓
担当者を変更
↓
対応する
という業務まで一つの画面で行いたい場合は、Webシステム内にダッシュボードを開発するメリットがあります。
Excelで作っている集計表をダッシュボード化する方法
現在Excelで毎月集計している企業も多いでしょう。
例えば、
各担当者がExcel入力
↓
管理者がファイルを集約
↓
SUMIFSやピボットで集計
↓
グラフ作成
↓
会議資料へ転記
という業務です。
これをWebシステム化すると、
担当者が業務システムへ入力
↓
データベースへ保存
↓
自動集計
↓
ダッシュボード表示
という流れにできます。
特に、
「毎週同じExcel集計をしている」
のであれば、自動化できる可能性があります。
ダッシュボード開発では権限設計も必要
会社全体の数字を全社員へ表示してよいとは限りません。
例えば、
営業担当
→ 自分の売上だけ
営業マネージャー
→ 自部署の売上
経営者
→ 全社売上
というように、利用者によって表示範囲が異なる場合があります。
また、
売上
原価
利益
人件費
などは閲覧できる担当者を限定したいこともあります。
そのためダッシュボード開発では、
「ログインできるか」
だけでなく、
「どの数字を誰が見られるか」
まで設計します。
データの詳細閲覧にも同じ権限を適用する
例えば営業担当者に、
「自分の売上のみ」
表示しているとします。
しかしダッシュボードの数字をクリックした先で、他の社員の案件まで閲覧できてしまうと意味がありません。
ダッシュボード
↓
一覧
↓
詳細
まで一貫して権限制御する必要があります。
ダッシュボードをスマートフォンで見る必要はある？
これも利用場面によります。
例えば経営者が外出先から、
- 売上
- 問い合わせ
- 重要KPI
だけ確認したい場合は、スマートフォン対応が便利です。
一方、大量データを分析する管理者向け画面ではPCの方が適しています。
スマートフォンでは、
重要KPI
↓
警告
↓
簡易一覧
に絞り、詳細分析はPCで行う設計も考えられます。
ダッシュボード開発でよくある失敗
表示できる数字を全部並べる
利用できるデータをすべて表示すると、何を見るべきか分からない画面になります。
利用目的から重要指標を絞ります。
グラフを増やしすぎる
グラフが10個、20個並んでいても、利用者が判断できなければ意味がありません。
グラフごとに、
「このグラフを見て何を判断するか」
を確認します。
KPIの定義が曖昧
営業部門と経理部門で「売上」の定義が異なると、同じダッシュボードを見ても認識が合いません。
数値の定義を明文化します。
元データの品質を確認していない
ダッシュボードは元データ以上に正確にはなりません。
例えば担当者が案件ステータスを更新していなければ、正確な受注見込みは表示できません。
ダッシュボード開発と合わせて入力ルールも整理する必要があります。
ダッシュボードから詳細へ移動できない
異常を見つけても、その原因を確認できない画面では業務につながりません。
指標から対象データへドリルダウンできる構成を検討します。
更新日時が分からない
利用者がリアルタイムデータだと思っていても、実際には前日のデータである可能性があります。
必要に応じて、
最終更新：2026/07/31 09:00
など、更新日時を表示します。
見るだけで終わる
ダッシュボードは作ったものの、会議で誰も使わなくなるケースがあります。
「見る指標」ではなく、
「異常を発見して次の行動につなげる指標」
を設計することが重要です。
【コピペ用】ダッシュボード開発ヒアリングシート
ダッシュボード開発を検討するときは、次の内容を整理してみてください。
目的
- ダッシュボードを作る目的：
- 現在確認に時間がかかっている数字：
- ダッシュボードを見て判断したいこと：
- 数字を確認した後に行う業務：
利用者
- 経営者：
- 管理者：
- 一般社員：
- 外部ユーザー：
- 利用人数：
指標
- 最重要KPI：
- 売上：
- 件数：
- 達成率：
- 進捗：
- その他：
比較
- 目標値：
- 前月比：
- 前年比：
- 部署比較：
- 担当者比較：
データ
- データ元：
- データベース：
- Excel：
- Googleスプレッドシート：
- 外部システム：
- API：
更新
- リアルタイム：
- 1時間ごと：
- 1日ごと：
- 手動更新：
絞り込み
- 期間：
- 担当者：
- 部署：
- 拠点：
- 商品：
- 顧客：
権限
- 全社データを見られる人：
- 部署データを見られる人：
- 個人データのみ見られる人：
- 機密指標：
詳細画面
- KPIから詳細一覧へ移動：
- 対象データの検索：
- データ編集：
- CSV出力：
この内容を整理することで、ダッシュボード開発会社へ相談するときも要件を伝えやすくなります。
ダッシュボード開発に関するよくある質問
ダッシュボードには何個くらいKPIを表示すればよいですか？
固定された正解はありませんが、重要なKPIを優先し、利用者が一目で状況を判断できる範囲に絞ることが重要です。
詳細指標は別画面や下位セクションへ分ける方法もあります。
Excelの集計表をダッシュボードにできますか？
可能です。
ただし、Excelの見た目をそのままWeb化するのではなく、
- どのデータを使っているか
- どの計算式で集計しているか
- 誰が更新しているか
- どの数字を実際に見ているか
を整理してから設計した方がよいでしょう。
リアルタイム表示にした方がよいですか？
必ずしも必要ではありません。
数分の遅れが業務に影響する情報なのか、1日1回の更新でも問題ない情報なのかを確認して決めます。
リアルタイム性を高めるほど、システム構成が複雑になる場合があります。
BIツールと独自ダッシュボードはどちらがよいですか？
自由な分析を中心にするならBIツール、業務システム内で詳細確認や更新まで行いたいなら独自ダッシュボードが向いている場合があります。
現在の業務と利用目的から判断します。
ダッシュボードからExcelやCSVを出力できますか？
可能です。
ただし、個人情報や売上情報などを含む場合は、誰が出力できるか権限を設計する必要があります。
データが複数システムに分かれていても作れますか？
API、データベース連携、CSVなどを使ってデータを集約できる可能性があります。
ただし、システムごとに顧客コードや商品コードが異なる場合などは、データ統合ルールの整理が必要です。
どの指標を表示すればよいか決まっていなくても相談できますか？
可能です。
むしろ最初から画面を作るのではなく、
「現在どの数字を確認して、何を判断しているのか」
を整理してからKPIを決めることが重要です。
ダッシュボードは「経営者向け」と「現場向け」で分ける
すべての利用者へ同じダッシュボードを見せる必要はありません。
例えば経営者向けでは、
- 全社売上
- 利益
- 目標達成率
- 部門別業績
など、全体状況を重視します。
一方、現場担当者向けでは、
- 今日の対応案件
- 未処理タスク
- 期限超過
- 在庫不足
など、すぐ行動につながる情報が重要です。
経営ダッシュボードと業務ダッシュボードでは目的が異なります。
利用者ごとに、
「この画面を見た後、何をしてほしいのか」
を考えることがポイントです。
ダッシュボード開発はプロトタイプから始める方法もある
指標やレイアウトがまだ決まっていない場合、最初から本格開発する必要はありません。
例えば、
業務ヒアリング
↓
KPI整理
↓
簡易ワイヤーフレーム
↓
担当者レビュー
↓
プロトタイプ
↓
実装
という流れです。
実際の画面イメージを見ると、
「このグラフはいらない」
「担当者別ではなく商品別が見たい」
「ここから案件一覧へ移動したい」
など、要望が具体的になります。
ダッシュボードは視覚的な要素が多いため、早い段階で画面を確認することが有効です。
hiro-dev-labでは指標整理からダッシュボード開発まで相談できます
ダッシュボード開発では、グラフを描く技術そのものより、
「何を表示するべきか」
を整理する工程が重要です。
例えば現在、
Excelからデータを集計
↓
担当者がグラフ作成
↓
会議資料へ転記
↓
会議で数字を確認
という業務であれば、
業務データ
↓
自動集計
↓
ダッシュボード
↓
異常値を確認
↓
詳細データへ移動
という仕組みに変更できる可能性があります。
hiro-dev-labでは、
- 業務ヒアリング
- As-Is（現在の業務）の整理
- To-Be（改善後の業務）の整理
- KPI・指標整理
- データ項目整理
- データ取得元の整理
- 画面一覧作成
- ワイヤーフレーム
- プロトタイプ作成
- 権限設計
- Webダッシュボード開発
- API連携
- Excel・CSV連携
- 業務自動化
などから相談できます。
「Excel集計に時間がかかっている」
「経営数字をすぐ確認できるようにしたい」
「管理画面にダッシュボードを追加したい」
「どのKPIを表示すればよいか整理できていない」
という段階でも、現在確認している数字と業務フローを整理するところから検討できます。
まとめ
ダッシュボード開発で重要なのは、グラフをきれいに並べることではありません。
まず、
- 誰が使うのか
- 何を判断するのか
- どのKPIを見るのか
- 数値をどう定義するのか
- データをどこから取得するのか
- どのように比較するのか
- 異常発見後にどこへ移動するのか
- 誰がどの情報を見られるのか
を整理することが重要です。
そしてダッシュボードを見る目的は、数字を眺めることではありません。
売上未達
↓
原因を確認
在庫不足
↓
発注対象を確認
期限超過
↓
担当案件を確認
というように、
「状況を把握し、次の行動を決める」
ためにあります。
ダッシュボードを単なる可視化画面ではなく、業務や意思決定を進めるための画面として設計することが、継続して使われる管理画面につながります。