dashboard-designer

ダッシュボードデザイナー

概要

このスキルでは、適切な KPI と対象者の定義から、情報アーキテクチャ、視覚的な階層、色分け、ツールの選定まで、ダッシュボードを設計するための体系的なアプローチを提供します。優れたダッシュボードは、適切な情報を適切な人に適切なタイミングで示します。このスキルでは、データビジュアライゼーションの原則と UX の考え方を組み合わせ、単にデータを表示するだけでなく、意思決定を促すダッシュボードを作成します。

使用する場面

• 新しいダッシュボードを作成しており、何を表示し、どう配置するかを決める必要がある
• 既存のダッシュボードが雑然としている、見られていない、またはユーザーにとって分かりにくい
• BI ツール（Tableau、Power BI、Looker、Grafana）の中から選ぶ必要がある
• 技術的な実装に着手する前に KPI フレームワークを設計したい
• 経営幹部を対象にデータを提示するため、ストーリーの構成が必要である

使用しない場面

• ダッシュボード用の SQL クエリを書く（sql-analyst skill を使用）
• Python/JavaScript でチャートのコードを作成する（chart-builder skill を使用）
• 静的なレポートやスライド資料を作成する（プレゼンテーションスキルを使用）
• 基盤となるデータモデルやデータウェアハウスを設計する（データエンジニアリングスキルを使用）

クイックリファレンス

設計原則	ルール
視覚的な階層	最重要 KPI は左上に、詳細は右下に配置します
余白	ダッシュボード領域の 15～20% を確保し、認知的な過負荷を防ぎます
色分け	色は最大 4～5 色とし、状態には赤／緑、補足情報にはグレーを使用します
チャートの密度	画面あたり最大 6～8 個とし、数を減らして大きく表示することを優先します
KPI 数	経営幹部向け：3～5 個。業務運用向け：8～12 個。アナリスト向け：上限なし
テキスト	タイトルはラベル（「売上」）ではなく、インサイト（「売上が 12% 増加」）として記述します
更新頻度	業務運用向けはリアルタイム、管理向けは毎日、戦略向けは毎週／毎月
インタラクティブ性	フィルターは上部に配置し、クリックでドリルダウンできるようにし、最も一般的な表示をデフォルトにします
モバイル	モバイルではチャートを縦に並べ、上位 3 個の KPI に絞ります
アクセシビリティ	色覚多様性に配慮した配色を使用し、コントラスト比は 4.5:1 以上にします

手順

ステップ 1：対象者と目的を定義する

設計を始める前に、次の質問に答えてください。

1. このダッシュボードを使うのは誰ですか？ 経営幹部、チームマネージャー、アナリスト、エンジニア、顧客など。
2. どのような意思決定に役立ちますか？ （「西部地域へのマーケティング費用を増やすべきか？」）
3. どのくらいの頻度で確認しますか？ リアルタイム（業務運用向け）、毎日、毎週、毎月など。
4. どのようなアクションを取れますか？ アクションがない場合は、ダッシュボードが適切な形式かどうかを見直してください。

ダッシュボードの類型：

種類	対象者	更新頻度	KPI 数	例
戦略	経営幹部、VP	毎週／毎月	3～5	全社の健全性スコアカード
業務運用	チームリーダー、マネージャー	毎日	8～15	営業パイプラインダッシュボード
分析	データアナリスト	オンデマンド	上限なし	コホート分析エクスプローラー
リアルタイム監視	エンジニア、サポート担当者	ライブ	10～20	システム稼働率とエラー率

ステップ 2：適切な KPI を選ぶ

KPI は次の条件を満たす必要があります。

• 実行可能である：閲覧者が表示内容に基づいて改善できる
• タイムリーである：ダッシュボードの更新頻度に合わせて利用できる
• 比較可能である：比較対象となる目標、ベンチマーク、または前の期間がある
• 明確である：すべての関係者が共有する、明確な定義が 1 つある

KPI の選定手順：

1. 対象者が重視する指標を 20 個リストアップします
2. 対象者がアクションを取れる指標に絞ります（見栄えだけの指標は除外します）
3. 残った指標を 3～5 個のテーマに分類します（例：売上、顧客、業務、品質）
4. 各テーマから主要指標を 1～3 個選びます
5. 各指標の計算方法、データソース、担当者を定義します

KPI の階層：

• レベル 1（ヘッドライン）：上部に大きく表示する KPI を 3～5 個（総売上、MAU、NPS）
• レベル 2（補足）：背景情報を示すチャートを 6～10 個（地域別、製品別、トレンド）
• レベル 3（詳細）：調査用のテーブルまたはドリルダウン

ステップ 3：情報アーキテクチャ（レイアウトパターン）

Fパターンのレイアウト（最も一般的）：ユーザーは左上から右上へ、続いて左側を下へと視線を動かします。

┌─────────────────────────────────────────────────────┐
│  KPI 1        KPI 2        KPI 3        KPI 4       │  ← Headline KPIs
├───────────────────────┬─────────────────────────────┤
│                       │                             │
│  Primary chart        │  Secondary chart            │  ← Primary context
│  (e.g. revenue trend) │  (e.g. by region)           │
│                       │                             │
├───────────────────────┴─────────────────────────────┤
│  Detail chart 1    │  Detail chart 2  │  Table      │  ← Supporting detail
└────────────────────┴──────────────────┴─────────────┘

Zパターンのレイアウト（経営層向けダッシュボード）：要素を絞り、全体像を伝える流れを重視します。

グリッドレイアウト（業務ダッシュボード）：同じサイズのタイルを行ごとに配置します。

ステップ 4：視覚的階層の原則

1. サイズ：大きいほど重要です。最も重要な KPI カードを最大の要素にします。
2. 位置：左上隅が最も注目されます。主要指標をそこに配置します。
3. 色：主要データには（青やオレンジなどの）鮮やかな色を使用し、補足情報にはグレーを使用します。
4. タイポグラフィ：指標の値は大きく（24～32pt）、ラベルは小さく（10～12pt）、タイトルは中くらい（14～16pt）にします。
5. 余白：空白は無駄ではありません。視線を導き、疲労を軽減します。

ステップ 5：カラーコーディングの体系

一貫した色の使い方を定めます：

• 🟢 緑：良好、順調、目標を上回る
• 🔴 赤：不良、警告、目標を下回る
• 🟡 黄／オレンジ：注意、しきい値に接近
• 🔵 青：主要データ、中立的な情報
• ⬜ グレー：二次データ、前期間、補足情報

色覚多様性に配慮した代替パレット：

• 使用する色：#0077BB（青）、#EE7733（オレンジ）、#009988（ティール）、#CC3311（赤）
• 避ける色の組み合わせ：模様やラベルで区別せずに、純粋な赤と純粋な緑を併用する

ステップ 6：BI ツール選定ガイド

ツール	最適な用途	強み	制限事項
Tableau	エンタープライズ BI、複雑な可視化	強力な可視化機能、活発なコミュニティ、ドラッグ＆ドロップ	高価、学習曲線が急
Power BI	Microsoft 中心の組織、セルフサービス BI	Excel／Azure との深い統合、手頃な価格	レイアウトの柔軟性が低い、DAX が複雑
Looker	データチーム主導、エンジニアリング中心の組織	LookML モデリング、統制された指標、Git 統合	データエンジニアが必要、高価
Grafana	リアルタイム監視、エンジニアリング指標	ライブデータ、アラート、オープンソース	ビジネスユーザー向けではない、チャートの種類が限られる
Metabase	小規模チーム、SQL ファーストの分析	オープンソース、SQL からダッシュボードを簡単に作成	高度な機能が限られる
Google Data Studio (Looker Studio)	Google Workspace ユーザー、迅速な共有	無料、簡単に共有可能、Google Sheets と統合	データ変換機能が限られる、基本的なビジュアル
Retool	アクションを伴う業務ダッシュボード	CRUD 操作、社内ツール	セットアップに開発者が必要

クイック選定ガイド：

• 小規模チームのスタートアップ → Metabase または Looker Studio
• 既存の Microsoft スタックを利用するエンタープライズ → Power BI
• 統制された指標レイヤーを構築するデータチーム → Looker
• エンジニアリングの監視 → Grafana
• 最高水準の可視化と大規模な予算 → Tableau

ステップ 7：ダッシュボード品質チェックリスト

公開前に、以下を確認します：

• すべてのチャートに、指標名だけでなくインサイトを示すタイトルがある
• すべての KPI に比較値がある（目標との比較、前期間との比較）
• カラーコーディングが全体で一貫している
• 日付範囲が明確に表示され、ユーザーが変更できる
• フィルターが上部にあり、最も一般的な表示がデフォルトになっている
• すべての数値が適切な精度でフォーマットされている（収益：$1,234,567.89 ではなく $1.2M）
• データソースと更新日がフッターに表示されている
• （該当する場合）モバイルレイアウトをテスト済み

例

例 1：営業実績ダッシュボードを設計する

入力：「営業担当副社長が毎週確認するダッシュボードが必要です。売上、パイプラインの健全性、チームのパフォーマンスを重視しています。」

**対象者の分析：**営業担当副社長 — 経営幹部レベル — 毎週のレビュー — チームの人員配置や注力分野に関する戦略的な意思決定。

KPI の選定（レベル 1 — 主要指標）：

1. 受注額（ARR） — 今週の新規受注売上と目標の比較
2. パイプラインカバレッジ — パイプラインの金額 / ノルマ（目標：3 倍のカバレッジ）
3. 成約率 — 受注に至った案件の割合（目標：25%）
4. リスクのある案件 — 想定クロージング日を過ぎた進行中の案件

レイアウト設計：

┌────────────────────────────────────────────────────────────────┐
│ FILTER: [Week ▼]  [Region ▼]  [Rep ▼]          Data as of Mon │
├──────────────┬──────────────┬──────────────┬──────────────────┤
│ Bookings     │ Pipeline     │ Win Rate     │ Deals at Risk    │
│ $1.2M        │ 3.4× quota   │ 28%          │ 12 deals         │
│ ▲ 15% vs LW  │ ✅ on track  │ ▲ 3pt vs LW  │ 🔴 $340K at risk │
├──────────────┴──────────────┴──────────────┴──────────────────┤
│ Bookings Trend (12 weeks) ← primary chart, 60% width          │
│                                                                │
├─────────────────────────────┬──────────────────────────────────┤
│ Revenue by Rep (bar chart)  │ Pipeline Stage Funnel            │
├─────────────────────────────┴──────────────────────────────────┤
│ Deal Table: Name | Stage | Value | Expected Close | Days Late  │
└────────────────────────────────────────────────────────────────┘

色の使い分け：

• 緑：指標が目標を上回っている
• 赤：指標が目標を下回っている、または「リスクのある」項目
• 青：傾向線（主要データ）
• グレー：前期間との比較線

**ツールの推奨：**Salesforce CRM を使用している場合は Salesforce Einstein Analytics、または Salesforce コネクターを備えた Tableau をおすすめします。小規模なチームには、HubSpot の組み込みレポート機能、または CRM データベースに接続した Metabase が適しています。

---

例 2：エンジニアリング指標ダッシュボードを設計する

入力：「エンジニアリングチームは、システムの健全性、デプロイ頻度、インシデント対応を追跡するダッシュボードを求めています。」

**対象者：**エンジニアリングチームのリーダー、オンコールエンジニア — 日次およびリアルタイムでの利用。

KPI の選定（DORA メトリクスのフレームワーク）：

1. デプロイ頻度 — 1 週間あたりのデプロイ回数（目標：毎日）
2. 変更のリードタイム — PR のマージから本番環境への反映まで（目標：1 日未満）
3. 変更失敗率 — インシデントにつながったデプロイの割合（目標：5% 未満）
4. MTTR（平均復旧時間） — インシデントの平均継続時間（目標：1 時間未満）

補足チャート：

• サービスごとのエラー率（過去 24 時間の折れ線グラフ）
• エンドポイントごとの P95 API レイテンシ（ヒートマップ）
• 重大度と SLA ステータスを含む未解決インシデントの表
• 最近のデプロイ履歴

**ツールの推奨：**Grafana（Prometheus、DataDog、CloudWatch に直接接続でき、ネイティブのアラート機能とリアルタイム更新に対応）。

**色分け：**赤 = SLA 違反、黄 = パフォーマンス低下、緑 = 正常、グレー = データなし。

ベストプラクティス

• データではなく問いに基づいて設計します。「どのようなデータがあるか」ではなく、「このダッシュボードによってどのような意思決定ができるか」から始めます
• ダッシュボード 1 つにつき対象者は 1 種類にします。同じビューで経営幹部とアナリストの両方に対応しようとしないでください
• KPI には目標が必要です。基準のない数値には意味がありません
• 「アラート」色（赤）を多用すると効果が薄れるため、本当の問題にのみ使用します
• その時点の数値だけでなく傾向も表示します。履歴のない現在値には文脈がありません
• 可能であれば凡例を参照させるのではなく、チャート上にデータを直接表示します
• モバイル版は後回しにせず、デスクトップ版の後に作成します

よくある間違い

• KPI が多すぎる：20 個以上の指標は、洞察ではなく分析麻痺を招きます
• 見栄えだけの指標：ページビュー、SNS のフォロワー数、登録ユーザー総数（アクションにつながらない）
• 比較する文脈がない：目標や前期間との比較なしに売上が 120 万ドルとだけ表示されている
• 日付フィルターに一貫性がない：あるチャートは「過去 30 日間」、別のチャートは「今月」を表示している
• 5 区分を超える円グラフの使用 — 順位付きの棒グラフに切り替えます
• ユーザーが落ち着いて確認したいダッシュボードを自動更新する — 認知負荷が増加します
• モバイル対応を忘れる：ダッシュボードの閲覧の 40% 以上はタブレットまたはスマートフォンで行われます

ヒントとコツ

• 「5 秒テスト」を実施します。誰かにダッシュボードを 5 秒間だけ見せてから、「最も重要なことは何ですか？」と尋ねます。答えられなければ、情報の優先順位が明確ではありません
• すべての補助データにはグレーを標準色として使い、重要な情報の強調にだけ色を使います
• データが古くないかユーザーが確認できるよう、必ず「最終更新」タイムスタンプを含めます
• ダッシュボードのタイトルは、ダッシュボードが扱う問いに答えるものにします。「Sales Dashboard」ではなく、「営業実績 — 1 月 15 日の週」とします
• 経営幹部向けのダッシュボードでは、作成に着手する前に、文章による「ダッシュボードの説明資料」を用意します。経営幹部が求めているのは、探索用のツールではなく、概要説明であることがよくあります

Related Skills

• chart-builder
• sql-analyst
• data-analyst
• business-analyst