kintoneダッシュボードの設計方法｜ポータル・グラフ・外部BIの使い分け

kintoneでは、アプリのグラフや表を使って、業務状況を確認できます。

売上推移を見る。

案件進捗を見る。

問い合わせ件数を見る。

在庫残数を見る。

予実差額を見る。

未対応タスクを見る。

こうしたグラフをポータルやスペースに置けば、ダッシュボードらしい画面は作れます。

ただし、実務で崩れるのは、グラフの配置そのものではありません。

次のような状態が起きます。

• 売上、案件、問い合わせ、在庫のグラフを並べたが、どれを見て判断すべきか分からない
• 経営者、部門責任者、現場担当者が同じ画面を見ており、情報量が多すぎる
• 売上グラフと請求グラフの数字が違い、会議で説明できない
• 複数アプリをまたぐ指標を作りたいが、標準グラフでは表現できない
• 社外メンバーに見せたいが、kintoneの権限やアカウント管理が合わない
• 月次会議の数字を後から再現できない
• ダッシュボードを見るだけで、次の対応やレビューに使われない
• 作った人しか指標の意味を説明できない

これは、ダッシュボードツールの選定だけでは解決しません。

見る人、KPI、正本アプリ、更新頻度、権限、レビュー会議、改善アクションを設計する必要があります。

kintoneダッシュボードで最初に決めるべきなのは、どのツールを使うかではなく、「誰が、どの数字を見て、何を判断する画面か」です。

この記事では、kintoneダッシュボードを設計するときの、ポータル・グラフウィジェット・標準グラフ・krewDashboard・kLooker・外部BIの使い分け、見る人とKPI、複数アプリ横断、公開範囲、更新頻度、週次レビュー運用を整理します。

kintoneグラフの設計方法はこちら
kintone集計全体の設計方法はこちら

先に結論：ダッシュボードは会議と判断の設計

ダッシュボードは、グラフを並べる場所ではありません。

会議や日次確認で、見る順番に沿って数字を確認し、必要なレコードへ戻り、次の対応を決める画面です。

ダッシュボード	見る人	判断
経営ダッシュボード	経営者、役員	売上、粗利、未達、重点案件、資金繰り
営業ダッシュボード	営業責任者	案件進捗、確度、受注予定、活動量
現場ダッシュボード	現場責任者	未対応、期限超過、作業負荷、異常値
サポートダッシュボード	サポート責任者	問い合わせ量、未対応、種別、対応遅延
経理ダッシュボード	経理、管理部	請求、入金、未回収、差し戻し

同じkintoneデータでも、見る人によって必要な画面は違います。

経営者には、全体の変化と例外が必要です。

部門責任者には、担当者別の偏りや遅延が必要です。

現場担当者には、今日見るべきレコードが必要です。

すべてを1画面に置くと、誰にも使いにくいダッシュボードになります。

良いダッシュボードは、全員に同じ画面を見せるものではありません。見る人と判断内容ごとに、必要な指標と粒度を分けます。

見る人とKPIを決める

ダッシュボードを作る前に、KPIを決めます。

ただし、KPIは「見たい数字」ではありません。

判断に使う数字です。

見る人	KPI例	見た後の動き
経営者	月次売上、粗利、予実差額、未回収	重点案件確認、コスト見直し
営業責任者	案件数、確度別金額、失注理由、次回アクション未設定	担当者フォロー、案件レビュー
サポート責任者	未対応件数、対応遅延、問い合わせ種別	担当変更、ナレッジ追加
現場責任者	作業遅延、担当別負荷、期限超過	優先順位変更、応援調整
経理	未請求、未入金、差し戻し、締め未完了	催促、確認、締め処理

KPIを決めるときは、次の5つをセットで決めます。

決めること	例
指標名	月次売上、未対応件数、期限超過件数
正本アプリ	案件アプリ、請求アプリ、問い合わせアプリ
集計条件	今年、今月、未完了、受注済み、失注除外
更新頻度	リアルタイム、日次、週次、月次
次の対応	レコード確認、担当変更、会議議題化、外部共有

たとえば「売上」を見るとしても、正本が案件アプリなのか、請求アプリなのか、会計ソフトなのかで意味が変わります。

案件見込みを見たいなら、案件アプリ。

請求済み売上を見たいなら、請求アプリ。

入金状況を見たいなら、入金管理や会計ソフト。

この区別をせずにダッシュボードへ並べると、同じ「売上」という言葉で別の数字を見てしまいます。

kintone売上管理の設計方法はこちら

標準グラフとポータルウィジェットで足りるケース

まずは、kintone標準機能で足りるかを確認します。

kintoneヘルプでは、グラフウィジェットは特定アプリのグラフを表示でき、売上推移や在庫残数の定点観測に使えると説明されています。

kintoneヘルプ：グラフウィジェット

グラフウィジェットでは、表示するアプリとグラフを選びます。

また、閲覧権限のあるアプリだけが検索候補として表示されます。

つまり、標準のポータルダッシュボードは、kintone内の権限とアプリ構成に沿って使うのが基本です。

標準機能で足りるのは、次のようなケースです。

ケース	標準機能で足りる理由
1アプリ内のグラフを共有したい	保存済みグラフをポータルに置ける
部門内で同じグラフを見たい	権限が揃っていれば運用しやすい
日次で未対応件数を見る	最新値を見ればよい
在庫残数や問い合わせ件数を定点観測する	アプリ内の単純集計で足りる
会議前に数個の指標を確認する	画面数を増やさず共有できる

標準機能で始める場合は、グラフ数を絞ります。

たとえば、営業ポータルなら次の3つ程度から始めます。

グラフ	目的
今月の受注予定金額	月次目標との差を確認する
確度別案件金額	重点フォロー先を決める
次回アクション未設定件数	放置案件を減らす

問い合わせポータルなら、次のようにします。

グラフ	目的
未対応件数	今日見るべき件数を確認する
対応遅延件数	優先対応を決める
問い合わせ種別	増えているカテゴリを把握する

ポータルに置くグラフは、多くても数個に絞ります。

毎日見るもの、週次会議で見るもの、月次会議で見るものを混ぜない方がよいです。

複数アプリ横断が必要なケース

ダッシュボードで難しくなるのは、複数アプリをまたぐときです。

たとえば、次のような画面です。

見たいダッシュボード	必要なアプリ
顧客別の売上・問い合わせ・契約状況	顧客、売上、問い合わせ、契約
案件別の予算・実績・請求	案件、作業実績、請求、予算
商品別の売上・在庫・発注	商品、売上明細、在庫、発注
部門別の売上・工数・粗利	案件、請求、作業実績、原価

この場合、単にグラフを増やすだけでは足りません。

アプリ間でキーを揃える必要があります。

顧客コード。

案件番号。

商品コード。

部門コード。

期間。

担当者。

これらが揃っていないと、外部BIやプラグインを使っても数字が合いません。

複数アプリ横断のダッシュボードでは、先に次を決めます。

決めること	例
正本アプリ	売上は請求アプリ、案件数は案件アプリ
結合キー	顧客コード、案件番号、商品コード
集計期間	請求月、作業月、受注予定月
除外条件	テスト、キャンセル、失注、下書き
更新頻度	日次、週次、月次、会議前
権限	誰がどの粒度まで見られるか

ここを決めずに、複数アプリをつないだダッシュボードを作ると、見た目は整っても数字の説明ができません。

複数アプリ横断のダッシュボードは、ツール選定より先に、正本アプリ、結合キー、集計期間、除外条件を決めます。

kintone予実管理の設計方法はこちら

krewDashboard・kLooker・外部BIの使い分け

標準ポータルで足りない場合、krewDashboard、kLooker、Looker Studioなどを検討します。

krewDashboardの機能ページでは、ピボットテーブル、縦棒、折れ線、複合グラフ、ゲージ、スライサー、ドリルダウン、クロスフィルター、PDFや画像への出力などが紹介されています。

krewDashboard：機能

また、krewシリーズは、krewSheet、krewData、krewDashboardを組み合わせることで、入力・加工・可視化までをつなげる構成を訴求しています。

これは、kintone内で見やすいダッシュボードを作りたい場合の選択肢です。

一方、kLookerは、kintoneデータをGoogle Looker Studioでダッシュボード化するサービスです。

kLookerのページでは、複数アプリ間集計、kintone外部への共有、定期更新、サイト埋め込み、PDF出力、メール定期配信、アクセス制限などが紹介されています。

kLooker：kintoneのダッシュボード化サービス

実務では、次のように使い分けます。

選択肢	向いているケース
標準グラフ	1アプリ内の数字を確認する
グラフウィジェット	ポータルで数個の指標を共有する
krewDashboard	kintone内で複数グラフ、フィルター、ドリルダウンを使いたい
krewData + krewDashboard	複数アプリの加工・集計をkintone側で扱いたい
kLooker / Looker Studio	社外共有、PDF、メール配信、外部BI形式の画面が必要
自社BI / DWH	kintone以外の会計、広告、販売、基幹データも統合する

重要なのは、製品名から選ばないことです。

「krewDashboardを使いたい」ではなく、「kintone内の責任者が、日次で複数グラフを操作しながら見たい」ならkrewDashboardが合います。

「社外パートナーや役員向けに、kintoneアカウントなしで定期配信したい」ならLooker Studio系が合います。

「会議前に3つの指標を見れば足りる」なら、標準ポータルで十分です。

公開範囲と権限設計

ダッシュボードは、権限設計が非常に重要です。

グラフや集計表は、レコード詳細を見せなくても、合計値として情報を見せることがあります。

売上。

原価。

粗利。

人件費。

個人情報。

評価。

契約金額。

これらを含むダッシュボードは、誰にどこまで見せるかを決めます。

情報	注意点
売上	担当者別、顧客別で見せる範囲を分ける
原価・粗利	経営、管理部、部門長など範囲を限定する
個人情報	氏名、連絡先、評価情報の表示に注意する
未回収	顧客別の信用情報として扱う
案件確度	社外共有時に見せない

kintone内で見る場合は、アプリ、レコード、フィールドの権限を確認します。

ポータルに置く場合も、対象者が同じ数字を見る前提になっているかを確認します。

外部BIで共有する場合は、kintoneの権限だけでなく、BI側の閲覧権限、URL共有、メール配信、PDF出力の範囲も確認します。

ダッシュボードは、レコードを開かなくても集計値で情報が伝わります。公開前に、原価・粗利・個人情報・顧客別売上の見せ方を確認します。

更新頻度と週次レビュー運用

ダッシュボードは、更新頻度を決めないと使われなくなります。

最新値を見る画面と、会議時点の数字を残す画面は分けます。

用途	更新頻度	保存の考え方
現場の未対応確認	リアルタイム	保存せず最新値を見る
営業週次	週次	会議前時点を確認する
月次経営会議	月次	確定値として保存する
社外共有	提出時、定期配信	出力条件と版を残す
監査・説明責任	月次、四半期	集計条件と根拠を残す

週次レビューで使うなら、ダッシュボードを見る順番を決めます。

1. 全体の異常値を見る
2. 部門別・担当者別に分解する
3. 変化が大きい指標を見る
4. 原因レコードへ戻る
5. 次の対応者と期限を決める
6. 次回会議で確認する指標を決める

これを決めずに、グラフだけ置いても、会議では「数字を見た」で終わります。

ダッシュボードは、レビューの型とセットで作ります。

週次で見るなら、週次の入力締めを決めます。

月次で見るなら、月次の確定タイミングを決めます。

社外共有するなら、共有前の確認者を決めます。

この運用がないと、いつの数字を見ているのか分からなくなります。

よくある失敗

kintoneダッシュボードでよくある失敗を整理します。

失敗	原因	対策
グラフを置きすぎる	見る人と会議が決まっていない	画面を利用者別に分ける
数字が合わない	正本アプリ、期間、除外条件が違う	指標定義を先に固定する
複数アプリ横断で詰まる	キーが揃っていない	顧客コード、案件番号などを設計する
見るだけで終わる	次の対応に戻る導線がない	レコード一覧、担当、期限を決める
権限事故が起きる	集計値の公開範囲を確認していない	権限と外部共有範囲をレビューする
月次の数字が再現できない	最新値だけを見ている	集計日時と条件を保存する
外部BI導入後も使われない	会議運用がない	週次・月次レビューに組み込む

特に多いのは、ダッシュボードを「きれいな画面」として作ることです。

見た目が整っていても、会議で使う順番がなければ定着しません。

グラフが多くても、次の対応に戻れなければ改善につながりません。

ダッシュボードは、画面ではなく運用です。

Bitlightに相談できること

Bitlightでは、kintoneダッシュボードを、単なるグラフ配置ではなく業務判断の設計として整理できます。

たとえば、次のような支援ができます。

• 経営、部門責任者、現場担当者ごとのKPI整理
• 正本アプリ、集計条件、更新頻度の定義
• 標準グラフ、ポータルウィジェット、krewDashboard、外部BIの使い分け
• 複数アプリ横断に必要なキー設計
• 権限、外部共有、PDF出力、メール配信の整理
• 週次レビュー、月次会議、社外共有の運用設計
• ダッシュボードから根拠レコードへ戻る導線設計

kintoneダッシュボードは、ポータルにグラフを置くだけならすぐに始められます。

しかし、経営と現場が同じ数字で話すには、指標の意味、正本データ、更新頻度、公開範囲を揃える必要があります。

現場確認は標準ポータル。

複数グラフの操作やドリルダウンはkrewDashboard。

社外共有や会議資料化はLooker Studio系。

このように役割を分けることで、ダッシュボードは単なる画面ではなく、判断と改善のための業務システムになります。