【読了】ビジネスダッシュボード設計実装ガイドブック
CDP（顧客データ基盤）サービスプロバイダ業者の本
はじめに
解説しないこと
・特定のBIツールの使い方
・組織論
第1章 ダッシュボードの種類と課題
ダッシュボードに必要な要素と種類
BIツールを使えば様々な可視化を画面内に表示できるが、それだけでは「ビジネス向けダッシュボード」とは言えない
ビジネスダッシュボードの3要件
①利用目的に直結すること：直結しない情報は表示させるだけ無駄
②行動や意思決定に繋がること：それを見て何もアクションを起こせないなら無駄
③リアルタイムかつ継続的であること
ビジネスにおけるダッシュボードの用途
・モニタリング：問題があるかどうかを瞬時に判断できることが重要（原因の深掘りは不要）
・戦略や方針の立案：事象の詳細を深掘りして原因特定までできることが重要
・効果測定：実施した施策と効果を紐づけられることが重要
ダッシュボードが普及してきた背景
略
ダッシュボードが使われなくなる原因
◯要求や設計の問題
・データから分かることをただ表示しているだけ
・既存／新規の業務プロセス上で、どう使うかを吟味していない
・どの業務で使う？
・いつのタイミングで使う？
・誰が使う？
・何を意思決定する？
◯実装の問題
・ダッシュボードの動作が重い（レスポンスタイムが長い）
◯運用の問題
・データの更新が停止している
・使い方が分からない
・改善要望が出せない
第2章 ダッシュボード構築プロジェクトの全体像
プロジェクトの全体像と概要
①フェイズ
・要求定義・要件定義：どんなに単純なダッシュボードでも、用途とデータソースの定義が不可欠
・ダッシュボード設計：実現可能性を調査
・データ準備：テーブル定義、データパイプラインの定義
・ダッシュボード構築：
・運用・レビュー・サポート：
②必要スキル
・ハードスキル
・BIツール操作
・前処理：BIツールで使える形式にデータを整える（SQLなどを使う）
・分析ツールの導入保守：BIツールや分析ツールなど
・データパイプラインの構築保守：（ETLツールなどを使う）
・データベースの構築保守：データレイク、DWH、データマートなど
・コスト管理
・ソフトスキル
・プロジェクト管理
・要求定義
・事業の理解
・業務プロセスの理解
・AsIsとToBeの理解
・要件定義
・ユースケースの整理：業務プロセス上でどう使うか
・必要データの整理：データソース、前処理
・ダッシュボード構成要素の整理：表示する指標、グラフの軸、など
・データ分析：「目的の形式にデータを加工すること」ではなく「意思決定に使える情報を提供すること」である
・ダッシュボードデザイン：使いやすい相互作用やUI（配色など）
・データマート設計
③体制
・プロジェクトオーナー（ダッシュボード活用責任者）：ユーザ
・プロジェクトマネージャ：プロジェクト管理に注力
・データアナリスト：効果的な分析（要求や要件の質を高める）ことに注力
・エンジニア：ダッシュボード製品の構築運用に注力
④進め方
・ウォーターフォール型：変更を受け入れたり、当初の想定と異なる事象（技術的な困難、期待ギャップ発生など）が起こった場合、当初のQCDは守れない
・略
・アジャイル型：短期間に区切って進める、変更を受け入れられる反面、長期的な完成日や成果物が想定しにくい
・早期にアクションに繋げたい
・何ができるか詳しく分からず進め方も分からない
一般的に、2つの型を組み合わせて進めていく
後戻りできない部分がある（例：ダッシュボードを構築し始めてからテーブル定義が変更されると、影響範囲が大きい）ため、マイルストーンを示しながら進めていく
各フェイズに必要な成果物（第3章以降で解説）
・プロジェクト管理上、マイルストーンとして使える（作業の見通しがつく）
・期待ギャップを把握できる
プロジェクト管理用ドキュメント
・ロードマップ：全体像の俯瞰
・スケジュール進捗管理表：アクティビティの依存関係、スケジュールの予実
・課題管理表：プロジェクト推進上の懸念事項
・タスク管理表（TODOリスト）：実行担当者だけでなく、レビュー担当者や終了条件まで記載する
・会議体スケジュール：定例会、分科会、ステコミ、など
第3章 ダッシュボードの要求定義・要件定義
要求定義
・ビジネス課題の整理
・KGI／KPIの整理
・AsIs／ToBeの整理
要件定義
・利用目的、ユーザなどの整理
・業務プロセスのどの段階で利用するのかの整理
・ダッシュボードに必要な要素の整理
要求から要件に落とし込む
要求定義プロセス
①事業の理解
・PESTOLやSWOTなどの一般的なフレームワークで整理する
②業務の理解
・業務プロセス
・着目している／意思決定の根拠としている／行動のトリガーとなっている指標は？
③KPI設計：KPIツリー（ロジックツリーの一種）を使って、KGI／CSF／KPIのの関係性を整理する
・KGI（定量目標）：売上◯億円
・CSF（目標を達成するための必要条件、観点、定性目標）：新規会員を獲得すること
・KPI（必要条件をクリアするための定量目標）：新規来訪者◯人、サイト回遊率◯%
※ロジックツリーを使う時は、先入観に囚われず幅広い要因を洗い出すこと（ここが狭いと指標を漏らしてしまう）
※状態遷移や進捗状況を指標にしたい場合、プロセスに基づいた指標を設定すると良い
購買行動プロセス
サイト訪問：サイト訪問者数
商品明細ページ閲覧：商品ページ到達者数
カート追加：カート追加者数
決済ページ閲覧：決済ページ到達者数
購入：購入者数
④AsIsとToBeの整理
・定量目標（KGIとKPI）におけるAsIsを測定する
・AsIsを踏まえてToBeを設定する
・AsIsとToBeのギャップを特定する：KPIにおけるギャップを埋めるための行動がアクション（施策）となる
⑤課題の優先順位づけ
・どのギャップを優先して埋めるか（どのKPIを改善するのが効果的か）を優先順位づけする
・コスト
・難易度
・緊急度
⑥ダッシュボード導入要否の決定
・全てのデータ分析要件をダッシュボードで実装する必要はなく、定型的で高頻度な分析はダッシュボード化し、それ以外（難易度が高い、柔軟に分析したいなど）はアドホック分析で対応することを検討する
・状況によっては、ダッシュボードを導入することが不向きなケースもある（ダッシュボードはアプリのようにテストが必要になるため）
・以下のような場合、ダッシュボード導入ではなくアドホック分析の方が効果的なため、「本当にダッシュボードが必要なのか？」を振り返る必要あり
・分析結果が早く欲しい場合
・試行錯誤しながら分析したい場合：指標の算出、軸の変更
・頻繁な変更が想定される場合
・ダッシュボードにおいて、機能数と使いやすさはトレードオフ
要件定義プロセス
要件：ダッシュボードで何を見る必要があるのか？何が分かればいいのか？
何を見ればいいのか分からない場合、課題の認識が甘い（解像度が低い）ため、ロジックツリーなどでブレイクダウンする
①想定ユースケースの策定：「ユースケース一覧」
以下を整理して文書化する
①どの業務プロセスのステップで使うか？
②誰が使うか？
③何を決めるため／何をするために使うか？
→アクションとの関連性
④意思決定／行動を起こすためにどんな情報が必要か？
→ダッシュボードの表示項目、相互作用の要否
④どれくらいの頻度で情報が必要か？
→ダッシュボードの更新頻度
②ダッシュボードの全体構成を決める
典型的な構成の例
・エグゼクティブサマリー（経営層向け）
・各指標について、値カード（現在値、前月比、目標値との差異）＋推移グラフ
・相互作用は少なくて良い
・組織別ダッシュボード（組織長向け）
・自組織が管轄する範囲の情報
・詳細分析用ダッシュボード
・個々のレコード（データの最小単位）まで深掘りできるもの
③ダッシュボードの構成要素を決める
・ダッシュボードを構成するシート
・表示する項目の3分類
・指標：KPIなど、売上高、販売量、利益率
・属性：カテゴリなど、性別、家族構成、年齢
・行動：トランザクション、購入履歴、
・指標の見方
・時系列の推移
・カテゴリ別の比較
・相関関係
など
④実装の優先順位を決める
優先順位付けのパターン
・具体的な用途が決まっているものから実装する
・全体的なダッシュボードから実装する
⑤利用データを決める
・要件の実現に必要なデータが揃えられない可能性も高い
・利用可能なデータでどこまで分析可能か、要件通りの分析を行うためにできることは何か
ダッシュボード要件一覧表
・ダッシュボード名
・業務プロセス
・ステップ
・想定利用者
・想定するアクション：意思決定のパターンを参照
・更新タイミング
・シート名
・表示するKPI名
・データソース名
・優先順位
第4章 ダッシュボード設計
単純なダッシュボードの場合、または分析担当者自身がダッシュボードを実装する場合などは、スキップすることも可能
しかし、要求から要件を定義しただけでは、方向性しか決められておらず、ユーザとの期待ギャップ（可視化の寄せ集めに過ぎず、ユーザのアクションには繋がらない）が生じる可能性が高い
可視化の作成に必要な情報
・抽出条件：販売日が2023年
・指標：売上金額
・集計条件：商品カテゴリごと
・可視化の種類：横棒グラフで表示
意思決定のパターン
①施策の評価（継続／見直し）
必要な情報
・実績値と目標値との乖離：基準値を下回ったら
・予測値と目標値との乖離：閾値以上に乖離したら
・指標の推移：3期連続で減少したら
②リソースの再配分（選択と集中）
必要な情報
・投資対効果：低い案件から高い案件に回す
③新規プランの検討
必要な情報
・よく購入される商品の共通項（→共通項を持った新商品の開発）
・解約しそうな行動を取っている顧客（→リテンション策をかける）
ダッシュボードの用途
・モニタリング：問題があるかどうかを瞬時に判断できることが重要（原因の深掘りは不要）
・戦略や方針の立案：事象の詳細を深掘りして原因特定までできることが重要
・効果測定：実施した施策と効果を紐づけられることが重要
①指標モニタリング：テコ入れの要否を判断するもの
・目標値、計画値、予測値、基準値などからの乖離
・前期比較
・時系列推移
②現状のサマリ：問題や課題や改善点を探し出すもの
・商品や顧客セグメントでの比較
・相関関係（散布図）
・分布（ヒストグラム）
③原因の特定：個々のレコードまで深掘りするもの
・ドリルダウン
比較方法の検討
・大きさ：現場担当者にとっては差分の方がわかりやすい（比率は単位がなくなるため）
・値そのもの（差分）：基準値との差分、項目間の差分
・比率：基準値の何％、
・変化：時系列、周期（特定の曜日や月や四半期ごとに比較）
・構成費：ツリーマップ、内訳グラフ
・分布：ヒストグラム、人口ピラミッド
・関係性：散布図でクラスタリング、2指標間の相関を見る
分析設計の注意点
・全ての分析をダッシュボードで完結させようとしない：ここまではダッシュボードで提供し、ここからはアドホック分析で行う、のように線引きをする
・設計書を過剰にしない
・ユーザビリティを重視する
データの調査
データ調査の目的
・現状のデータの仕様や特徴を調査することにより、分析要件の実現可能性を確認する
・分析可能な状態に整えるまで、どれくらいの前処理（データマートを作るまでのETL処理）が必要かを検討する
ダッシュボードを作ろうと思っても、
・そもそもデータがない
・データはあるが分析に使えない（前処理しても使えなさそう）
・データは利用可能だが信頼性が低い
・どのフィールド項目を使えばいいか分からない
というケースは多い
前処理すれば使えそうなデータがある場合のみ、分析要件が実現可能だと判断できる
データ調査のステップ：データ管理ができてないと調査に時間がかかる
①データソースレベルの調査：重要なのは、データの提供元（担当者の手入力だと信頼性が落ちて分析結果と実態が乖離するため）
②テーブルレベルの調査：重要なのは、レコード総数や新規追加量（多すぎると分析実行が困難になるため）、履歴テーブルの有無（取得元テーブルに履歴テーブルを含める必要があるか？）
③カラムレベルの調査：テーブル定義書だけではなく実際の値の格納状況も確認する、分析に使おうとしているフィールドはあるのか？欠損値が多くないか？前処理すれば使えるのか？
ダッシュボード設計一覧表
設計を進める過程で具体的に追記していく
・ダッシュボード名
・シート名
・可視化名
・可視化する指標：売上
・可視化の種類：横棒グラフ
・可視化の軸：商品カテゴリ名＞商品名
・可視化に適用するフィルタ：集計期間
・接続するデータマート名
・指標の算出式
・指標の目標値
・意思決定のパターン
第5章 ダッシュボードデザイン
テンプレート、レイアウト、可視化などを設計し、モックアップ（静的、相互作用なし）またはプロトタイプ（動的、相互作用あり）を作成する
ダッシュボードの特徴
・ダッシュボードとは、可視化（ビジュアル）が配置（レイアウト）されたもの
・相互作用を設定できる
テンプレートのデザイン
ダッシュボードは複数作成することになるため、外観や挙動を統一できるようにテンプレートを作成するのがよい
ダッシュボードのサイズ
・1画面×複数シート：Z型配置、シートが増えすぎると往来が煩雑になるので注意
・2画面以上（縦スクロール）：F型配置
レイアウト（ワイヤーフレーム）：グリッドレイアウトが一般的
・タイトル
・フィルターエリア
・他ダッシュボードへのリンクエリア
・可視化配置エリア
配色
・メインカラー：青系
・ベースカラー：グレースケール
・アクセントカラー：オレンジ系
レイアウトのデザイン
個別ダッシュボードのデザイン
「ダッシュボード詳細設計書」に追記していく
可視化を並べる順番
例：要約→内訳
①現在値
②時系列グラフ
③
・店舗ランキング（横棒グラフ）
・商品ランキング（横棒グラフ）
…
例：深掘りのた目のグラフを下方向に並べる
↓各KPIの状況は順調か？
①各KPIの現在値（カード）や推移（時系列グラフ）
↓利益率が低下しているが、どの店舗（エリア、責任者）か？
②店舗別のKPI一覧
↓A店舗で利益率が低下しているが、どの顧客セグメント／商品カテゴリで低下しているのか？
③顧客別分析、商品別分析
可視化のデザイン
ひとつのダッシュボードにおける各可視化のデザイン
可視化の選択
・何を比較したいか？
・量
・変化
・構成比
・分布
・相関
・次元（比較の軸）は？
・時間軸あり
・時間軸なし
複雑な可視化は複数に分解する
・積み上げ棒グラフ → 合計値の棒グラフ＋各カテゴリの棒グラフ
・コンボチャート（棒グラフと折れ線グラフの2軸チャート） → 棒グラフ＋折れ線グラフ
・数表（比較しにくい） → スパークラインを配置
相互作用のデザイン
・フィルタ（スライサー）
・可視化間の相互作用：グラフAをクリックするとグラフBが絞り込まれる
・ドリルスルー：内訳データへの遷移
・ツールチップ：ホバー時にヒントを表示させる
第6章 データ準備・ダッシュボード構築
通常、ダッシュボードを直にデータソースに接続することはない
データパイプライン（ETLツール）を使って、データソースからデータマート（BIツールで扱うのに適した形態のデータベース）に変換する
「指標の算出式」の設計
一言に「売上」「会員数」と言っても
・売上：商品販売価格をそのまま使ってOK？値引額や返品額を控除するか？
・会員数：会員IDをそのままカウントしてOK？休会者を控除するか？
「指標の算出粒度」の設計
粒度を細かくするとBIツールで深掘りできる深度が深くなるが、細かくするとパフォーマンスやレスポンスタイムも劣化していく
月次の集計値でOK？
週刊や日間（各曜日）などの粒度も見たい？
「データマートのテーブル定義」の設計
BIツールを使うためには、BIツール用のDB（データマート）を作る必要がある
テーブル設計は、可視化の構成要素から考えると進めやすい
可視化の構成要素
・ディメンション：分析の切り口
・例：性別、地域、商品カテゴリ
・メジャー：集計する値
・例：人数、金額
・フィルタ条件
テーブル間のリレーションシップ
・パフォーマンスに注意
データマートテーブルのタイプ
・EAV型（Entity-Attribute-Value）：「メジャー名」というフィールドがある、最も柔軟性が高い（が、理解しにくい）
・例：日付｜店舗名｜メジャー名（売上、販売量、など）｜値
・Tidy Data型：メジャーはフィールドになっている、使いやすい
・例：日付｜店舗名｜売上｜販売量｜…｜値
・Wide Spread型：フィールドが多い（横に長い）、最も拡張性が低い
・例：日付｜店舗Aの売上｜店舗Aの販売量｜店舗Bの売上｜店舗Bの販売量｜…
「データマートのテーブル」の実装（ETL）
データソースからレコードをロードして、変換し、データマートに格納する
データサイズの絞り込み
BIに読み込むデータサイズはある程度の大きさにしないと、レスポンスタイムを毀損し、実業務で使えなくなる
そのため、データソースからデータマートを作成する際に、レコードを絞り込む必要がある
ただし、データマート作成時に処理しすぎると、ダッシュボード上で動的に深掘りしにくくなるので注意（例：ユーザがダッシュボードで集計期間を決めたい場合、データマート上では全期間のレコードを持っておく必要がある）
・フィールド数
・使わないフィールドは、データマートには読み込まない
・より軽いデータ形式に変換する：秒単位データを日単位データにする
・レコード数
・集計する
・期間を制限する（今年度のデータしか読み込まないようにする）
コード変換
データマートは分析に使いやすい方がよい（アナリストが使いやすい方がよい）ため、コード値は文字列に変換しておいた方がいい場合もある
「データの更新タイミング」の設計
自動更新できるもの
・決まった時間にスケジューラを設定
自動更新できないもの
・マスタメンテなど
更新頻度
・業務上で無駄がないように
データ準備における典型的な問題
手戻りが多く発生する
・ダッシュボードで可視化を作成している段階で、データマートにデータ項目が不足していたことに気づく
・データマート作成時に集計しすぎると、可視化作成時に粒度を細かくしたくなっても、変更できない（例：日次売上の集計値だけ見れれば十分だと考えていたが、後から毎日の商品別売上が見たくなった場合、データマートから作り直しになる）
データ件数が多すぎる
→データを一定期間で区切る
→データを集計する
結局何が言えるのか分からない
→アクションに繋がるレベルのカテゴリを導入する
「ダッシュボード」の実装
①データソースへの接続
②データの前処理（＝データマートの作成）
・データソースのテーブル単体に対する前処理
・数値計算
・文字列処理
・不要データの除外
・結合（JOIN）
③関数の作成
・PowerBIにおけるメジャー
④可視化の作成
⑤ダッシュボードの作成（可視化の配置）
⑥相互作用の設定
⑦レビュー
・数値の整合性
・相互作用
・レスポンスタイム
第7章 運用・レビュー・サポート
レビュー（QA）
構築中・構築後に品質を検証すること
設計レビュー
・レビュー時期：ダッシュボード設計完了後
・レビュー対象：モックアップ（静的）／プロトタイプ（動的）
※ウォーターフォール型で進める場合、静的でレビューできる部分を先にやっても良い
・レビュー観点
・表示情報からアクションや意思決定は可能か？：実際の業務プロセスを想定してレビューする
・レイアウト（可視化の配置）
・相互作用：実際の操作方法を想定してレビューする
・配色：認知的負荷を考慮
・文言
パフォーマンスレビュー
・レビュー時期：？
・レビュー対象：前処理スクリプト
・レビュー観点
・前処理に必要な時間
数値整合性レビュー
・レビュー時期：ダッシュボード構築完了後
・レビュー対象
・レビュー観点
・表示数値がデータソースと整合しているか？：再計算する
テスト運用レビュー（UAT）
・レビュー時期：ダッシュボード本番運用開始前
・レビュー対象
・レビュー観点
・実業務で使えるか？
・レスポンスタイム：実際に使い始めてみないと検証しにくい部分
導入後効果レビュー
・レビュー時期：ダッシュボード本番運用開始後（1〜3ヶ月後）
・レビュー対象
・レビュー観点
・ダッシュボード導入による定性的な効果
・ダッシュボード導入による定量的な効果
・導入プロジェクトの目標との比較
ユーザーサポート（ヘルプデスク）
ユーザがダッシュボードを業務に活用できるように支援すること
説明会の実施
①ダッシュボードの意図している目的や役割
②ダッシュボードの画面構成
③ダッシュボードの操作方法
④業務プロセス上の具体的なユースケース（シナリオ）
説明資料・マニュアルの作成
・データマートのテーブル定義書
・指標の計算ロジック
・ダッシュボードの構成要素がわかる資料
・データの更新タイミング（自動更新、マスタメンテが必要なタイミングなど）
など
ユーザとの継続的なコミュニケーション
・ポータルサイト
・FAQ
・チャット
継続的サービス改善（メンテナンス）
ダッシュボードの利用状況をモニタリングし、ユーザからのフィードバックを反映するサイクルを回すこと
利用状況モニタリング
・誰（部門、役職）が閲覧しているか？
・何回閲覧しているか？
アンケート
インタビュー
メンテナンス
・レコード数が増えると、ダッシュボードのレスポンスタイムも遅くなっていく
・マスタの更新
付録
ダッシュボード構築プロジェクトのチェックシート
略
あとがき
BIツールを触ってみた段階では、ダッシュボードを導入することは簡単に思える
しかし、実際に導入が成功するかは、プロジェクトに参加するメンバーに大きく左右される