ダッシュボードの作り方:データソース、KPI、グラフ、アクセス権限
ダッシュボードを作るには、何に答えるべきか、誰が読むのかという質問から始めてください。そのうえで、定義を正確に決めた少数の指標を用意し、それらの元になるデータを接続し、それぞれに分かりやすいグラフを選びます。最後に、誰がどの数字を見られるかを決めます。AIアプリビルダーは、洗練されたダッシュボードを数分で生成できます。しかし、誰かが信頼するかどうかを決めるのは、データと定義を正しく作ることであり、そこが最も難しい部分です。
グラフより先に質問を決める
何でも表示しようとするダッシュボードは、一度開かれて終わります。グラフを考える前に、次を答えてください。
- 誰のためのものか? 創業者、営業チーム、オペレーション、投資家、顧客のどれか。
- どんな判断を支えるのか? 「サポート担当をあと一人増やす必要があるか」は、ダッシュボードで答えられる質問です。「データを見せて」は違います。
- どれくらいの頻度で見られるか? 毎日の運用ダッシュボードには新しいデータとアラートが必要ですが、月次の役員向けの画面はそうではありません。
三〜五個の質問を書き出してください。それぞれが一つか二つの指標になります。
各指標を正確に定義する
ダッシュボードをめぐる議論の多くは、実は定義をめぐる議論です。すべての数字について、短い定義を書いてください。
| 指標 | あいまいな定義 | 正確な定義 |
|---|---|---|
| 売上 | 「我々が稼いだお金」 | 支払い済み請求書の合計額(税抜き)を請求日で集計し、単位はUSD |
| アクティブユーザー | 「使っている人」 | 過去30日間に一度でもログインした、重複のないユーザー数 |
| 解約率 | 「辞めた人」 | 月初に有料契約していた顧客のうち、その月中に解約した人数を、月初の顧客数で割ったもの |
| 応答時間 | 「サポートの速さ」 | チケット作成から最初の人による返信までの中央値(営業日のみ) |
これらの定義をプロンプトに貼り付けてください。そうしないと、AIは、もっともらしく聞こえるけれど自社の数え方とは合わない計算を選んでしまいます。
データはどこから来るか
| ソース | ダッシュボードの読み方 | 注意点 |
|---|---|---|
| 自社アプリのデータベース | 直接クエリ | 重いクエリがメインのアプリを遅くするため、必要に応じて集計用のテーブルを用意する |
| スプレッドシート | CSVとして取り込む、またはAPI経由で読む | 手作業の編集で形式が崩れる。合計行や結合されたセルに注意 |
| SaaSツール(Stripe、HubSpot、Shopify、Google Analytics) | APIキーを使ってそのAPIを呼ぶ | レート制限、ページネーション、各ツールが独自に指標を定義していること |
| データウェアハウス(BigQuery、Snowflake、Postgres) | サーバー側の接続を通じてSQLを実行 | 認証情報とクエリの費用 |
どこでも当てはまる原則が二つあります。
- キーはサーバー側に置く。 APIキーやデータベースのパスワードは、アプリの環境変数に保存し、ブラウザのコードに入れてはいけません。
- 鮮度を決める。 ページを開くたびに複数のAPIを呼ぶと、遅く、レート制限にも当たりやすくなります。多くのビジネス向けダッシュボードでは、一時間ごとまたは夜間に自社データベースへ同期し、ページに「最終更新」の時刻を表示するほうが、シンプルで信頼性も高くなります。
APIに不慣れなら、APIとはとデータベースとはで基礎を確認してください。
適切なグラフを選ぶ
- 変化率付きの単一の数字(「42万ドル、先月比で8%増」)— KPIカード。多くのダッシュボードで最も役立つ要素です。
- 時間の推移 — 折れ線グラフ。棒グラフは期間が少ない場合にだけ使います。
- カテゴリの比較 — 値で並べた横棒グラフ。
- 全体に対する内訳 — 積み上げ棒グラフ。円グラフは、スライスが二つか三つのときだけ有効です。
- 詳細と例外 — 並べ替え、検索、フィルター付きの表。グラフよりも役立つことがよくあります。
色はいつも同じ意味で使ってください。「今期」は一つの色、「比較対象」は控えめな色、要注意の項目だけに赤を使います。
誰が何を見られるか
構築の前に、アクセス権を決めてください。
- 社内向けで全員が全部を見られる — 最もシンプルです。ただし事業データを扱うなら、ログインは必要です。
- 役割ベース — 営業は営業の数字を、財務は利益率を、マネージャーは自分のチームの数字を見られる。
- 顧客向け — 各顧客は自分のデータだけを見られる。すべてのクエリは、サーバー側で顧客のアカウントによって絞り込まれていなければなりません。二人の異なる顧客としてログインして確認してください。
売上や顧客データが、ログインなしで公開URLに置かれていると、いずれ見つかる情報漏えいになります。
うまくいく最初のプロンプト
従業員10人のBtoBソフトウェア会社向けの営業ダッシュボードを作ってください。想定する閲覧者は、創業者と営業責任者で、毎週月曜日に確認します。概要ページには、今月の新規MRR、総MRR、今月の新規顧客数、今月の解約顧客数、パイプラインの金額を表示するKPIカードを置き、それぞれに先月との比較を付けてください。過去12か月のMRRの折れ線グラフと、流入元ごとの新規案件の棒グラフも入れます。案件ページには、検索と並べ替えができる表(会社、担当者、金額、ステージ、受注予定日)を用意し、担当者とステージで絞り込めるようにしてください。指標の定義は次のとおりです。MRRは、有効な月額サブスクリプションの金額の合計で、年額プランは12で割ります。解約は、今月サブスクリプションが終了した顧客を数えます。当面は、データベースに現実的なサンプルデータを入れてください。後でStripeに接続します。「最終更新」の時刻を表示してください。ログインを必須にし、サイドバーのすっきりしたレイアウトにしてください。
構築の手順
- サンプルデータでレイアウトを作る。 データが架空で、変更が簡単なうちに、指標とグラフについて合意します。
- 実際のデータソースを一つ接続する。 数字を一つずつ、元のシステムと手作業で照合してください。MRRがStripeの表示と違えば、先に進む前に理由を突き止めてください。
- 他のデータソースを一つずつ追加する。 それぞれ照合しながら進めます。
- 定期的な更新、またはページ読み込み時のクエリ。 「最終更新」の表示付き。
- フィルター。 まず期間、次に人が頼みがちな一つか二つ。
- ログインと役割。
- 空の状態とエラーの状態。 データソースが停止しているとき、またはフィルターの結果がないときに、ページに何を表示するか。
- 閲覧者と共有し、 一か月見られなかったものは削除する。
高速にする
遅いダッシュボードは、確認されにくくなります。計算に時間がかかる合計は事前に集計しておき(すべての注文をスキャンするのではなく、日次の集計テーブルを使う)、大きな表はページ分割し、主要なカードを先に読み込んで、グラフが描画される前にもページが役立つようにしてください。計算に時間がかかる数字は、訪問するたびに再計算するのではなく、最後に計算された時刻を表示してください。
よくある失敗
- グラフが多すぎる。 全部が強調されていると、何も強調されていないのと同じです。
- 指標が定義されていない。 同じダッシュボードを見た二人が、同じ結論に至るべきです。
- 元のデータと照合しない。 一つでも間違った数字があると、人はダッシュボード全体を信頼しなくなります。
- ページを開くたびに、すべてのAPIを呼ぶ。 遅く、壊れやすく、ときには費用もかさみます。
- 日付の文脈がない。 必ず期間と比較対象を表示してください。
- フロントエンドに秘密情報を置く。 ブラウザで見えるAPIキーは、ページを開いた誰にでもコピーされてしまいます。
BIツールが適している場合
データがすでにデータベースやウェアハウスにあり、主な利用者がデータを探索し、スライスし、自分でグラフを作りたいアナリストである場合は、Looker Studio、Power BI、Metabaseなどの BI ツールのほうが、独自開発よりも役立ちます。多くのSaaSツールには、良い標準レポートが組み込まれています。作り直す前に、それらを確認してください。独自のダッシュボードが勝つのは、顧客向けや非アナリスト向けである場合、BIツールでは表現できないロジックや権限が必要な場合、自社特有の方法で複数のソースを組み合わせる場合、または既に運用している製品の一部として組み込む場合です。
仕事が数字を見ることよりも、レコードを変更することである場合は、管理画面や社内ツールのほうが適しています。社内ツールの作り方を参照してください。数字が今スプレッドシートにある場合は、スプレッドシートをアプリにする方法が次に読むとよいガイドです。
Mythexで作る
Mythexでは、ダッシュボードを説明すると、エージェントがライブプレビューでページとグラフを作ります。最初は現実的なサンプルデータを使い、数字を保存する必要が出たら、専用のPostgresデータベースに移行します。ドキュメントのダッシュボードのユースケースに、開始用のプロンプトがあります。データがGoogle スプレッドシートのようなツールにある場合は、コネクターからそのアカウントを接続し、エージェントにそのデータを読んでダッシュボードを作るよう頼めます。
アプリ自体に組み込みのウェアハウス用コネクターはありません。BigQuery、Snowflake、Stripeなどについては、アプリが各APIを呼び出し、キーはプロジェクトのシークレットとして保存します。ダッシュボードを見る人のログインと役割は、作るアプリの一部です。プロンプトから始めたい場合は、ダッシュボードのテンプレートを見てください。たとえばメトリクスダッシュボードがあります。
よくある質問
ダッシュボードはどのように作りますか?
まず、誰が見るためのものか、どんな質問に答える必要があるかを決めます。次に、定義が明確な指標を数個選び、データソースを接続してから、指標ごとにグラフを選びます。これらが決まっていれば、AIアプリビルダーが説明からページとグラフを生成できます。
KPIはいくつくらい入れるべきですか?
一目で把握できる数に抑えてください。メインの画面では五〜七個程度が目安です。詳細は別のページにまとめ、主要な数字がおかしいと感じたときに開いてもらうようにします。
独自のダッシュボードを作るべきか、BIツールを使うべきか?
データがすでに対応したデータベースやデータウェアハウスにあり、アナリストが自由に探索するなら、Looker Studio、Power BI、MetabaseのようなBIツールを使ってください。顧客向けや非アナリスト向けで、独自のロジックや権限が必要な場合、または既に持っているアプリの中に組み込む場合は、独自のダッシュボードを作ってください。
ダッシュボードはリアルタイムのデータを表示できますか?
はい。ページの読み込み時や、一定の間隔で更新する仕組みで、データベースやAPIから読み込めば可能です。多くのビジネス向けダッシュボードでは、一時間ごとや毎日の更新で十分であり、そのほうが単純でコストも低く抑えられます。