kpi-dashboard-design

KPI ダッシュボード設計

ビジネス上の意思決定を促進する、効果的な重要業績評価指標（KPI）ダッシュボードを設計するための包括的なパターンです。

このスキルを使用する場面

• 経営層向けダッシュボードを設計するとき
• 意味のある KPI を選定するとき
• リアルタイム監視ディスプレイを構築するとき
• 部門別のメトリクスビューを作成するとき
• 既存のダッシュボードレイアウトを改善するとき
• メトリクスのガバナンスを確立するとき

中核となる概念

1. KPI フレームワーク

レベル	焦点	更新頻度	対象者
戦略	長期目標	月次/四半期	経営層
戦術	部門目標	週次/月次	マネージャー
運用	日々の業務	リアルタイム/日次	チーム

2. SMART KPI

Specific: Clear definition
Measurable: Quantifiable
Achievable: Realistic targets
Relevant: Aligned to goals
Time-bound: Defined period

3. ダッシュボードの階層

├── Executive Summary (1 page)
│   ├── 4-6 headline KPIs
│   ├── Trend indicators
│   └── Key alerts
├── Department Views
│   ├── Sales Dashboard
│   ├── Marketing Dashboard
│   ├── Operations Dashboard
│   └── Finance Dashboard
└── Detailed Drilldowns
    ├── Individual metrics
    └── Root cause analysis

詳細な実例とパターン

詳細なセクション（## 部門別の一般的な KPI で始まるもの）は references/details.md にあります。上記のナビゲーション概要では不十分な場合は、そのファイルをお読みください。

ベストプラクティス

すべきこと

• 5〜7 個の KPI に絞る - 重要なものに集中する
• コンテキストを示す - 比較、トレンド、目標
• 一貫した色を使う - 赤=悪い、緑=良い
• ドリルダウンを可能にする - サマリーから詳細へ
• 適切に更新する - メトリクスの頻度に合わせる

すべきでないこと

• 虚栄のメトリクスを表示しない - 実行可能なデータに集中する
• 詰め込みすぎない - 余白は理解を助ける
• 3D グラフを使わない - 知覚を歪める
• 方法論を隠さない - 計算方法を文書化する
• モバイルを無視しない - レスポンシブデザインを確保する

トラブルシューティング

ダッシュボードに表示される MRR が財務部門の数値と一致しない

最も一般的な原因は、年払いプランの扱いが一貫していないことです。財務部門は日割りレートに按分している一方、ダッシュボードは月額に正規化している可能性があります。単一の計算式に合意し、ダッシュボードのカードに直接記載してください：

-- Explicit formula shown in tooltip / data dictionary
-- Annual plans: divide total contract value by 12
-- Quarterly plans: divide by 3
-- Monthly plans: use as-is
CASE subscription_interval
    WHEN 'monthly'   THEN amount
    WHEN 'quarterly' THEN amount / 3.0
    WHEN 'yearly'    THEN amount / 12.0
END AS normalized_mrr

ダッシュボードは緑を示しているが、プロダクトチームはユーザーからの苦情を報告している

ダッシュボードはおそらくシステム稼働率（遅行指標）を追跡しているものの、ユーザー体験に関する品質メトリクスを追跡していません。インフラのメトリクスと並べて、顧客が認識するメトリクスを追加してください：

インフラ（緑）	ユーザーが認識するもの（これらを追加）
API 稼働率 99.9%	P95 ページ読み込み時間
エラー率 0.1%	タスク完了率
キューの深さは正常	サポートチケット数

リテンションコホートが横ばいに見える — コホート間にばらつきがない

コホートクエリが登録月で正しくパーティション分割されているか確認してください。よくあるバグは、DATE_TRUNC('month', created_at) の代わりに created_at::date を使用することで、日単位でグループ化され、トレンドを示すには小さすぎるコホートが生成されます：

-- Wrong: too granular, cohorts are too small
DATE_TRUNC('day', created_at) AS cohort_date

-- Correct: monthly cohorts
DATE_TRUNC('month', created_at) AS cohort_month

リアルタイムダッシュボードがデータベースに負荷をかける

複雑なコホート SQL を使って 10 秒ごとに更新されるライブダッシュボードは、本番クエリのパフォーマンスを低下させます。スケジュールされたジョブで事前集計したメトリクスをサマリーテーブルに書き込み、ダッシュボードはそこから読み取ることで、OLAP ワークロードを OLTP から分離してください：

# Scheduled every 5 minutes via cron/Celery
def refresh_mrr_summary():
    conn.execute("""
        INSERT INTO kpi_snapshot (metric, value, snapshot_at)
        SELECT 'mrr', SUM(...), NOW()
        FROM subscriptions WHERE status = 'active'
        ON CONFLICT (metric) DO UPDATE SET value = EXCLUDED.value
    """)

アラートしきい値が頻繁に発火し、チームが無視している

一度設定して見直されない静的なしきい値は、アラート疲れを引き起こします。移動平均に基づく動的なしきい値を使用することで、メトリクスが自身のベースラインから大きく逸脱したときにのみアラートが発火します：

# Alert if current value is > 2 standard deviations from 30-day rolling mean
def is_anomalous(current: float, history: list[float]) -> bool:
    mean = statistics.mean(history)
    stdev = statistics.stdev(history)
    return abs(current - mean) > 2 * stdev

関連スキル

• data-storytelling - ダッシュボードの発見を、経営層の意思決定を促進するストーリーに変える