ビジネスダッシュボード 設計・実装ガイドブック(8)

運用・レビュー・サポート

所感

レビューに関しては、ダッシュボードにフォーカスしているが、製品開発でも同様の事が言えそうに思います。
その意味ではレビューのパターンは覚えておいて損はないかと…

データサイエンス好きとしては、改善・メンテナンス周りのユーザの利用履歴、操作履歴などにもっと細かいテクニックが欲しかったｗｗｗ

構築が終わってからが本番

1. レビュー
   レビューの時期、観点、レビュアーは目的によって異なる。
   その種類や内容について考える。
2. サポート
   ユーザ向け説明会などユーザサポートについて考える。
3. 改善・メンテナンス
   定期的に利用状況のモニタリングを行い、必要に応じて改善する。
   改善やメンテナンスについて考える。

を行うフェーズ。

レビュー

• 機能レビュー 機能が十分かどうかを確認しませう。
  • ダッシュボード設計後
  • ダッシュボードのユーザをレビュワーに置きます。
  • 観点
    • ダッシュボードに求める分析要件（指標、比較軸、フィルター等）が揃ってるか
    • 想定した使い方ができそうか
    • アクションに必要な意思決定ができそうか
• デザインレビュー デザイン面・操作面で利用しやすいものになっているかどうか確認しませう。
  • ダッシュボード設計後
  • やはりダッシュボードのユーザをレビュアーを置きます。
  • 観点
    • レイアウト構成が使いやすいものになっているか
    • チャート形式は目的に沿ったものか
    • 色分け、スタイルは？
    • 言葉遣いは？
    • 認知負荷は？（情報量は適切？）
    • 操作は難しくない？
• 数値整合性レビュー 表示される数値が実情に合ってるか？
  • ダッシュボード構築後、実データを反映して行う
  • ビジネス面で数値に理解のあるユーザー、集計方法に詳しいデータ周りの担当者をレビュワーに置く
  • 観点
    • 各指数の数値が合ってるか？
    • 指標の計算ロジックが合ってるか？
    • 用いるデータは合ってるか？
• テスト運用レビュー 資運用して不備がないかを確かめるテスト運用レビューです
  • プロトタイプ作成中に行うのが望ましい。
  • ダッシュボードユーザをレビュワーに置く。
  • 観点
    • 業務利用で不備はない？
    • 使い勝手に不備はない？
• 導入効果レビュー ビジネスや業務に影響を与えたかの確認
  • 導入後ある程度日を開けてから、１～３か月後。その後は半年～1年単位で。
  • レビュワーには業務領域にかかわる人、ダッシュボードを確認するユーザ等
  • 観点
    • 導入で定量的効果があったか？
    • PDCAサイクルが早くなった、改善のサイクルが上がった等の効果があったか？

サポート

説明会や、説明資料、QAの設置等で利用者に下記を理解してもらう。

1. ダッシュボードの目的や役割
2. 画面の構成解説
3. 操作方法解説

4. 具体的分析（いくつかの例を元に、使い方説明）

5. 説明資料

   • データマートのテーブル定義書
   • 指標の計算ロジック
   • ダッシュボードの構成要素の説明
   • データ更新のタイミング定義
6. QAの場の設置
   • 定期的な質問会
   • チャットグループ作成
   • Tips集の作成

改善・メンテナンス

利用状況を、定期的なモニタリングやユーザインタビューを行いませう。

1. 集にどの位利用されてるか
2. 誰が主に利用してるか？どんな役割の人か？

どんな機能が一番役立つか、どんなタイミングで、どの様な操作をしているかを聞いて、改善に役立てよう。
定期的メンテナンスとしては、データの肥大化で速度劣化が起きていないか確認しませう。