ビジネスダッシュボード 設計・実装ガイドブック(2)
概要
これの続き。
2 章を読んでいく
第二章「ダッシュボード構築プロジェクトの全体像」
プロジェクトの全体像
ダッシュボード構築プロジェクトの全体像と、フェースはざっくり5段階
- 要件定義・要件定義フェーズ
どんなビジネス課題、KGI*1/KPT*2を測りたいのか？
誰が、どの業務プロセスで、どんな目的で使うのかを想定して要件を定義する。 - ダッシュボード設計フェーズ
求められているダッシュボードの実現性を、データの種類、定義、取得・生成方法、欠損、偏りなどを踏まえて調査する。
レイアウト、デザインなどのワイヤーフレームモックアップを作成する。
図や指標をどこにどう配置するかなどもここで検討する。 - データ準備フェーズ
モックアップをダッシュボードとして実現するのに必要なデータマート*3の要件を整理して、テーブル構造の設計や、テーブルの作成を行う。
また、データマートを自動更新するためのデータパイプライン構築はこのフェーズ。 - ダッシュボード構築フェーズ
作成したデータマートをBIツールに接続する設定と、ダッシュボード設計に合わせてダッシュボードを構築する。 - 運用・レビュー・サポートフェーズ
ダッシュボード構築時や、構築後にユーザやプロジェクト関係者からフィードバックをもらって、ダッシュボードの改修を行うフェーズ。
ぶっちゃけ息が一番長い…
プロジェクトの必要スキル
大きく分けて二つ
- ハードスキル
- BI ツール操作スキル
- BI ツール構築スキル
- SQL 等のデータ抽出スキル
- データパイプライン構築スキル
- データベース環境構築、運用保守スキル
- ソフトスキル
- プロジェクト管理スキル
- 要求定義・要件定義スキル
- アナリティクススキル
- ダッシュボードデザインスキル
- データマート設計スキル
多分経験ないのは、プロジェクト管理と、BI ツール系、アナリティクスと、ダッシュボードデザインスキルかな…
Tableau 周り Trailhead やるかな…
プロジェクト体制
主にかかわるのは以下面子
データアナリストを除けば、ロール自体は通常の開発プロジェクトとさほど変わらないなというのが個人的な印象。
プロジェクトの進め方
…と言っても、WF と アジャイルの紹介だけですね…。
この違いは既に議論されつくされた感があるので割愛。
- 参考: ウォーターフォール 併せて読んでおきたいのは V字モデル かな
- 参考: アジャイル 因みにアジャイルはイテレーションだーとだけ言ってる人もいるが、即対応を是とする XP や、作業フローを1週間等の等間隔で区切ってフェーズを回す スクラム (ソフトウェア開発) - Wikipedia や、パイプラインの様なタスク処理型で完結する かんばん (ソフトウェア開発) - Wikipedia 等があり、そこにチーム固有のプラクティスが入ってくる。
どっちを採用するではなくて、ハイブリッドで進める場合があるそうだ。
それは要望によるが
なんてのが多いらしい。
実に現場っぽいなぁと (;'∀')
因みにハイブリッド案の例として
- データ準備フェーズ までは WF で進める
- 以降のフェーズは アジャイル で進める
という案を提示している。
何だろう… SIer 時代超やったパターンだ（汗
各フェーズの成果物
成果物を事前に上げておくと
- 成果物単位を小さな目標にしてスケジュールすると、プロジェクト管理しやすい
- 成果物から逆算で作業を見通しできる
- インプット/アウトプットが明確だとステップごとの判定がしやすい
- アウトプットがあると期待値の基準に達してるか判断しやすい
逆算思考ですね。
プロジェクトマネジメントの重要性と具体的な内容
ダッシュボードプロジェクトの特性として、利用するデータソース次第で、プロジェクトにかかわる組織が横断的になりやすい。
横断的になるほど、プロジェクトの関係者やユーザが増加するので、方向性を決定するための論点、解決すべき事項、タスク、スケジュール等の把握がしづらくなる。
最悪、プロジェクトメンバーが思い思いのタスク実施を始めてしまって、プロジェクトが停滞…解散！なんてことがありえるそうで…
何か聞き覚えあるなぁと思ったら、Facebook 社の VR 事業周りが似たような状況になって、統括者が辞めたなんてニュース とかあったな…
ダッシュボード構築プロジェクトにおける進行管理
おおよそ次の事を行う
- ロードマップ作製
ゴールとプロジェクトの全体像を俯瞰的に書いた計画書の事。
ここに中間目標（マイルストーン）や成果物を設定する。
全体戦略や施策なども書いとくと、プロジェクトがブレない。 - スケジュール進捗管理
プロジェクト運用時に進捗状況を確認する。 フェーズで実施すべきタスクの一覧を作って、ガントチャート等で可視化しながら、遅延状況や課題の進行状況を確認します。 - タスク管理と課題管理
タスクの進捗状況を表にして管理します…Backlog なら カンバン でも見ろやと思わなくない…。 - 会議体の設計
「どのような会議を、どのメンバーが、どれくらいの頻度で開催するか」を決定する。
よくある会議体は- 定例会議 : 進捗状況と、課題管理表の議題について
- 分科会 : 定例で消化しきれない課題についての会議
- ステアリングコミッティ : 経営層などに対するプロジェクト報告、相談
- 四半期ビジネスレビュー : プロジェクト成果報告、次四半期の計画共有
個人的に会議体の設計というのは初耳でした…。
多分経営とか戦略ではなくて、あくまで開発現場に好んで張り付いてたから、その概念がなかった…。
興味深いですね。
二章感想
所々で、通常の製品開発プロジェクトと異なる要素が出てくるのが興味深い。
プロジェクトメンバーにデータアナリストやダッシュボード活用責任者が関わってくる、プロジェクトマネジメント周りで、組織を横断する必要性に迫られる辺りは特に通常のプロジェクトと異なる。
また、製品開発と異なるという意味では、顧客に当たるのに経営陣も含まれるので、分科会では各部署の関係者も入ってくるあたり。
おおよその流れが製品開発と似たようなものだが、「似たような物だろ」と考えすぎると足元を掬われそうですね。
