BPR/DX WBS テンプレート — Phase 0 構想策定 + 90 日キックオフ (Day -30〜Day 90) タスク分解

対象: 売上 100 億規模 (従業員 150 名規模) 建設・土木企業 (公共工事比率次第) の DX/BPR プロジェクトを Phase 0 (構想策定 Day -30〜-1) + 90 日キックオフ (Phase 1-3 Day 0-90) で進める bizlp 内部運用テンプレート。 用途: 顧客 1 社につき 1 部作成。Phase 0 で記入 → Phase 1-3 で進捗チェック → Day 91 以降の Phase 4 (Pilot 実行) への引き継ぎ。 位置付け: A.03.4.1 (解説) と A.03.4.2 (8 論点記入用) の橋渡し。Day 単位のタスク分解 + RACI + リスク行列 + 工数根拠を 1 ファイルに集約。 版改訂: 本テンプレは RQ-111 audit (2026-06-25 / 3 モデル並列 / PMI PMBOK 7th / ISO 21500 / Cooper Stage-Gate / PRINCE2 / SAFe / ISO 31000 / FMEA / Bowtie / MLIT BIM/CIM lens) の §7.1-§7.3 改訂勧告を反映した v2.0。v1.0 (#2848) からの主要変更は §15「v1.0 → v2.0 主要変更」参照。

TL;DR (読了 90 秒)

• 4 Phase 構造: Phase 0 (Day -30〜-1 / 構想策定) + Phase 1 (Day 0-30 / BPR-only 先行) + Phase 2 (Day 31-60 / Parallel-tracks) + Phase 3 (Day 61-90 / Pilot 着手準備)。各 Phase 末に Gate (G0 / G1 / G2)。v2.0 で Phase 2 中盤 (Day 45) に G1.5 micro-gate を追加。
• WBS 行総数: 約 130-150 行 (Phase 0: 30-40 / Phase 1: 28-35 / Phase 2: 30-40 / Phase 3: 25-32)。
• 総工数見積 (BigQuery 実績データなし → 外部一次資料 [IPA / JUAS / JISA / 建設業 PMO] 根拠): 顧客 420-690 人日 / 弊社 320-530 人日 / Day 0-90 予算 ¥25-50M (売上比 1.0-1.5%)。
• 不可逆ポイント 5 件 (PoNR) + 戦術的 Go-decisions 7 件を Phase 0 で経営者・弊社署名で合意。後戻りコスト ¥50-200M / 公共案件改革ミスは指名停止 ¥1-3B 級。
• 3 つの Critical リスク: Sponsorship 不在 / 公共案件中の改革試行 / 現場代理人離反。月次 steering 会議で §6 早期警告 Top 7 を定型チェック。
• 取捨選択: 公共工事比率 30% 超は建設業 sub-論点 12 件全件・PoNR-4 / PoNR-5 最重要。10% 未満は規制 work-stream を改正電帳法・2024 年問題のみ強制。
• v2.0 改訂ハイライト (RQ-111 audit 反映): (1) Gate に 5-outcome rubric (Go / Conditional Go / Hold / Recycle / Kill) 明示、(2) §3.1 全体俯瞰に deliverable-based parallel view 追加、(3) §8 RACI を Customer-side 9×12 + External RAPID 7×12 に層化分割、(4) §10.1 リスク行列に Owner / Detection (FMEA) / RPN / Mitigation / Contingency 列追加、(5) §10.5 新設 Bowtie barrier mapping (Critical 3 件)、(6) §3.4 新設 MLIT BIM/CIM Information Container 命名規約統合 (ISO 19650 / BS1192)。

1. 使い方

1.1 対象案件 / 想定読者

• 対象案件: 売上 ¥10B 前後・従業員 150 名規模・本社 + 支店 + 複数現場・公共工事比率の影響を受ける企業
• 想定読者 (bizlp 内部): 弊社代表 / PM / 規制実務リード / PMO。顧客には A.03.4.1 (解説) と A.03.4.2 (記入用) を提示し、本ファイルは bizlp が WBS を設計するときの参照元として使う。

1.2 4 Phase 構造 (A.03.4.1 §3 ロードマップとの対応)

Phase 4 以降 (Day 91+ Pilot 実行 / Year 1-3 全社展開) は本テンプレート対象外。Phase 3 末で G2 を通過した案件のみ別途 WBS を設計する。

1.3 WBS# 採番ルール

形式: P{0-3}.S{1-8}.{seq}

• P0 〜 P3 = Phase 番号
• S1 〜 S8 = work-stream 番号 (Phase 内)
• .{seq} = 当該 stream 内の連番 (01, 02, ...)

例: P0.S2.01 = Phase 0 / work-stream 2 (PoNR 合意) / 連番 01。

1.4 工数記法

各 WBS 行の工数欄は 顧 X / 弊 Y [出典タグ] 形式。

出典タグ体系:

工数推定の確度ラベル:

• ◎ 一次根拠 (IPA / JUAS の数値で直接置換可能)
• ○ 類推 (汎用 IT 業界数値 + 建設業 PMO 補正)
• △ 専門家 judgment (BigQuery PM 実績なしのため)

詳細は §11 工数根拠。

8/80 rule (v2.0 追加 / PMI Practice Standard for WBS 準拠):

各 Task は 8 時間以上 80 時間以内の effort を目安とする。これより小さいなら親 Task に統合、これより大きいなら sub-task に分解する。例: 顧 12 / 弊 6 = 18 人日 ≒ 144h (8h × 18 = 18 人日換算で 1 人作業時の係数前提) の場合は Task 単位として大きすぎる → 2-3 sub-task に分解検討。1 人作業時間で 8h-80h を超える Task は §4-§7 各 Phase 表で sub-task 行に分解する。

1.5 取捨選択ガイド (キー判定軸)

2. 案件メタ情報 (記入欄)

3. WBS 全体俯瞰 (4 Phase × 主要 work-stream)

3.1 4 Phase × 主要 work-stream マトリクス (phase-based view)

Control Account 設計 (v2.0 追加 / ISO 21502 + 建設業 EV 慣行):

各 Stream を Control Account (scope × schedule × cost が integrate される管理単位) として運用。OBS (組織分解構造) との交点に Control Account を置くことで協力会社別の Earned Value 監視を可能にする。例: P2.S3 (ERP RFI) は Control Account 「ERP 選定 / 弊社 PMO + 経営企画」、P2.S5 (協力会社ヒアリング) は Control Account 「協力会社接続 / 弊社規制実務リード + 工事管理 + 上位 5-10 社」。各 Stream に CA-owner を指定し、月次 steering で報告。

3.1.1 4 Phase × deliverable-based parallel view (v2.0 追加 / PMI 推奨)

phase-based view (時間軸) を補完する deliverable-oriented decomposition。PMI PMBOK は WBS を deliverable-oriented にすることを推奨しており、Cross-phase に渡る主要 deliverable を別軸で俯瞰する。

各 deliverable に acceptance criteria を §4-§7 各 Phase 表の WBS Dictionary 注記列で明示する (v2.0 追加)。

3.2 主要 milestone 10 件タイムライン (v2.0: G1.5 追加)

3.3 推定総工数サマリ (Phase × 顧客 / 弊社)

出典: Phase 0 = [専門家 J] + [JUAS-24] (中堅 ERP 導入要件定義工数 / 体制人月) / Phase 1-3 = [JUAS-24] + [IPA-23] 類推 + [建設 PMO] 補正。詳細は §11。

3.4 MLIT BIM/CIM Information Container 命名規約統合 (v2.0 追加 / ISO 19650 / BS1192)

公共工事比率が高い顧客では、BPR/DX で生成される BIM/CIM 関連成果物 (3D モデル / 図面 / 設計書 / 出来高記録) を MLIT 推進 BIM/CIM ガイドラインに基づく Information Container 命名規約 (ISO 19650 / BS1192) と本テンプレの WBS coding 体系で同期させる。これにより Common Data Environment (CDE) 上で WBS 検索 → BIM/CIM 成果物の一意特定が可能になる。

Information Container 命名規約 (ISO 19650 標準): Project_Originator_Volume_Level_Type_Role_Number

運用ルール:

• Phase 0 で顧客側 BIM/CIM 担当者と本命名規約を合意 (P0.S3.04 BIM/CIM 原則化 規制対応計画と統合)
• Phase 2 to-be 設計 (P2.S1) 内で BIM/CIM 成果物の Information Container 名を発行
• Phase 3 パイロット to-be マニュアル (P3.S2) に BIM/CIM 成果物リストを Information Container 名で参照
• CDE は ISO 19650-2 に基づく Work-In-Progress / Shared / Published / Archived の 4 状態管理

取捨選択: 公共工事比率 30% 未満かつ BIM/CIM 原則化適用案件がない場合は本節 Skip 可。公共工事比率 30% 超または 2025 年以降の BIM/CIM 拡大対応案件は必須。

4. Phase 0 WBS (Day -30 〜 Day -1) — 構想策定

4.1 Phase 0 ゴール / DoD (Definition of Done)

• ゴール: A.03.4.2 「DX 構想合意書」(1-2 ページ・8 論点記入 + PoNR 5 件署名) を Day -1 までに完成・経営者と弊社代表 (+Optional 構想策定責任者) で署名。
• DoD: G0 Gate の 10 項目チェック (§4.4 参照) を全件通過。1 件でも未達なら Phase 1 開始延期 (構想策定 1 ヶ月延長)。

4.2 Phase 0 タスク表

行数: 26 行 (代表的タスクのみ列挙)。実際の案件では sub-論点 12 件の個別 sub-task や規制 7 領域の個別実装計画タスクを追加し 30-40 行に拡張する。

4.3 Phase 0 Go-decisions チェックリスト

DX 構想合意書 (A.03.4.2) に記入する以下 4 系統を Phase 0 末で確定:

• 戦術的 Go-decisions 7 件 (A.03.4.1 §4.1): BPR 最高責任者 / First-wave スコープ / BPR-then-system / 協力会社巻き込み / 公共凍結 / 成功 KPI 4 軸 / 撤退条件
• 不可逆 PoNR 5 件 (A.03.4.1 §4.2): 工事原価粒度 / 進捗度測定 / 接続方式 / 公共案件包含 / 経審 W 点コミット
• 成功 KPI 4 軸 (A.03.4.1 §4.1 #6): 工数削減 % / 月次決算日数 / 現場代理人事務時間 % / 経審 W 点維持
• 撤退条件 3 件 (A.03.4.1 §4.1 #7): Pilot +20% 悪化 / 監督員指摘 2 回以上 / 離職率 +50%

4.4 G0 Gate (Day -1) — Phase 0 → Phase 1 移行

判定基準 (v2.0: 5-outcome rubric / Cooper Stage-Gate 準拠):

判定責任者: 社長 + 弊社代表 + 管理本部長の 3 者合議 (1 名でも Kill / Recycle を主張する場合は要再協議)。判定根拠は G0 判定書 (P0.S8.05 成果物) に明記する。

5. Phase 1 WBS (Day 0 〜 Day 30) — BPR-only 先行

5.1 Phase 1 ゴール / DoD

• ゴール: 本社経理 + 1 現場パイロットの as-is 業務フロー図を Day 25 までに完成、規制 7 領域の詳細化を Day 14 までに完了、KPI baseline を Day 30 までに固定。
• DoD: G1 Gate (§5.3) の 5 件チェックを通過。

5.2 Phase 1 タスク表

行数: 16 行 (代表的タスクのみ列挙)。実際の案件では sub-論点 (規制 5 領域) の個別実装タスクを追加し 28-35 行に拡張する。

5.3 G1 First Go/No-Go Gate (Day 30)

判定基準 (v2.0: 5-outcome rubric / Cooper Stage-Gate 準拠):

判定責任者: 社長 + 弊社代表 + 管理本部長の 3 者合議。

6. Phase 2 WBS (Day 31 〜 Day 60) — Parallel-tracks 開始

6.1 Phase 2 ゴール / DoD

• ゴール: to-be プロセス設計 + Fit/Gap 分析を Day 50 までに完了。建設業 ERP 専業 3-5 社へ RFI 発行 → Day 60 までに 2-3 社絞り込み完了。協力会社上位 5-10 社ヒアリングと現場代理人合意取り付け完了。
• DoD: Mid-phase 監視 (Day 45) で ERP 候補絞り込み進捗 + 現場代理人合意進捗を確認。

6.2 Phase 2 タスク表

行数: 15 行 (代表的タスクのみ列挙)。実際の案件では sub-論点 6 件 (3-A〜3-F) の個別 to-be 設計タスクや規制 7 領域の個別実装タスクを追加し 30-40 行に拡張する。

6.3 G1.5 Mid-Phase 2 Micro-gate (Day 45 / v2.0 新設)

Cooper Stage-Gate frequency に合わせて Phase 2 中盤に micro-gate を追加。RQ-111 Claude 提案を採用。

判定基準 (5-outcome rubric):

判定責任者: 弊社代表 + 管理本部長 (社長は escalate only)。

7. Phase 3 WBS (Day 61 〜 Day 90) — Pilot 着手準備

7.1 Phase 3 ゴール / DoD

• ゴール: RFP 発行 → ベンダー 2 社絞り込み・契約交渉開始。パイロット to-be 業務マニュアル (ベテラン向け / 若手向け 2 版) と教育プログラム展開を Day 85 までに完了。Day 89 にリハーサル。Day 90 に Second Gate。
• DoD: G2 Gate (§7.3) の 4 件チェックを通過。

7.2 Phase 3 タスク表

行数: 11 行 (代表的タスクのみ列挙)。実際の案件では教育プログラムの sub-モジュール (BIM/CIM・CCUS・改正電帳法 等) や規制対応の最終チェック sub-task を追加し 25-32 行に拡張する。

7.3 G2 Second Go/No-Go Gate (Day 90)

判定基準 (v2.0: 5-outcome rubric / Cooper Stage-Gate 準拠):

判定責任者: 社長 + 弊社代表 + 管理本部長の 3 者合議 + Phase 4 予算追認 (経営者承認)。

7.4 Phase 3 → Phase 4 (Day 91+) への引き渡し条件

Phase 4 (Pilot 実行) は本テンプレート対象外。引き渡し時に確認:

• G2 4 件チェック全件通過
• 撤退条件 3 件への未抵触
• Phase 4 予算 (Day 91-180 / Pilot 実行 + 横展開準備) の経営者承認
• KPI 測定 schedule (Day 91 baseline / Day 121 / Day 151 / Day 181 で判定)

8. RACI / RAPID 責任分担表 (v2.0: 層化分割)

v2.0 改訂: RQ-111 audit を反映し、(a) single-A 原則を冒頭明文化、(b) Customer-side RACI 9×12 + External-coordination RAPID 7×12 に層化分割、(c) 建設業特有の「現場代理人 vs 本社」2 重 RACI 例を §8.3 に注記。

8.0 single-A 原則 (v2.0 明文化 / PMBOK / HBR "Who Has the D?" 準拠)

RACI / RAPID 運用の最重要規律 = single-A 原則 (1 タスクに Accountable は 1 名のみ)。複数 A は責任の希薄化 (diffusion of responsibility) を生み、決定遅延 / 押し付け合い / "toothless gate" の主因となる。R (Responsible / Perform) と C (Consulted / Input) は複数可。本テンプレの全 RACI / RAPID マトリクスは下記 sweep を Phase 0 末で実施し違反を排除する:

• 各行で A セルが 2 つ以上ある場合: 主担当 1 名に絞り残りを R か C に降格
• 各行で A セルが 0 個の場合: 単一責任者を 1 名指定 (空欄禁止)
• 該当 sweep 結果を G0 判定書 (P0.S8.05) に添付

8.1 役割定義 (16 ロール)

8.2-A Customer-side RACI マトリクス (顧客 9 ロール × 主要 12 タスク / v2.0)

• R = Responsible (実作業) / A = Accountable (単一・最終責任) / C = Consulted (双方向) / I = Informed (一方向通知)
• single-A 原則: 各行の A は単一セル (§8.0)

8.2-B External-coordination RAPID マトリクス (弊社 + 外部 7 ロール × 主要 12 タスク / v2.0)

外部協業ロール (PMO / ERP / 税理士 / 行政書士) は責任の流れが「Recommend → Decide → Perform → Input」の連鎖になるため、RACI より RAPID (BCG / Bain framework) の方が表現しやすい。

• R = Recommend (起案・推薦) / A = Agree (同意権・拒否権) / P = Perform (実行) / I = Input (情報提供) / D = Decide (最終決定)
• single-D 原則: 各行の D は単一セル

D (Decide) はほぼすべて顧客側 (C-S / C-AH) に置く設計 (上記表では D は省略・暗黙的に顧客側 §8.2-A の A セルが D を兼ねる)。例外: P0.S2.01-02 の不可逆 PoNR は規制実務 (E-TA: 税理士 / E-AG: 行政書士) が A を持つ (法定要件のため拒否権あり)。

8.3 建設業特有: 「現場代理人 vs 本社」2 重 RACI 例 (v2.0 注記)

建設業 PMO 実務では、現場代理人 (C-FS) と本社 (C-AH / C-CM) が同一タスクに対して 2 重 RACI を持つケースが頻発する。これを single-A 原則と整合させる方法:

判定基準: タスクの最終リスクオーナーが「現場固有リスク」か「全社統合リスク」かで A を切り分ける。両者にまたがる場合は分解して 2 タスク化する。

8.4 社長月 4 時間配分の内訳 (must_have #9 担保のための具体化)

9. 依存関係 DAG (mermaid)

9.1 Phase 間 critical path (高粒度)

flowchart LR
    P0_S1[8 論点合意
A.03.4.2 §3] --> P0_S2[PoNR 5 件署名]
    P0_S3[規制 7 領域 lock] --> P0_S2
    P0_S4[体制組成 / 社長 commit] --> G0{G0
Day -1}
    P0_S2 --> G0
    P0_S5[投資配分表] --> G0
    P0_S6[KPI + 撤退条件] --> G0
    P0_S7[公共工事凍結ルール] --> G0
    P0_S8[戦術 Go-dec 7] --> G0

    G0 --> P1[Phase 1 BPR-only]
    P1 --> G1{G1
Day 30}
    G1 --> P2[Phase 2 Parallel]
    P2 --> P3[Phase 3 Pilot 準備]
    P3 --> G2{G2
Day 90}
    G2 --> P4[Phase 4 Pilot 実行
Day 91+]

9.2 Phase 0 内 work-stream 依存

• S1 (8 論点) → S2 (PoNR)・S5 (投資配分)・S6 (KPI)・S8 (戦術 Go-dec)
• S3 (規制) → S2 (PoNR-3 接続方式)・S7 (公共工事凍結)
• S4 (体制) → G0 (Gate 判定)
• S1.04 (論点 7 投資配分) → S5
• S1.04 (論点 8 ガバナンス) → S6 + S4 (steering)

9.3 Phase 1-3 内 work-stream 依存

• P1.S2 (本社経理 as-is) + P1.S3 (1 現場 as-is) → G1 → P2.S1 (to-be 設計)
• P2.S1 → P2.S2 (Fit/Gap) → P2.S3 (RFI) → P3.S1 (RFP)
• P2.S4 (現場代理人合意) → P3.S2 (Pilot マニュアル) + P3.S3 (教育)
• P2.S6 (文化抵抗ヒアリング) → P3.S3 (役割再定義 + 分離教育)

9.4 PoNR 5 件と上流タスクのリンク

10. リスク行列

10.1 リスク source 統合表 (20 件 / v2.0: Owner + Detection + RPN + Mitigation + Contingency 列追加)

v2.0 改訂: FMEA (Failure Mode and Effects Analysis) の Detection 軸 (1-10 / 1 = 確実検出、10 = 検出困難) と RPN (Risk Priority Number = Sev × Occ × Det) を追加。RPN ≥ 100 はエスカレーション trigger。各 Risk に Owner + Mitigation (予防策) + Contingency (発生時対応) を明示 (ISO 31000:2018 / PMI PMBOK 準拠)。

RPN ≥ 100 = エスカレーション (即対応): R-01 (100) / R-05 (96 / Critical 扱い) / R-06 (105)。 RPN 50-99 = 重点監視 (月次 steering で個別確認): R-09 (80) / R-11 (60) / R-13 (60). RPN < 50 = 通常監視: 残り 14 件。

10.2 Severity × Likelihood 5x5 マトリクス

Critical 領域 (Sev 4-5 × Lik 3-4): R-01 / R-05 / R-06 → 月次 steering で必ず確認・致命的サイン出現時は即座介入。

10.3 月次 steering 会議 早期警告チェック票 (A.03.4.1 §6 早期警告 7 件 / v2.0: Risk Register 双方向リンク列追加)

開催日: ______________ / 出席者: ______________ / 該当 Phase: ______________

エスカレーション欄 (× が 1 件でもある場合): ______________

双方向リンク sweep (v2.0): 月次 steering で × が出た早期警告サインは、紐付け Risk# の Owner (§10.1) に即座エスカレーション。Risk# の Mitigation / Contingency を発火させる。逆に Risk# が新規に発火した場合 (例: R-13 ビッグバン発生) は、対応する早期警告サインが存在するか確認、存在しない場合は新規警告サインを §10.3 に追加検討。

10.4 撤退条件 3 件の発火閾値表

判定責任者は社長 or 経営企画役員に限定。死せる PJ 延命を防止。

10.5 Bowtie barrier mapping — Critical 3 件 (v2.0 新設 / IEC 31010 準拠)

Bowtie 分析は Threat → Top event → Consequence の流れに Preventive barriers (左側: Threat → Top event を防ぐ) と Mitigative barriers (右側: Top event → Consequence を軽減する) を配置する分析手法。RPN ≥ 96 の Critical 3 件 (R-01 / R-05 / R-06) に適用。

10.5.1 R-01 Sponsorship 不在 (RPN = 100)

[Threat 上流]                    [Top event 発生]            [Consequence 下流]
社長の関心減衰 ─→ 月次 BPR 5 分 ─→ 緩慢化 → 撤退判断不能 → 死せる PJ 延命
  ↑Preventive 1: P0.S4.02 月 4h commit 契約条文 (発生抑止)
  ↑Preventive 2: P0.S4.03 steering 月次 1-2h 固定
  ↑Preventive 3: P0.S1.04 論点 8 ガバナンス・KPI で行動指針 5 項目
                                       ↓Mitigative 1: 月次 steering で早期警告 #1 即チェック
                                       ↓Mitigative 2: 弊社代表が社長 1on1 緊急開催
                                       ↓Mitigative 3: G0 Recycle / Kill 発火

10.5.2 R-05 現場代理人・ベテラン離反 (RPN = 96)

[Threat 上流]                            [Top event 発生]          [Consequence 下流]
紙ハンコ慣行 + 「うちの現場は特殊」発言 ─→ 現場代理人非協力 ─→ Pilot 崩壊 → 紙運用回帰
  ↑Preventive 1: P1.S3.03 ヒアリング 10+ 件で早期検出
  ↑Preventive 2: P2.S6.02 役割再定義 (親方→データ管理者)
  ↑Preventive 3: P3.S3 ベテラン/若手分離教育プログラム
  ↑Preventive 4: P2.S4.01 合意取り付け (試行期間・フォールバック条件)
                                         ↓Mitigative 1: 現場代理人交代 (P3.S4.01 で準備済)
                                         ↓Mitigative 2: Pilot 現場入替え (P1.S4.02 candidate)
                                         ↓Mitigative 3: G2 Recycle (Phase 3 延長)

10.5.3 R-06 公共工事案件中の新フロー試行 → 指名停止 ¥1-3B (RPN = 105)

[Threat 上流]                                [Top event 発生]           [Consequence 下流]
「ついでに新フロー」発言 + 凍結ルール曖昧 ─→ 進行中案件に新フロー試行 ─→ 監督員指摘 → 指名停止 1-6ヶ月 → 経審 W 点減点 → 入札ランク低下 → ¥1-3B 機会損失
  ↑Preventive 1: P0.S7.01 凍結ルール明文化 (残工期 6ヶ月以下/完成検査済除外)
  ↑Preventive 2: P0.S7.02 発注者・監督員事前協議
  ↑Preventive 3: PoNR-4 経営者署名 (P0.S2.04)
  ↑Preventive 4: P3.S4.02 Pilot 適用前 最終事前協議
                                            ↓Mitigative 1: 該当案件 即除外 + 旧フロー復帰
                                            ↓Mitigative 2: 発注者陳謝 + 改善計画提出
                                            ↓Mitigative 3: 撤退条件 #2 発火 (監督員指摘 2 回) → PJ Kill
                                            ↓Mitigative 4: 弁護士・行政書士と指名停止対応

Bowtie 分析の運用 ルール:

• Critical 3 件 (RPN ≥ 96) のみ Bowtie 分析対象 (実装コスト過剰回避)
• Phase 0 末で各 Bowtie 図を経営者 + 弊社代表で確認・署名
• 月次 steering で Preventive barriers の機能状況を確認 (◎ 全件機能 / △ 部分機能 / × 機能不全)
• Top event 発生時は Mitigative barriers を順次発火 (上から順)
• 出典: IEC 31010:2019 §B.4.2 Bowtie analysis / IOGP Risk Assessment Data Directory

11. 工数根拠 (外部産業データ)

11.1 IPA ソフトウェア開発データ白書 2023 ([IPA-23])

• 要件定義工数比率: 全体の 10-15%
• 中規模 (1-5 億円) システム導入の要件定義期間平均: 60-90 日
• 適用箇所: P1.S2.02 / P1.S3.02 (as-is フロー図) / P2.S1.01 (to-be 設計) / P3.S2.01 (マニュアル)
• 確度: ◎ 一次根拠

11.2 IPA DX 動向 2025 ([IPA-DX-25])

• DX 推進企業の KPI 設計比率: 構想策定段階で 60% 以上が定量 KPI を設定
• 適用箇所: P0.S6.01 (KPI 設計) / P1.S5.01 (KPI baseline)
• 確度: ○ 類推

11.3 JUAS 企業 IT 動向調査 2024 ([JUAS-24])

• 中堅 (¥10B 規模) 製造業 ERP 導入予算中央値: ¥300-800M (建設業は同等)
• IT 投資比: 売上 1.0-1.5% (¥10B → ¥100-150M/年)
• 体制人月: 4-12 人月 / 月 (大手汎用)
• 適用箇所: P0.S2.01 (PoNR-1 工事原価粒度) / P0.S2.03 (PoNR-3 接続方式) / P0.S4.01 (体制組成) / P0.S5.01 (投資配分表) / P2.S3.03 (RFI 回答) / P3.S1.01-03 (RFP)
• 確度: ○ 類推

11.4 JISA 工数調査 2024 ([JISA-24])

• コンサル SE 単価: ¥1.5-2.5M / 人月
• PM SE 単価: ¥2.0-3.0M / 人月
• 適用箇所: §3.3 推定総工数サマリの予算換算
• 確度: ○ 類推

11.5 建設業 PMO 単価相場 ([建設 PMO])

• 戦略系コンサル: ¥1.8-3.0M / 人月
• 業務系コンサル: ¥1.2-2.0M / 人月
• 規制実務 (税理士 / 行政書士 / 社労士): 顧問契約 ¥0.2-0.5M/月 + スポット ¥50K/h
• 適用箇所: §3.3 予算計算 / P0.S3.02-04 (規制実務 3 専門家) / P0.S4.01 (外部 PMO)
• 確度: △ 専門家 judgment (一次資料公開なし・業界実勢)

11.6 経産省 DX レポート 2.2 ([METI-DX])

• 行動指針 5 項目: ビジョン駆動 / 価値重視 / オープンマインド / 継続的な挑戦 / 経営者中心
• steering 月次 1-2h レビュー推奨
• 適用箇所: P0.S4.03 (steering 体制) / P1.S1.02 (キックオフ steering) / P1.S6.05 (早期警告月次チェック)
• 確度: ◎ 一次根拠

11.7 専門家 judgment ([専門家 J])

BigQuery に bizlp 過去案件の PM 実績データなしのため、以下は専門家判断:

• P0.S1.01-04 (8 論点 WS) の工数
• P0.S2.04-05 (PoNR-4 / PoNR-5)
• P0.S7.01-02 (公共工事凍結ルール)
• P1.S3.03 (現場代理人ヒアリング)
• P2.S5.01 (協力会社ヒアリング)
• P3.S5.01 (リハーサル)

→ 将来 Phase 4 以降で実績データが蓄積された時点で本テンプレートに backfill する。

12. 取捨選択ガイド / Scaling

12.1 公共工事比率別

12.2 社員規模別

12.3 既存 ERP 老朽度別

12.4 社内 DX 人材有無別

12.5 sub-論点 12 件の出し入れ判定表

13. A.03.4.1 / A.03.4.2 への逆向きマッピング

13.1 A.03.4.1 §3 90 日ロードマップ → WBS Day 単位対応

13.2 A.03.4.1 §4.1 Go-decisions 7 → WBS マッピング

13.3 A.03.4.1 §4.2 PoNR 5 → WBS マッピング

13.4 A.03.4.1 §5 規制 7 領域 → P0.S3 + P1.S6 マッピング

13.5 A.03.4.1 §6 早期警告 7 → §10.3 月次チェック票

1-to-1 マッピング (§10.3 のチェック票で重複なく追跡)。

13.6 A.03.4.2 §3 8 論点記入欄 → Phase 0 タスクの対応

13.7 RQ-109 失敗 catalog 15 → リスク# 逆向きマッピング

§6 早期警告にない 8 件 (R-08〜R-15・R-19 / R-20) は §10.1 リスク行列に追加 + 対応 WBS タスクへ予防策をリンク済。

14. 用語 / 関連資料

14.1 用語

14.2 関連資料

• A.03.4.1 顧客向け BPR 進め方ガイド — 経営者向け 1 ページ briefing (§1-§8 解説)
• A.03.4.2 DX 構想合意書テンプレート — Phase 0 8 論点記入用 (本テンプレートの Phase 0 タスクから記入する)
• RQ-111 Synthesis — v2.0 改訂の根拠 (PMBOK / ISO 21500 / Cooper / RAPID / FMEA / Bowtie / MLIT BIM/CIM lens の 3 モデル合意)
• RQ-110 Synthesis — 8 論点 audit + Phasing マップ + 学術裏付け (Mintzberg / Kotter / Cohen-March-Olsen)
• RQ-109 Synthesis — 業界固有の失敗 catalog 15 件 + 推奨ポジション根拠
• IPA ソフトウェア開発データ白書 — [IPA-23] 出典
• JUAS 企業 IT 動向調査 — [JUAS-24] 出典
• 経産省 DX レポート 2.2 — [METI-DX] 行動指針 5 項目

15. v1.0 → v2.0 主要変更 (2026-06-26 / RQ-111 audit 反映)

15.1 必須採用 5 件 (3 モデル合意 3/3)

15.2 推奨採用 5 件 (3 モデル合意 2/3 以上)

15.3 検討採用 3 件 (1 モデル独自・実務性高)

15.4 変更しなかった指摘 (将来検討)

• WBS 階層を 4 階層に: 現状 3 階層 (P / S / seq) で 130-150 行は管理可能。4 階層化は実案件で必要と判明したときに sub-task 番号 (P{0-3}.S{1-8}.{seq}.{sub}) を local に追加する形で対応。
• PRINCE2 Project Board 体制への移行: steering 3 者 (社長 + 弊社代表 + 管理本部長) で十分機能している。Project Board (Executive / Senior User / Senior Supplier) 導入は overkill。
• SAFe PI Planning 導入: 90 日キックオフは waterfall 寄りの設計で、Agile スケール導入は Phase 4 以降の議論。

15.5 出典 / audit 経緯

本改訂は RQ-111 audit (2026-06-25 / 3 モデル並列 deep research) の §7.1-§7.3 に基づく。Audit lens: PMI PMBOK 7th / ISO 21500 / IPA PM / Cooper Stage-Gate / PRINCE2 / SAFe / ISO 31000 / FMEA / Bowtie / MLIT BIM/CIM。3 モデル (OpenAI o3-deep-research / Gemini deep-research-preview / Claude opus-4-7) の合意度マトリクスは RQ-111 synthesis §1 参照。