導入プロジェクトのキックオフと WBS
レッスン4:導入プロジェクトのキックオフと WBS
このレッスンで学ぶこと
- キックオフミーティングの型(アジェンダ・参加者・成果物)を持てる
- WBS 主要 5 領域(データ移行・SSO 統合・トレーニング・並行運用・カットオーバー)を組み立てられる
- プロジェクト体制の階層と役割分担を持てる
- リスクマップの作り方を持ち帰れる
前レッスンでは PoC 設計と実施を扱いました。本レッスンでは、選定完了後の導入プロジェクトのキックオフと WBS を扱います。ここから買い手 PM のプロジェクトマネジメントスキルが本格的に問われます。3 か月〜 1 年の導入プロジェクトを、スケジュール・品質・コストの 3 制約の中で回す骨格を組み立てます。
キックオフミーティングの型
キックオフは、プロジェクトの全ステークホルダーが一同に会し、目的・体制・スケジュール・成功基準を共有する場です。
キックオフのアジェンダ(120 分想定)
- 10 分:オーナー挨拶(役員からプロジェクトの位置づけと期待)
- 20 分:プロジェクト概要(PM から目的・スコープ・成功基準)
- 20 分:体制説明(役割分担と連絡ルート)
- 30 分:スケジュール説明(マイルストーンと WBS 概要)
- 20 分:リスク・課題認識の共有
- 15 分:質疑応答
- 5 分:次回定例の案内と締め
キックオフの参加者
- プロジェクトオーナー(役員)
- 買い手 PM
- PMO
- IT 側リーダーとメンバー
- 業務側リーダーとキーユーザー
- SaaS ベンダー側 PM と主要メンバー
- SI パートナー側 PM(必要に応じて)
30〜 50 名規模のキックオフになることもあります。全員が「同じ絵を見た」状態を作ることが、その後のプロジェクトを支えます。
キックオフの成果物
- 議事録(決定事項・アクションアイテム)
- プロジェクトチャーター(プロジェクトの憲章として全ステークホルダーが合意した文書)
- スケジュール表・WBS
- 課題管理表・リスク管理表の初期版
WBS 主要 5 領域
WBS(Work Breakdown Structure:作業分解構造)は、プロジェクトの成果物を階層的に分解した図です。SaaS 導入プロジェクトの WBS は、次の 5 領域が主要な柱になります。
graph TD
A[SaaS 導入プロジェクト] --> B[領域1<br/>データ移行]
A --> C[領域2<br/>SSO 統合]
A --> D[領域3<br/>トレーニング]
A --> E[領域4<br/>並行運用]
A --> F[領域5<br/>カットオーバー]
領域 1:データ移行
- 既存データの棚卸し
- クレンジング(不要データの削除・重複排除)
- マッピング(既存データ項目と SaaS のデータ項目の対応付け)
- 移行スクリプト作成
- 移行テスト(複数回リハーサル)
領域 2:SSO 統合
- IdP(Entra ID・Okta・Google Workspace)との連携
- SCIM プロビジョニング設定
- 権限グループ設計
- テストユーザーでの動作確認
領域 3:トレーニング
- 役職別・部門別のトレーニング計画
- e ラーニング教材の作成
- 対面ハンズオン研修の実施
- ヘルプデスクの受け入れ準備
領域 4:並行運用
- 既存システムと SaaS の並行運用期間の設定
- 段階的な業務移行(部門別・機能別)
- 障害時のバックアッププラン
- 業務側の運用ルール策定
領域 5:カットオーバー
- 本番切替の判断基準
- 切替当日の作業手順書
- 切替後の初期対応体制
- 既存システムの停止・データバックアップ
プロジェクト体制の階層と役割分担
SaaS 導入プロジェクトの体制は、意思決定の階層と実行の階層に区分されます。
意思決定の階層(月次ステアリング委員会)
-
プロジェクトオーナー
-
経営企画部門長
-
IT 部門長
-
業務側部門長
-
買い手 PM
-
議題:進捗・課題・リスク・重要意思決定
-
頻度:月 1 回、60〜 90 分
実行の階層(週次プロジェクト定例)
-
買い手 PM
-
PMO
-
IT 側リーダー
-
業務側リーダー
-
SaaS ベンダー PM
-
SI パートナー PM
-
議題:週次の進捗・タスク・課題
-
頻度:週 1 回、60 分
領域別ワーキンググループ(隔週または随時)
- データ移行 WG
- SSO 統合 WG
- トレーニング WG
- 並行運用・カットオーバー WG
各 WG は 3〜 5 名の少人数で構成し、実務担当者が主導します。
リスクマップの作り方
SaaS 導入プロジェクトには、次のようなリスクが典型的に発生します。リスクマップで先手を打ちます。
リスクマップの構造
| リスク | 発生確率 | 影響度 | 対策 | 担当 | 期限 |
|---|---|---|---|---|---|
| データ移行スクリプトの遅延 | 中 | 高 | 早期プロトタイプ・複数リハーサル | IT 側 | 2 か月前 |
| 業務側キーユーザーの離職 | 低 | 高 | 副担当者の同時育成 | 業務側 | 常時 |
| SSO 統合の技術トラブル | 中 | 中 | ベンダーとの事前検証 | IT 側 | 3 か月前 |
| トレーニング参加率の低さ | 高 | 中 | オーナー通知・部門長経由の督促 | PMO | 1 か月前 |
| ベンダー側の体制変更 | 低 | 高 | 契約書での体制条項確認 | 買い手 PM | 契約時 |
リスク評価の 3 段階(発生確率)
- 低:発生確率 25 %未満
- 中:発生確率 25〜 75 %
- 高:発生確率 75 %以上
リスク評価の 3 段階(影響度)
- 低:スケジュール数日遅延、少額の追加コスト
- 中:スケジュール数週間遅延、中程度の追加コスト
- 高:プロジェクト中止級、大幅な追加コスト、レピュテーション棄損
高リスク(発生確率 × 影響度が高い)から順に対策を優先します。
講師の現場メモ
私が消費財メーカーで会計 SaaS への切替プロジェクトを回した時の話です。キックオフで 45 名を集めましたが、経理部門から「なぜ IT 部門主導なのか」との反発が出て、初日の空気が硬直しました。
急遽、経理部長にオーナー役として次回以降のステアリング委員会を主宰してもらう体制に変更し、「経理部門主導・IT 側支援」の構図で仕切り直しました。結果、経理部門のコミットメントが上がり、データ移行・並行運用も経理主導で進みました。
キックオフは「情報共有」の場だけでなく、「政治的な体制承認」の場でもあります。IT 側 PM は、業務側部門長を主役に立てることを意識することで、プロジェクトの推進力が変わります。
次のステップ
本レッスンでは導入プロジェクトのキックオフと WBS を扱いました。次のレッスンでは、WBS 5 領域の中でも最も工数と難易度が高いデータ移行と業務プロセス変更を扱い、実装の詳細を組み立てます。
確認クイズ
このレッスンで学んだ内容を確認しましょう。