[DX PMO] リードタイムDashboardの「データ入力」問題 — 測定の前提をどう整えるか

背景：Dashboardは作れた。しかし簡単ではない

何を作ったか

Fintech領域のプロダクト開発において、リードタイム（要件定義開始からリリースまでの日数）を追跡するDashboardを構築した。

Dashboard構成（5 TAB）:

  TAB 1: Overview        — KPIカード これまでのLead timeを目標を設定
  TAB 2: Product Line    — Line別リードタイム + フェーズ内訳 + 効率指標
  TAB 3: Distribution    — リードタイム分布 + 目標達成率サマリー
  TAB 4: Trend Analysis  — 週次スナップショット + Top Movers + LT Gap
  TAB 5: Project Size    — 規模分析 + Scope内訳（v2で追加）

データパイプラインはJira → DWH → dbt → BIツールで自動化されており、日次更新で最新のリードタイムを提供する。

何が難しいのか

Dashboardの「箱」は作れた。しかし運用を始めると、3つの構造的な課題が浮かび上がる。

これらは「Dashboardの問題」ではなく、組織のデータ入力プロセスの問題である。

課題C1：日付データの入力漏れ — フォールバックの限界

なぜ日付データが必要か

リードタイムは4つのフェーズに分解される。各フェーズの開始日・終了日がないと、ボトルネック分析ができない。

リードタイムのフェーズ分解:

  PRD Start ──▶ PRD End ──▶ Dev Start ──▶ QA ──▶ Release
  │                │                │          │         │
  │   PRD Phase    │   Dev Phase    │ QA Phase │ Release │
  │   (~70日)      │   (~78日)      │ (~21日)  │ (~26日) │
  └────────────────┴────────────────┴──────────┴─────────┘
                    合計: ~183日（中央値: ~147日）

現実：担当者が記入しないと始まらない

各フェーズの日付は、チケット管理ツールのカスタムフィールドに担当者が手入力する。

抜け漏れが発生しやすい理由:

• 担当者にとって日付入力は「本業」ではない

• 入力しなくても開発は進む（即座にペナルティがない）

• フィールドが多すぎて、どれが必須か分からない

• ステータス遷移のタイミングと日付入力のタイミングがズレる

対策：フォールバックロジック + カバレッジ監視

フォールバックロジック

日付が未入力の場合に、代替データから推定する仕組みをデータモデルに組み込む。

PRD End Date のフォールバック優先順位（11段階）:

  1. PRD End Date（カスタムフィールド）  ← 最も正確
  2. Dev Start Date（開発開始 ≒ PRD完了）
  3. ステータス変更履歴: PRD → Dev への遷移日
  4. ステータス変更履歴: To Do → Dev への遷移日
  5. ... （中間の代替ソース）
  11. 現在日付（進行中の場合）           ← 最後の手段

フォールバックの段数が深いほど精度は落ちる。理想は第1〜2段で解決すること。

カバレッジ率の監視

フォールバックに頼らず、元データがどれだけ入力されているかをトレンドで追跡する。

Phase Duration カバレッジ率（週次トレンド）:

  Coverage %
  100│
     │                                    ●─────● Overall
   80│                              ●─────●
     │                       ●─────●
   60│                ●─────●                    ●──── PRD
     │         ●─────●                    ●─────●
   40│  ●─────●                     ●─────●
     │                        ●─────●            ●── DEV
   20│                  ●─────●
     │           ●─────●
    0┼──────┬──────┬──────┬──────┬──────
    02-16  03-02  03-16  03-30  04-13

カバレッジ率が上がれば、フォールバックへの依存が減り、Dashboard全体の精度が向上する。

データ入力を促進する仕組み

推奨: チケット自動化 + Slackアラートのハイブリッド。自動化で80%をカバーし、残りをアラートで補完する。

課題C2：プロジェクト単位の不統一 — 何を「1件」と数えるか

なぜ単位が重要か

リードタイムの比較は「1プロジェクト」単位で行う。しかし、プロジェクトの粒度がバラバラだと、比較が成立しない。

粒度の問題:

  プロジェクトA: 「送金機能リニューアル」
    → 10チーム関与、120 PM、リードタイム 300日

  プロジェクトB: 「ボタンの色変更」
    → 1チーム、0.5 PM、リードタイム 14日

  → 平均リードタイム: (300 + 14) / 2 = 157日  ← これに意味はあるか？

測りやすくするための3つのアプローチ

アプローチ1: サイズクラスで層別化

プロジェクトを工数（PM）ベースでサイズ分類し、同じクラス内で比較する。

アプローチ2: 効率指標（Days per PM）で正規化

リードタイムを工数で割ることで、規模を正規化した効率指標を得る。

Days per PM = SUM(Lead Time) / SUM(Person Month)

  例:
  Line A: 平均LT 200日、平均PM 3.0 → Days/PM = 66.7（規模の割に効率的）
  Line B: 平均LT 120日、平均PM 1.1 → Days/PM = 109.1（規模の割に遅い）

  → 平均LTだけ見るとLine Bの方が「速い」が、
    規模を考慮するとLine Aの方が「効率的」

この指標により、「リードタイムが長い → 規模が大きいから仕方ない」vs「規模の割に遅い」を区別できる。

アプローチ3: 件数の定義を厳格化

「1件」の定義を組織で合意し、例外ルールを明文化する。

課題C3：見積もり工数（PM）の未整備 — 最適化が大前提

なぜ見積もりが必要か

今回リードタイムDashboardについて、Project Sizeの観点が追加された。「リードタイムが長いのは、規模が大きいから仕方ないのか？ それとも規模の割に遅いのか？」を構造的に議論するためである。

この議論には、見積もり工数（Person Month） が不可欠。

見積もり最適化のロードマップ

Phase 1: カバレッジの引き上げ（以下は、例）

Phase 2: 見積もり精度の検証サイクル

見積もりが蓄積されたら、見積もり vs 実績のフィードバックループを回す。

見積もり精度の継続改善サイクル:

  ┌─ Planning ─────────────────────────────────────────┐
  │  チーム別工数見積もり                                  │
  │  ※過去の見積もり精度データを参照しながら見積もり        │
  └────────────────────────┬───────────────────────────┘
                           ▼
  ┌─ Development ──────────────────────────────────────┐
  │  進捗ダッシュボードがリアルタイム更新                  │
  │  Done遷移 → 実工数を記録                             │
  └────────────────────────┬───────────────────────────┘
                           ▼
  ┌─ Review ───────────────────────────────────────────┐
  │  見積もり vs 実績の自動比較レポート                    │
  │  チーム別・規模別の見積もり精度分析                    │
  └────────────────────────┬───────────────────────────┘
                           ▼
                     次のPlanningへ（精度が上がった状態で）

Phase 3: 因数分解による構造的な議論

見積もりが整備されると、リードタイムを4つの要素に因数分解して議論できるようになる。

リードタイム = f( 規模, 投入, 効率, 構成 )

4要素を一緒に見る理由: LTという1つの結果を「規模の効果」「投入の効果」「効率の効果」「構成の影響」に分けることで、「なぜそのLTなのか」「改善したのか」「妥当なのか」を構造的に議論できる。1つでも欠けると、別の要因で説明がつく反論を潰せない。

Scope（スコープ）の扱い — 工数だけではProject Sizeが決まらない

なぜScopeを変数に含めるか

同じプロジェクトでも、Scope（BRD / PRD / Dev / Delivery）によって工数の意味が変わる。

二軸アプローチ（推奨）

二軸で見るシミュレーション:

  主軸（Deliveryのみ）:
    件数: 5件 → 5件（同じ）
    工数: 100 PM → 120 PM（投入増）
    LT:   100日 → 80日（短縮）
    Days/PM: 5.0 → 3.3（効率改善）

  補助軸（全Scope内訳）:
    PRD:      30 PM → 20 PM
    Dev:      70 PM → 60 PM
    Delivery: 100 PM → 120 PM
    合計:     200 PM → 200 PM（全体は同じ）

  → 全体工数は同じ200 PMだが、Deliveryのシェアが50%→60%に上昇
  → 「今四半期は届けることにリソースを集中した」と解釈できる

Weekly vs Quarterly の使い分け

実践のポイント

1. Dashboardの精度は「入力率」で決まる

どれだけ高度な分析ロジックを組んでも、元データが入力されていなければ意味がない。カバレッジ率を最初のKPIにすることで、Dashboard自体の信頼性を可視化できる。

2. フォールバックは「保険」であり「常態」にしてはいけない

フォールバックロジックは未入力データを補完する強力な仕組みだが、段数が深いほど精度は落ちる。フォールバックへの依存度を週次で監視し、第1〜2段で解決する割合を80%以上に保つことを目標にする。

3. 見積もりなき計画は「勘」の域を出ない

見積もりカバレッジが低い状態だと、「規模の割に妥当か」の議論はできない。まず直近のDeliveryスコープから着手し、目標の数値まで引き上げることで、因数分解による構造的な議論が可能になる。

4. 「1件」の定義を合意してからDashboardを見せる

プロジェクトの粒度が統一されていない状態でDashboardを見せると、「この数字は何を数えているのか」という議論に時間を取られる。件数の定義・除外条件・分割ルールを先に合意しておく。

5. 自動化で入力負荷を下げ、アラートで漏れを拾う

担当者に「入力してください」と言い続けるのは持続可能ではない。ステータス遷移に連動した日付の自動セット（80%カバー）+ 未入力アラート（残り20%の補完）のハイブリッドが現実的。

まとめ

• リードタイムDashboardの価値は、データ入力の品質に完全に依存する。フォールバックロジックで補完はできるが、元データの入力率向上が本質的な解決策

• プロジェクト単位の不統一は、サイズクラス分類と効率指標（Days per PM） で正規化することで、異なる規模のプロジェクトを公平に比較できるようになる

• 見積もり工数（PM）の最適化は、リードタイムを因数分解（規模・投入・効率・構成） して構造的に議論するための大前提。

• Dashboardは「作って終わり」ではない。入力プロセスの整備 → データ品質の監視 → 分析精度の向上という継続的な改善サイクルを回すことで、初めて組織の意思決定に使えるツールになる

関連記事

• [DX PMO] 開発進捗の可視化と見積もり精度の継続改善サイクル

• Fintech DX PMOの思考法と行動原則 - ドメイン特性が変えるPortfolio / Program / Project管理