dashboard-specification

ダッシュボード仕様書

使用するタイミング

• 新しいダッシュボードを構築するにあたり、開発者が着手前に明確な概要を必要としている
• 既存のダッシュボードがわかりにくい、またはあまり使われておらず、体系的な再設計が必要である
• ダッシュボードに何を表示すべきかについて、ステークホルダーとデータチームの考えが異なる
• より広範なデータプロダクトのプロセスの一環として、ダッシュボードの要件を文書化する
• 複数回の質疑応答を経ずに引き継げる、セルフサービス分析の仕様書を作成する

プロセス

1. 目的を定義する — 「このダッシュボードは、[意思決定またはアクション] が必要な [対象者] のために、[質問] に答えます」という一文を書きます。一文で表現できない場合は、まずスコープを絞り込む必要があります。references/dashboard_design_principles.md を参照してください。
2. 対象ユーザーを分析する — 対象者（経営幹部、マネージャー、IC）ごとに、訪問頻度、答えを得るために訪れる主な質問、技術的な習熟度を記録します。ニーズが異なるユーザーには通常、1つのダッシュボードにフィルターを増やすよりも、別々のダッシュボードが必要です。
3. 指標の階層を定義する — 主要 KPI（最上部に表示する目立つ数値）、補助的な二次指標、詳細レベルの内訳を一覧にします。異なる指標が10～12個を超えるダッシュボードは、詰め込みすぎです。
4. 情報アーキテクチャを設計する — 目立つ数値 → トレンド → 内訳 → 詳細のパターンを使ってレイアウトをスケッチします。最も重要な情報は左上に配置します。レイアウトのパターンについては、references/dashboard_requirements_guide.md を使用してください。
5. インタラクティブ性を指定する — グローバルフィルター（日付範囲、地域、セグメント）、ドリルダウンの経路、クリック時のアクション、ホバー時のツールチップの内容を一覧にします。フィルターやドリルダウンを追加するたびに複雑さが増すため、それぞれの必要性を説明してください。
6. データ要件と成功基準を文書化する — 各指標について、ソーステーブル、変換ロジック、更新頻度を記録します。ダッシュボードの成功をどのように測定するか（利用率、アドホックなリクエストの削減）を定義します。assets/dashboard_spec_template.md を完成させてください。

このスキルに必要な入力

• ダッシュボードが答えることを目的とするビジネス上の質問
• 指標候補の一覧（チームから大まかな一覧を受け取り、精査できます）
• 主な対象者（役割、訪問頻度、行う意思決定）
• データの利用可否：確認済みのソーステーブルと更新スケジュール
• 制約：ツール（Tableau、Looker、Metabase など）、ブランドガイドライン

出力

• references/dashboard_design_principles.md — レイアウト階層、グラフの選択、情報密度に関するガイドライン
• references/dashboard_requirements_guide.md — 要件のヒアリング方法、スコープクリープの回避方法、仕様書の検証方法
• assets/dashboard_spec_template.md — 完全な仕様書：目的、ユーザー、指標の階層、レイアウトのワイヤーフレーム、インタラクティブ性、データソース、成功基準