ダッシュボード開発で手戻りをしたくないので、技術書『ビジネスダッシュボード 設計・実装ガイドブック』を読みました

『ビジネスダッシュボード 設計・実装ガイドブック 成果を生み出すデータと分析のデザイン』（翔泳社）という書籍でダッシュボード開発について学習しました。本記事では、この学習で得た学び・気付きを紹介します。

はじめに

私は都内某所に本社があるサービス事業会社でソフトウェア開発エンジニアとして勤務しています。これまで私が所属するチームは自社サービスの開発業務（機能追加や障害改修など）に従事していましたが、数ヶ月前からこのサービスのダッシュボード開発も業務内容に加わりました。なお、このダッシュボードはサービスのユーザーの利用状況を可視化し社内メンバーが新規企画を行うことを支援するもので、要求事項が詳細に定まっていないところからの開発スタートとなります。これまでの開発経験を活用すればダッシュボード開発もやりきれるとは思ったものの、ダッシュボード開発に固有の課題がもしも存在するのであれば事前に知りたいと思い、この技術書で学習しました。

ちなみに、この技術書ではダッシュボード開発の各工程（要求定義〜要件定義〜設計〜実装〜運用・サポートに関して進め方や成功するためのコツが解説されており、私がまさに知りたいことが記載されていました。ただ、特定のBIツールの使用方法やデータビジュアライゼーションの具体的な手法などについては詳細な解説がなかったため、これらについては別の技術書で学習したいと思います。

想定するダッシュボード開発

この記事では、事業やサービスのKGI・KPIを取り扱うなダッシュボードの開発を想定しています。

学び・気付き

この技術書の学習で得た学びと気づきは以下のとおりです。
※技術書の要約ではないことにご注意ください。

ダッシュボード開発の全体像

ダッシュボードの開発の工程の全体像として以下が紹介されていました。

1. 要求定義・要件定義
   • 要求定義
     • ビジネス課題整理
     • KGI/KPI整理
     • 現状の取り組みや今後の取り組み案確認
   • 要件定義
     • 利用目的、ユーザーなどを整理
     • 業務プロセスのどの段階で利用するのか整理
     • ダッシュボードに必要な要素の整理
2. ダッシュボード設計
   • 分析設計
     • ダッシュボード要件の詳細定義
       • 指標・比較軸の検討など
     • データ調査
   • ダッシュボードデザイン
     • レイアウト、デザイン設計
       • ワイヤーフレーム作成
       • モックアップ作成
3. データ準備
   • データマート設計
     • 計算ロジック確認
     • ダッシュボードデザインを考慮したテーブル設計
   • データマート実装
     • データマート作成
     • データパイプライン構築
4. ダッシュボード構築
   • ダッシュボード構築
     • データ接続、前処理
     • 関数作成、計算チェック
     • チャート作成
     • ダッシュボードレイアウト作成
     • チャート配置
     • フィルターなどの動作設定
     • 動作チェック
     • パフォーマンスチェック
5. 運用・レビュー・サポート
   • 運用
     • 利用状況モニタリング
     • 利用者インタビュー
     • 利用に合わせた改善
     • メンテナンス
   • レビュー
     • 機能、デザイン確認（構築前〜構築後に実施）
     • 数値整合性確認（構築前〜構築後に実施）
     • テスト運用（構築前〜構築後に実施）
     • 導入後効果検証
   • サポート
     • 説明会
     • 説明資料準備
     • Q&A設置

学習前は漠然とした「要件定義〜設計〜実装〜運用・サポート」を実施するのだろうぐらいのイメージしかなかったのですが、学習によりダッシュボード開発の各工程で実施することの解像度を上げることができました。特に要求定義・要件定義で整理すべきことが明確になったおかげで、これらを実践することでダッシュボード開発の手戻りを減らすことができそうです。

ウォーターフォール開発とアジャイル開発の両者の特徴を併せ持ったハイブリッド開発

全工程をウォーターフォール開発またはアジャイル開発のどちらかで実施するのではなく、これらの開発手法の両者の特徴を併せ持った「ハイブリッド開発」が紹介されていました。

• 全体的な要求定義・要件定義〜ダッシュボード設計（大枠の設計）〜データ準備（複数のパートに関わる部分）
  • ウォーターフォール開発で実施
• リリース単位での要求定義・要件定義〜ダッシュボード設計〜データ準備〜ダッシュボード構築〜運用・レビュー・サポート〜本リリース
  • アジャイル開発で実施

大枠な設計やその後の開発で共通して使用されるデータマート作成まではウォーターフォール開発で実施しておき、その後の開発はアジャイル開発でインクリメント開発をしていくイメージです。
私の所属チームでは自社サービスの機能追加や障害改修などではアジャイル開発を採用しているため、今回の学習前は今回のダッシュボード開発でもアジャイル開発を採用するつもりでしたが、後々の手戻りを減らす意味で、ハイブリッド開発を採用したいと思いました。（※実際にハイブリッド開発を採用するかどうかは、チーム内での相談が必要となります）

「使われないダッシュボード」になる可能性

ダッシュボードの開発が終わって関係者の最初の評判は良いものの、そのダッシュボードが最終的に全く使われなるケースが世の中にはあるそうです。そのような事態を招く要因として、以下のようなことが挙げられていました。

• 要求定義・要件定義や設計が問題
  • 開発されたダッシュボードが、どのような目的で使うのかが曖昧なまま、誰がどのような業務で使うのか・誰に何を知ってほしいのかを想定せずに作られた
• データの構造や運用・サポートが問題
  • 開発されたダッシュボードの動作が重い
  • データが更新されない
  • 新たに必要な機能やデータが出てきても、反映されない
  • 使い方がわからない、使い方を誰に聞いたら良いのかわからないし、使い方の調べ方もわからない

私は今回の学習開始時は、開発した後のことまでは正直思い描いてはおらず、漠然と開発すれば社内メンバーはそのダッシュボードを必ず使ってくれるものだと考えていました。ですが、「使われないダッシュボード」という単語をこの技術書で目の当たりにし、開発の要求定義のタイミングから丁寧に作業をする必要があると気付かされました。

ダッシュボードの3種類の代表例

以下のような3つ種類の代表例があるとされています。

1. モニタリング：コンディションを「モニタリング」、素早く診断するためのKPIダッシュボード
2. 戦略・方針立案：課題抽出→原因特定し、「戦略・方針立案」を行うための分析用ダッシュボード
3. 施策を「効果測定」する、施策効果測定ダッシュボード

私はこれまではダッシュボードを分類して考えることがなかったので、私にとっては新たな知見でした。私の所属チームがこれから開発するダッシュボードについては、聞いている話ではおそらくは上記の1.と2.の両方がターゲットなのですが、3.についての要求が本当に存在しないのかを社内メンバーに確認が必要だと感じました。

データ分析の4つのタイプ

データ分析の4つのタイプが紹介されていました。意思決定のパターンに応じて、複数組み合わせて使用されるということです。分析タイプによって、後述の3つのタイプのダッシュボードの中のどれが合う・合わないがあるそうです。

1. 現状診断型
   • KGIやKPIの現状を確認することでビジネスのコンディションを把握する
   • 現在地と目標値との比較、現在と過去の同時期の値の比較、時系列でのKPIの推移による数値トレンド確認など
2. 課題特定型
   • KGIやKPIを事業単位や店舗単位など業務の区分で比較
   • 想定通りの成果を出している事業・出していない事業、売上が高い店舗・低い店舗などを把握することで、ビジネス成果の課題をさらに詳細に分析する
   • ビジネスのどこに課題があるのかを分析するのが目的
3. 特徴・特性探索型
   • 対象の特徴や傾向を発見するために、比較軸やデータ抽出条件を切り替えながら試行錯誤的に集計結果の分析・解釈を行う
   • 課題の原因や構造をあぶり出すことが目的
4. 戦略・施策評価型
   • 戦略・施策立案時の想定通りに成果が得られたかを明らかにする分析
   • 顧客に対する洞察に従ってデザインされた戦略・施策の成果が想定通りかどうか分析する

私はこれまではデータ分析を分類して考えることがありませんでした。ですが、要求定義・要件定義でこれらのタイプを意識して整理することで、今回開発するダッシュボードについての解像度を上げることができる気がします。

ダッシュボードの3つのタイプ

ダッシュボードには以下の3つのタイプがあると解説されていました。情報の詳細レベルが異なります。

1. 全体サマリーダッシュボード
   • 経営層向けのダッシュボードのように、複数のKGIやKPIをモニタリングするためのダッシュボード
   • 短時間で、複数事業のビジネス状態を把握するのに非常に便利
   • 前述の分析タイプの「現状診断型」が特に適している
2. テーマ別ダッシュボード
   • ダッシュボードを使う人の領域に合わせて、担当業務のビジネス状況を把握するためのダッシュボード
   • 前述の分析タイプの「現状診断型」や「課題特定型」、「戦略・施策評価型」に適している
3. 詳細分析ダッシュボード
   • テーマ別ダッシュボードに載せると情報量が多くなり過ぎるダッシュボードや、非常に細かい粒度での分析を実現するダッシュボード
   • テーマ別ダッシュボードの分析を補助する
   • テーマ別ダッシュボードの分析で十分な場合は構築しないこともある
   • 前述の分析タイプの「課題特定型」、「特徴・特性探索型」、「戦略・施策評価型」に適している

私の所属するチームが開発するダッシュボードに関しては、経営層が使用する想定ではないものの、サービス全体のKPIのモニタリングも想定されているため、1.と2.が必須となりそうです。

ダッシュボードデザインの作業ステップ

ダッシュボードのデザインを決定するには以下の4ステップがあると解説されていました。

1. テンプレートデザイン
   • ダッシュボードサイズの設定、ワイヤーフレームの作成、配色ルールの決定
   • 複数のダッシュボードを構築する際の、体裁や見た目、配色などを統一する
2. レイアウトデザイン
   • 視線の流れを意識したチャートの配置
3. チャートデザイン
   • 最適なチャートの選択
     • 「指標の比較方法」、「比較軸の数」、「比較軸に時間軸を含むか」の3つの条件の掛け合わせで最適なものを選択する
     • 最も重要なことは「指標の比較の方法とチャートの形式が合っているか」
   • シグナルとノイズを意識したデザイン
     • シグナル：集計値の持つ情報やその傾向を読み取るために必要不可欠な要素
     • ノイズ：シグナル以外のチャートの構成要素
     • ダッシュボードのユーザーが分析に集中できるようにノイズを排除することが大事
   • 複雑なチャートは複数のチャートに分解
4. インタラクティブ機能デザイン
   • インタラクティブなフィルター機能のデザイン
   • ボタンによる指標やチャートの切り替え機能
   • 詳細情報の表示にツールヒントを有効活用する

この解説を読んで、段階を踏んでダッシュボードのデザインを決定することの大事さが理解できました。
もしもこの解説を読まずにダッシュボードの開発を行っていたら、BIツール上で深く考えずに場当たり的にチャートをダッシュボード上に配置していったと思います。その結果、見づらいダッシュボードが出来上がっていたかもしれません。

ダッシュボード開発は構築が終わってからが本番

ダッシュボードが利用され続けるための取り組みとして以下が紹介されていました。

1. レビュー
   • ダッシュボードの構築中と構築後に、様々な観点でレビューを受ける
   • 機能レビュー、数値整合性レビュー、テスト運用レビュー、導入後効果レビュー
2. サポート
   • ダッシュボードの構築後、ユーザー向けに説明会を実施するなど、ユーザーの疑問に解決できる仕組みを整える
   • 説明会の実施、説明資料の準備、Q&Aの場の設置
3. 改善・メンテナンス
   • 定期的に利用状況のモニタリングを行い、必要に応じて改善する
   • 利用状況モニタリング・ユーザーインタビュー、改善、メンテナンス

今回の学習前の時点では、ダッシュボードの開発後のサポートやメンテナンスといった作業については考慮できていませんでした。せっかく開発するダッシュボードなので、社内メンバーには長く活用して欲しい気持ちが大きいです。なので、これらの作業についても計画段階から考慮したいと思いました。

おわりに

今回の記事では、『ビジネスダッシュボード 設計・実装ガイドブック 成果を生み出すデータと分析のデザイン』という技術書でダッシュボード開発ついて学習して得た学びと気づきを紹介しました。この学習を通じて要求定義・要件定義の工程でやるべきことの解像度が上がったことで、手戻りの可能性を大幅に低減できそうです。また、使われないダッシュボードになる可能性とダッシュボード開発も構築が終わってからが本番であることなど、開発した後についての注意点に事前に気づけたのは大きな収穫でした。
これらの学びと気づきを活かして、社内で長く活用されるダッシュボードを業務で作り上げたいと思います。