目次
システム刷新のプロジェクト計画書を書けと言われて、白紙から完成させられる情シス担当者はどれほどいるだろうか。JUAS「企業IT動向調査2026」によると、IT予算増加の理由で最も多いのが「既存システム・基盤の刷新・更新・増強」で66.3%を占めた（出典：JUAS 企業IT動向調査2026）。刷新の機運は高まっている。しかし、計画書が不十分なまま着手するプロジェクトが後を絶たない。
BCGの調査では、500人月以上の規模のシステム投資でQCDを計画どおり達成できた企業は2割を下回る（出典：BCG「2025年の崖 システム投資に失敗する理由」）。計画書の不備は、この失敗率と無関係ではない。
本記事では、システム刷新プロジェクト計画書に必要な全項目を解説する。各セクションの記載例も示すので、自社のプロジェクトに合わせてカスタマイズしてほしい。
システム刷新プロジェクト計画書の全体構成
まず、計画書の全体像を押さえておく。IPA「システム再構築を成功に導くユーザガイド 第2版」でも、計画書の構造化が成功の前提条件として挙げられている（出典：IPA「システム再構築を成功に導くユーザガイド 第2版」）。
計画書に含めるべき7つのセクション
システム刷新プロジェクト計画書は、以下の7セクションで構成する。
| セクション | 内容 | 想定ページ数 |
|---|---|---|
| 1. プロジェクト概要 | 背景・目的・期待効果 | 2〜3ページ |
| 2. スコープ定義 | 対象範囲・除外範囲・前提条件 | 2〜3ページ |
| 3. 体制 | 組織図・役割分担・意思決定フロー | 2ページ |
| 4. スケジュール | マスタスケジュール・WBS・マイルストーン | 3〜4ページ |
| 5. 予算 | 概算見積もり・費用内訳・承認プロセス | 2〜3ページ |
| 6. リスク管理 | リスク一覧・対応方針・エスカレーションルール | 2〜3ページ |
| 7. コミュニケーション計画 | 会議体設計・報告ルール・ドキュメント管理 | 1〜2ページ |
合計で15〜20ページ程度が標準的な分量だ。これより薄い計画書は、いずれかの項目が不足している可能性が高い。
以降、各セクションの書き方と記載例を順に解説していく。
システム刷新プロジェクト計画：プロジェクト概要の書き方
プロジェクト概要は、計画書の冒頭に配置する最重要セクションだ。経営層からの承認を取りつけるためにも、ここで「なぜやるのか」を明確に示す必要がある。
背景と目的
背景には、現行システムの課題を事実ベースで記載する。「古くなったから」では説明にならない。具体的な数値や事象を挙げて記述する。
記載例：
背景： 現行の販売管理システムは2012年に導入され、13年が経過している。保守ベンダーからは2027年3月でのサポート終了が通告済み。過去3年間で年間平均12件の障害が発生しており、1件あたりの平均復旧時間は4.2時間。年間のシステム停止による機会損失は推定約800万円に達する。
>
目的： サポート終了に伴うセキュリティリスクの排除、障害頻度の50%削減、月次決算の処理時間を現行の5営業日から3営業日に短縮する。
期待効果
期待効果は、定量的に記載することが鉄則だ。「業務効率化」「生産性向上」といった抽象的な表現では、投資判断の材料にならない。
| 効果項目 | 現状 | 目標 | 改善幅 |
|---|---|---|---|
| 障害件数（年間） | 12件 | 6件以下 | 50%削減 |
| 月次決算処理 | 5営業日 | 3営業日 | 40%短縮 |
| 手作業によるデータ入力 | 月40時間 | 月10時間 | 75%削減 |
| 保守運用コスト | 年間1,200万円 | 年間800万円 | 33%削減 |
システム刷新プロジェクトの失敗パターン5選と回避策でも指摘したとおり、上流工程の設計がプロジェクト全体の成否を左右する。計画書の段階で期待効果を数値化しておかなければ、後から「成功だったのか失敗だったのか」を判断できない。
着手金0円・完全後払い。まずはお見積り → SysDock（シスドック）
プロジェクト概要の記載には、現行システムの正確な把握が不可欠だ。SysDockは、AIマルチエージェントがソースコードからシステム構造を1週間で可視化する。Wordレポート+PowerPointスライド+React Flowフロー図の3点セット。30万円のライトから利用でき、ソースコード非送信で安心して依頼できる。
システム刷新プロジェクト計画：スコープ定義の書き方
スコープ定義は、プロジェクトの境界線を引くセクションだ。ここが曖昧だと、要件の肥大化（スコープクリープ）を招く。
対象範囲と除外範囲
「何をやるか」だけでなく「何をやらないか」を明記することがポイントになる。除外範囲を書かない計画書は、ステークホルダーの期待値がばらつく原因になる。
記載例：
対象範囲：
- 販売管理システム（受注・出荷・請求・入金管理）の全面刷新
- 現行データベースから新システムへのデータ移行
- 会計システムとのインターフェース再構築
>
除外範囲：
- 在庫管理システムの刷新（フェーズ2で対応予定）
- 基幹ネットワークの更改
- エンドユーザー端末の更新
前提条件と制約条件
前提条件は「これが満たされなければ計画が成立しない」という条件だ。制約条件は「この範囲内でやらなければならない」という制限を指す。
| 区分 | 内容 |
|---|---|
| 前提条件 | 現行システムのソースコードおよびDB定義書が入手可能であること |
| 前提条件 | 業務部門から要件ヒアリングに月20時間の協力が得られること |
| 制約条件 | 本番切り替えは2027年3月のサポート終了前に完了すること |
| 制約条件 | 総予算は経営会議で承認された5,000万円以内とすること |
スコープ管理については、Asanaのガイドでもプロジェクトの目標・成果物・タスクを計画段階で明確にすることの重要性が指摘されている（出典：Asana「スコープマネジメントとは？」）。計画書のこのセクションが曖昧な場合、プロジェクト中に必ず「これも対象に含まれるはずだ」という議論が発生する。
システム刷新プロジェクト計画：体制と役割の書き方
体制セクションでは、「誰が何を担い、誰が意思決定するのか」を明確にする。体制図が曖昧なプロジェクトは、意思決定の遅延と責任の曖昧さに苦しむことになる。
プロジェクト体制図の設計
刷新プロジェクトの体制は、最低でも以下の役割を定義する。
| 役割 | 担当 | 責任範囲 |
|---|---|---|
| プロジェクトオーナー | 取締役/部長クラス | 最終意思決定、予算承認、経営層への報告 |
| プロジェクトマネージャー | 情シス課長/主任 | 全体計画の策定・管理、ベンダー折衝、進捗管理 |
| 業務リーダー | 各業務部門の係長クラス | 要件定義への参加、UAT（受入テスト）の実施 |
| 技術リーダー | 情シスのエンジニア | アーキテクチャ設計レビュー、技術判断 |
| PMO | 情シスまたは外部支援 | 進捗・課題・リスクの管理、品質モニタリング |
意思決定フロー
計画書には、意思決定の階層を明記する。現場判断で済む範囲と、上位にエスカレーションすべき範囲の境界が必要だ。
記載例：
- PM判断： スケジュール1週間以内の調整、50万円未満の追加費用
- オーナー判断： スケジュール1か月以内の変更、500万円未満の追加費用
- 経営会議付議： マイルストーンの変更、500万円以上の追加費用、スコープの追加・削除
ベンダー選定の評価軸でも触れたとおり、発注側にPM機能が存在しないプロジェクトは高い確率で混乱する。「ベンダーに任せておけばいい」という姿勢は、失敗の入り口だ。
システム刷新プロジェクト計画：スケジュールの書き方
スケジュールセクションは、計画書の中核をなす。マスタスケジュールとWBS（作業分解構造図）の2階層で構成するのが実務上の定石である。
マスタスケジュールの設計
マスタスケジュールは、フェーズ単位で全体の流れを俯瞰するために使う。以下は典型的なシステム刷新のフェーズ構成だ。
| フェーズ | 期間（目安） | 主な成果物 |
|---|---|---|
| 現状分析 | 1〜2か月 | 現行システム調査報告書、課題一覧 |
| 要件定義 | 2〜3か月 | 要件定義書、RFP |
| ベンダー選定 | 1〜2か月 | 評価結果報告書、契約書 |
| 基本設計 | 2〜3か月 | 基本設計書、画面設計書 |
| 詳細設計・開発 | 3〜5か月 | 詳細設計書、プログラム |
| テスト | 2〜3か月 | テスト計画書、テスト結果報告書 |
| 移行・切替 | 1〜2か月 | 移行計画書、移行リハーサル結果 |
| 安定化運用 | 1〜2か月 | 運用手順書、障害対応記録 |
IPA「ソフトウェア開発分析データ集2022」のデータでは、要件定義と基本設計で全体工数の約4割を占める（出典：IPA ソフトウェア開発分析データ集2022）。上流工程に十分な期間を確保するスケジュール設計が不可欠だ。
WBSの作成方針
マスタスケジュールの下に、WBSで各フェーズのタスクを詳細化する。WBSのレベルは3階層を目安とする。
記載例（現状分析フェーズ）：
`
- 現状分析
1.1 現行システム調査
1.1.1 システム構成図の作成
1.1.2 機能一覧の整理
1.1.3 ソースコード構造の解析
1.1.4 データベース構造の調査
1.2 業務調査
1.2.1 業務フローのヒアリング（販売部門）
1.2.2 業務フローのヒアリング（経理部門）
1.2.3 現行業務フロー図の作成
1.3 課題整理
1.3.1 技術課題の洗い出し
1.3.2 業務課題の洗い出し
1.3.3 優先順位付けと報告書作成
`
マイルストーンの設定
マイルストーンは、プロジェクトの進捗を確認する「関所」だ。計画書では以下の粒度で設定する。
- 要件定義完了： ステークホルダーの承認を得た時点
- ベンダー契約締結： 開発着手の起点
- 基本設計レビュー完了： 後工程の前提となる設計の確定
- 総合テスト開始： テスト計画の実行開始
- 移行リハーサル完了： 本番切り替えの判断材料
- 本番稼働： プロジェクトのゴール
マイルストーンには「Go/No-Go判定」の基準を事前に定めておく。「なんとなく進める」ことを防ぐ仕組みだ。
システム刷新プロジェクト計画：予算の書き方
予算セクションでは、費用の内訳と承認プロセスを明示する。「一式いくら」では経営層を説得できない。
費用項目の分類
システム刷新の費用は、大きく以下の4カテゴリに分かれる。
| カテゴリ | 主な費用項目 | 概算比率 |
|---|---|---|
| コンサルティング・設計 | 現状分析、要件定義支援、PMO | 15〜20% |
| 開発・構築 | アプリケーション開発、インフラ構築 | 40〜50% |
| テスト・移行 | テスト実施、データ移行、並行稼働 | 15〜20% |
| その他 | ライセンス、教育・研修、予備費 | 15〜20% |
予備費の確保
予備費は総予算の10〜15%を確保することが推奨される。刷新プロジェクトでは、現行システムの調査段階で想定外の課題が発覚するケースが多い。予備費のないプロジェクトは、想定外の事態に予算面で対応できなくなる。
JUAS「企業IT動向調査2026」では、IT予算増加の要因として「円安・人件費高騰・ベンダー提供価格の値上げ等の影響」が46.6%に達している（出典：JUAS 企業IT動向調査2026）。外部環境の変動を踏まえ、予備費の比率は従来より多めに設定すべきだ。
記載例：
| 費用項目 | 金額（千円） | 備考 |
|---------|-------------|------|
| 現状分析・要件定義支援 | 8,000 | 外部コンサルタント |
| アプリケーション開発 | 22,000 | ベンダー委託 |
| インフラ構築 | 5,000 | クラウド初期設定含む |
| テスト・移行 | 7,000 | データ移行リハーサル2回 |
| ライセンス・教育 | 3,000 | ミドルウェア年間費用含む |
| 予備費（10%） | 5,000 | 経営会議承認が必要 |
| 合計 | 50,000 | |
着手金0円・完全後払い。まずはお見積り → SysDock（シスドック）
現状分析フェーズの費用を抑えたいなら、SysDockの活用を検討してほしい。ライト30万円から、AIが最短1週間でシステム構造を可視化する。ベンダーへの情報提供資料としても使えるWordレポートとPPTスライドを納品。完全後払いだから、予算計上後の発注にも柔軟に対応できる。
システム刷新プロジェクト計画：リスク管理の書き方
リスク管理セクションは、計画書の中で最も「書いておいてよかった」と実感する部分だ。問題が発生した際に「想定済み」か「想定外」かで、対応スピードが大きく変わる。
リスク一覧の作成
リスクは「発生確率」と「影響度」の2軸で評価する。計画書の段階では、代表的なリスクを10〜15項目洗い出しておく。
| リスク項目 | 発生確率 | 影響度 | 対応方針 |
|---|---|---|---|
| 現行システムの仕様が不明確 | 高 | 高 | 現状分析フェーズでソースコード解析を実施 |
| 要件定義の長期化 | 中 | 高 | MoSCoW法で優先順位を設定、フェーズ分割で対応 |
| キーパーソンの異動・退職 | 中 | 高 | ナレッジの文書化を早期に実施 |
| ベンダーの品質問題 | 低 | 高 | 中間レビューの頻度を上げ、品質基準を契約に明記 |
| データ移行時の不整合 | 高 | 中 | リハーサルを最低2回実施 |
| 予算超過 | 中 | 高 | 予備費10%を確保、月次で予実管理を実施 |
| テスト期間の圧縮 | 高 | 高 | テスト期間にバッファ2週間を設定 |
| 業務部門の協力が得られない | 中 | 中 | プロジェクトオーナーから各部門長へ協力を要請 |
失敗パターンの記事で解説したとおり、現行システムの理解不足と要件の肥大化が最も発生頻度の高いリスクだ。この2つは計画書の段階で必ず対策を記載しておくべきである。
エスカレーションルール
リスクが顕在化した際の報告ルートも計画書に含める。
記載例：
- レベル1（PM対応）： タスク単位の遅延（3日以内）。PMが対策を立案し、週次報告で共有。
- レベル2（オーナー報告）： マイルストーンへの影響が見込まれる場合。PMからオーナーへ24時間以内に報告。
- レベル3（経営会議付議）： 予算超過またはスケジュール1か月以上の遅延。オーナーから経営会議へ付議。
システム刷新プロジェクト計画：コミュニケーション計画の書き方
見落とされがちだが、コミュニケーション計画はプロジェクトの血流ともいえるセクションだ。情報の流れが滞ると、課題の発見が遅れ、意思決定が停滞する。
会議体の設計
計画書では、定例会議の種類・頻度・参加者を一覧にまとめる。
| 会議名 | 頻度 | 参加者 | 目的 |
|---|---|---|---|
| ステアリングコミッティ | 月1回 | オーナー、PM、各部門長 | プロジェクト方針の確認・意思決定 |
| 週次進捗会議 | 週1回 | PM、技術リーダー、業務リーダー | 進捗・課題・リスクの共有 |
| ベンダー定例 | 週1回 | PM、ベンダーPM、開発リーダー | 開発状況の確認、課題の解消 |
| 業務部門レビュー | 隔週 | PM、業務リーダー、エンドユーザー | 要件・設計の確認、フィードバック |
ドキュメント管理のルール
議事録・課題管理表・変更管理台帳の運用ルールも定めておく。共有フォルダの構造、ファイル命名規則、更新頻度を明記するだけで、情報の散逸を防げる。
プロジェクト計画書の品質を高める3つのチェックポイント
最後に、完成した計画書のセルフレビュー用チェックポイントを3つ示す。
チェック1：第三者が読んで理解できるか
計画書は、プロジェクトメンバーだけでなく経営層にも読まれる。専門用語には必ず補足説明を加え、略語の一覧を冒頭に設けるのが望ましい。
チェック2：数値で語れているか
「なるべく早く」「できるだけ削減」は計画書に書くべきではない。日付・金額・件数・時間で具体化する。数値化できない目標は、達成したかどうかを誰も判断できない。
チェック3：リスクと前提条件に漏れはないか
計画書のレビューでは、リスクと前提条件のセクションに重点を置く。「この前提が崩れたらどうなるか」をシミュレーションし、対応策が記載されているか確認する。
まとめ：計画書の精度がプロジェクトの成否を決める
システム刷新プロジェクト計画書は、7つのセクションで構成する。プロジェクト概要、スコープ定義、体制、スケジュール、予算、リスク管理、コミュニケーション計画。どれか一つでも欠ければ、プロジェクトの途中で必ずその穴が問題として顕在化する。
とりわけ重要なのは、計画書を書く前の「現状把握」だ。現行システムの構造・課題・技術的負債を正確に理解していなければ、スコープも予算もスケジュールも空論になる。失敗パターンの記事でも、現行システムの理解不足が失敗の最大要因であることを指摘した。
計画書は「完璧を目指す」のではなく、「判断の根拠になる精度」を目指す。プロジェクトの進行とともに更新し続けるリビングドキュメントとして運用してほしい。
着手金0円・完全後払い。まずはお見積り → SysDock（シスドック）
プロジェクト計画書の土台となる「現状把握」を、SysDockが支援する。AIマルチエージェントが13言語/FWに対応し、ソースコードからシステム構造・依存関係・技術的負債を1週間で可視化。Word+PPT+React Flowフロー図の3点セットで、非エンジニアの経営層にも伝わるレポートを納品する。ライト30万円、スタンダード50万円、プレミアム80万円。ソースコード非送信・完全後払いで安心して依頼できる。
お見積りはこちら → sysdock.genbacompass.com
よくある質問（FAQ）
Q. プロジェクト計画書はいつ作成すべきですか？
A. 刷新の検討が本格化した段階で着手する。経営会議での予算承認を得るには計画書が必要であり、承認後に作り始めるのでは遅い。概算レベルの計画書をまず作成し、承認後に詳細化する二段階方式が実務的だ。
Q. 計画書のレビューには誰を巻き込むべきですか？
A. 最低でも3者のレビューが必要だ。プロジェクトオーナー（投資判断の妥当性）、業務部門リーダー（スコープと要件の妥当性）、技術リーダー（スケジュールと技術方針の妥当性）。外部のPMOやコンサルタントに第三者レビューを依頼するのも有効である。
Q. 現行システムの設計書がない場合、現状分析はどう進めればよいですか？
A. ソースコードが残っていれば、構造解析で代替できる。AIを活用した解析ツールなら、数十万行規模のコードからでも依存関係マップやデータフロー図を自動生成できる。設計書の有無にかかわらず、ソースコードの実態を把握することが計画書の精度を高める。
現場改善に役立つ関連ツール
GenbaCompassでは、SysDock以外にも現場のDXを支援するツールを提供している。