全体フロー
データ可視化プロジェクトの企画から改善までの全体工程
flowchart LR
A[企画] --> B[要件定義]
B --> C[データ準備]
C --> D[BI開発]
D --> E[テスト]
E --> F[リリース]
F --> G[運用]
G --> H[改善]
H --> A企画フェーズ
企画フェーズの目的は、解決する課題とプロジェクトの成功条件を明確にすること。実現方法を決める前に、現状の課題、利用者、意思決定の目的、期限の整理が必要
課題の一覧化
課題の漏れや重複を減らすため、MECE（相互に重複せず、全体として漏れのない状態）の考え方による整理
トップダウンアプローチ
全体像から要素を分解し、課題を整理する方法
- 全体像となる親要素の定義
- 地域、年齢、商品などの明確な軸による要素分解
- 売上を「単価 × 数量」のような方程式による分解
ボトムアップアプローチ
現場の事実や具体的な業務を積み上げ、課題を整理する方法
- 業務や営業活動の具体的な手順の洗い出し
- 手順の時系列による整理
- 自身、自チーム、前後工程のチーム、既存BI（ビジネスインテリジェンス）、関連業務の担当者への聞き取り
- 実現可否を問わない理想状態の一覧化
営業活動の流れの例: リード獲得 → 初回商談 → 提案 → 受注 → 納品
課題の選定
一覧化した課題から、プロジェクトで優先して解決する課題を選定
- KGI（最終目標を測る数値）の明確化
- 課題の一覧化
- MUST（必須事項）とWANT（希望事項）への分類
- 改善対象となるKPI（途中経過を測る数値）の決定
- プロジェクト成功条件の定義
アクションにつながる成功定義
プロジェクトの成功は、KPIの可視化だけでなく、異常の検知後に適切な対応を実行し、結果に基づいて継続改善できる状態
flowchart LR
A[KPIの可視化] --> B[閾値との比較]
B -->|閾値超過| C[担当者への通知]
C --> D[原因確認]
D --> E[対応の実行]
E --> F[対応結果の測定]
F --> G[閾値の改善]
F --> H[対応方法の改善]
G --> B
H --> Eアクション設計の決定事項
異常の検知から対応方法の改善まで、事前に決定する内容
| 項目 | 決定内容 |
|---|---|
| 閾値設定 | 正常、注意、異常を判定する数値 |
| 通知条件 | 通知対象となる閾値、継続時間、発生回数 |
| 通知先 | 担当者、責任者、関係部署 |
| 通知方法 | BI、メール、チャット |
| 対応内容 | 通知後に実施する確認と作業 |
| 対応期限 | 通知から対応開始・完了までの時間 |
| 結果測定 | 対応によるKPIの変化 |
| 閾値の改善 | 誤検知や検知漏れに基づく閾値調整 |
| 対応方法の改善 | 対応時間と効果に基づく手順改善 |
利用条件の整理
利用者ごとに必要な情報と閲覧可能な範囲を整理し、ダッシュボードによる意思決定の目的を明確化
| 確認項目 | 確認内容 |
|---|---|
| 閲覧者 | 本社、現場、社外関係者、部長、課長、メンバー |
| 閲覧情報の制限 | 利用者ごとの閲覧可能情報、集計値への部長・課長の要否 |
| 閲覧頻度 | 日次、週次、月次、年次 |
| 意思決定の目的 | ダッシュボードを見た後に決定する内容 |
| コンプライアンス（法令・社内規則の順守） | 現場担当者が確認できる社外関係者情報の範囲 |
期限と開発範囲の決定
最初から全機能の完成を目指さず、短期間で1サイクルを完了させるための範囲設定
- PDCA（計画・実行・評価・改善）を早く回すための期限設定
- 開発範囲の最低2フェーズへの分割
- MUST（必須事項）の優先度による分割
参考情報
企画フェーズでの課題整理や改善方法に関する参考情報
