プロジェクト計画書の書き方 目次テンプレートと項目別の記入例

プロジェクト計画書とは、「何を、いつまでに、だれが、どのように進めて完了とするか」を関係者全員で合意するための文書です。 目的・範囲・体制・日程だけでなく、会議や報告のルール、品質の目標、変更の受け付け方、完了の基準まで書いておくと、進行中に迷ったときの判断のよりどころになります。

この記事では、システム開発でそのまま使える章・節レベルの目次テンプレートを Markdown で載せ、全12章について架空の題材（社内図書の貸出管理システムの新規開発）での記入例と、「書く内容・書かない内容」の対比を示します。体制図とマイルストーンは Mermaid のコードで、会議体や品質目標などは表で書いています。

確認環境：Ubuntu 24.04 / @mermaid-js/mermaid-cli 12.0.0（Mermaid 12.1.0）と Chromium で、掲載した Mermaid のコード2点が描画できることを確認。日付の曜日と工数の合計は Python 3.11.15 で検算。

プロジェクト計画書の早見表

目次テンプレート（章・節レベル）

次の目次を、そのまま文書の骨組みとして使えます。かっこ内は、その節に書く内容の手がかりです。

# （プロジェクト名）プロジェクト計画書

- 版: 1.0
- 作成日: YYYY-MM-DD
- 作成者: （氏名）
- 承認者: （氏名）

## 1. プロジェクト概要
### 1.1 背景（なぜ今、取り組むのか）
### 1.2 目的（何のために行うのか）
### 1.3 ゴールと達成の基準（いつ、どうなっていれば達成か）

## 2. スコープ
### 2.1 対象範囲（機能・業務・利用者）
### 2.2 対象外（今回は行わないこと）
### 2.3 成果物一覧（名前・作成者・承認者・納期）

## 3. 前提条件と制約条件
### 3.1 前提条件（成り立つものとして計画に織り込むこと）
### 3.2 制約条件（変えられない条件）

## 4. 体制
### 4.1 体制図
### 4.2 役割と責任

## 5. スケジュール
### 5.1 マイルストーン
### 5.2 工程と期間

## 6. 進め方
### 6.1 工程ごとの作業と完了の基準
### 6.2 開発環境とツール

## 7. コミュニケーション計画
### 7.1 会議体
### 7.2 報告ルール
### 7.3 連絡手段と文書の保存場所

## 8. 品質計画
### 8.1 品質目標
### 8.2 レビューとテストの方針

## 9. リスク管理
### 9.1 リスク一覧
### 9.2 見直しの方法

## 10. 課題管理と変更管理
### 10.1 課題管理
### 10.2 変更管理の手順

## 11. 工数とコストの計画
### 11.1 工程別の工数
### 11.2 費用と予備

## 12. 完了基準
### 12.1 プロジェクトの完了基準
### 12.2 引き継ぎ

## 付録
### A. 用語
### B. 改訂履歴

項目別の記入例と「書く内容・書かない内容」

ここからは、12章それぞれの記入例です。題材は次の架空のプロジェクトです。

1. プロジェクト概要

記入例

• 背景：社内図書（約 2,400 冊）の貸出を紙の台帳で管理しており、返却の遅れに気づきにくい。貸出状況の問い合わせが総務部に月 60 件ほど寄せられている。
• 目的：貸出・返却・予約をシステムで扱えるようにし、利用者が自分で貸出状況を確認できるようにする。
• ゴールと達成の基準：

2. スコープ

記入例

成果物一覧：

3. 前提条件と制約条件

前提条件は「成り立つものとして計画に織り込んだこと」、制約条件は「変えられない条件」です。 前提が崩れたときに計画を見直す根拠になるので、崩れた場合の影響も書いておきます。

記入例

4. 体制

記入例

体制図（Mermaid）です。

flowchart TD
    OWN["依頼元の責任者<br>総務部 部長 山本"]
    WIN["依頼元の窓口<br>総務部 中村"]
    PM["プロジェクトマネージャー<br>佐藤"]
    DL["開発リーダー<br>鈴木"]
    DEV["開発担当<br>高橋・伊藤"]
    QA["テスト担当<br>渡辺"]
    INF["環境・移行担当<br>田中"]

    OWN --- WIN
    OWN --> PM
    WIN <--> PM
    PM --> DL
    PM --> QA
    PM --> INF
    DL --> DEV

役割と責任：

5. スケジュール

記入例

工程と期間（Mermaid のガントチャート）です。

gantt
    title 社内図書の貸出管理システム 工程表
    dateFormat YYYY-MM-DD
    axisFormat %m/%d
    excludes weekends

    section 要件・設計
    要件定義           :req, 2026-11-02, 2026-11-27
    要件定義の完了     :milestone, m1, 2026-11-27, 0d
    基本設計           :bd, 2026-11-30, 2026-12-25
    基本設計の完了     :milestone, m2, 2026-12-25, 0d

    section 実装
    詳細設計と実装     :impl, 2027-01-05, 2027-02-12
    実装の完了         :milestone, m3, 2027-02-12, 0d

    section テスト
    結合テスト         :it, 2027-02-15, 2027-02-26
    受け入れテスト     :uat, 2027-03-01, 2027-03-12
    受け入れテストの完了 :milestone, m4, 2027-03-12, 0d

    section 移行・リリース
    データ移行の試行   :mig, 2027-02-15, 2027-03-05
    リリース準備       :rel, 2027-03-15, 2027-03-18
    リリース           :milestone, m5, 2027-03-19, 0d
    利用開始後の見守り :care, 2027-03-22, 2027-03-31

6. 進め方

記入例

進め方：要件定義から受け入れテストまでを順に進める。実装は2週間ごとに区切り、区切りごとに動く画面を依頼元の窓口に見せて意見をもらう。

開発環境とツール：

7. コミュニケーション計画

記入例

会議体：

報告ルール：

連絡手段と文書の保存場所：

8. 品質計画

品質目標は、数字と確かめ方をセットで書きます。 数字は、組織の基準や過去のデータがあればそれに合わせ、無ければ関係者で合意した値を書きます。

記入例

不具合の重要度：

9. リスク管理

記入例

見直しの方法：週次定例でリスク一覧を確認し、起こりやすさと影響を更新する。新しいリスクは気づいた人が一覧に追加する。

10. 課題管理と変更管理

変更管理は、依頼元と開発側の双方を守る仕組みです。 「だれが受け付け、だれが影響を調べ、だれが決めるか」を書いておくと、要望を前向きに受け止めながら、日程と品質を保てます。

記入例

課題管理：課題は気づいた人が課題管理ツールに登録する。項目は「内容・起票日・担当・期限・状態・対応の経過」とする。週次定例で期限の近いものと期限を過ぎたものを確認する。2週間以上進展が無い課題は、運営会議に諮る。

変更管理の手順：

変更を判断する人の基準：

11. 工数とコストの計画

記入例

• 予備：3.0 人月（合計の 10%）。使う場合はプロジェクトマネージャーが理由を記録し、月次の報告に載せる。
• 工数以外の費用：テスト環境の利用料（5か月分）、利用者向け説明会の会場と資料。金額は見積書に記載する。
• 工数の把握：各担当が作業時間を日ごとに記録し、週次で予定と実際を比べる。差が 10% を超えた工程は、週次定例で理由と見通しを報告する。

12. 完了基準

完了基準は、「これが満たされたらプロジェクトを終える」という条件です。 計画の時点で合意しておくと、終盤に「まだ終わっていない」「もう終わった」と認識が分かれることを防げます。

記入例

引き継ぎ：利用開始後 2027-03-31 までは開発側が問い合わせに対応する。2027-04-01 以降は、総務部の管理者が一次の窓口となり、情報システムの担当が保守を行う。引き継ぐ文書は、設計書、手順書、未解決の課題の一覧、環境の構成の資料とする。

規模別：省略できる章の早見表

計画書の厚さは、規模に合わせて変えます。 小さなプロジェクトで12章すべてを詳しく書くと、作ることが目的になりがちです。次の表を目安に、章を簡略にするか、他の章にまとめます。

規模の目安は、小＝3名以下・3か月以内、中＝4〜10名・3〜6か月、大＝11名以上・6か月超または複数のチーム、です。

表計算ソフトに貼れるタブ区切りです。

章   小   中   大
1. プロジェクト概要 必須  必須  必須
2. スコープ 必須  必須  必須
3. 前提条件と制約条件    必須  必須  必須
4. 体制   簡略可 必須  必須
5. スケジュール   必須  必須  必須
6. 進め方  簡略可 必須  必須
7. コミュニケーション計画  簡略可 必須  必須
8. 品質計画 簡略可 必須  必須
9. リスク管理    簡略可 必須  必須
10. 課題管理と変更管理   簡略可 必須  必須
11. 工数とコストの計画   簡略可 必須  必須
12. 完了基準    必須  必須  必須
付録  省略可 必須  必須

どの規模でも省かないのは、概要・スコープ・前提と制約・スケジュール・完了基準の5つです。この5つがあれば、「何を、いつまでに、どの条件で、どうなったら終わりか」を合意できます。小規模なら、A4 で2〜3ページに収まります。

提出前の確認項目30個

提出やレビューの前に、次の30項目を確認します。

表計算ソフトで確認欄を足して使えるよう、CSV も載せます。

No,分類,確認項目,確認結果
1,全体,表紙に版・作成日・作成者・承認者が書かれている,
2,全体,改訂履歴に変更した日・箇所・理由が書かれている,
3,全体,用語や略語が初めて出る箇所か付録で説明されている,
4,全体,他の文書を参照する箇所に文書名と版が書かれている,
5,概要,背景に取り組む理由を示す数字がある,
6,概要,目的とゴールが分けて書かれている,
7,概要,ゴールごとに達成の基準と確認する時期がある,
8,スコープ,対象外が具体的な名前で書かれている,
9,スコープ,成果物ごとに作成者・承認者・納期がある,
10,スコープ,開発以外の作業を含むかどうかが書かれている,
11,前提と制約,前提条件に相手に守ってほしい期限や日付がある,
12,前提と制約,前提が崩れた場合の影響が書かれている,
13,前提と制約,制約条件に日程・工数・技術・規程の動かせない条件が挙がっている,
14,体制,依頼元の責任者と窓口が書かれている,
15,体制,役割ごとに責任と決められることが書かれている,
16,体制,兼務の割合や参加する期間が限られる人が分かる,
17,スケジュール,マイルストーンに日付と判定する人がある,
18,スケジュール,休日や長期の休みが日程に反映されている,
19,スケジュール,依頼元の作業の期間が入っている,
20,進め方,工程ごとに完了の基準が書かれている,
21,コミュニケーション,会議ごとに目的・頻度・出席・記録の担当がある,
22,コミュニケーション,報告のだれから・だれへ・いつ・何をが書かれている,
23,コミュニケーション,遅れや重大な問題が起きたときの連絡の経路と期限がある,
24,品質,品質目標が数字で書かれ確かめ方と時期がある,
25,品質,不具合の重要度の基準とリリース判定での扱いがある,
26,リスク,リスクごとに予防策・起きたときの対応・担当がある,
27,変更管理,変更の受け付け窓口・影響の調査・判断する人の基準がある,
28,工数とコスト,工程別の工数の合計が合っており予備の量と使い方が書かれている,
29,完了基準,完了基準ごとに確かめ方と判定する人がある,
30,完了基準,未解決の課題の扱いと引き継ぎ先が書かれている,

計画書を作る順番と、更新のしかた

計画書は、1章から順に書くより、決まりやすいものから埋めて、関係者と確認しながら仕上げるほうが早く進みます。

承認の後も、計画書は更新していきます。範囲・日程・体制・工数が変わったときは、10章の変更管理の手順で判断したうえで該当する章を直し、改訂履歴に「日付・箇所・理由・承認者」を残します。リスク一覧や課題の一覧のように毎週変わるものは、計画書の本体から切り離して別の表で管理し、計画書には「どこにあり、いつ見直すか」だけを書いておくと、版の更新が少なくて済みます。

よくある質問

Q. プロジェクト計画書は何ページくらいが適切ですか？ A. 規模によります。3名以下・3か月以内の小規模なら A4 で2〜3ページ、中規模で10〜20ページが目安です。ページ数よりも、概要・スコープ・前提と制約・スケジュール・完了基準の5つが合意できる内容になっているかを確かめます。

Q. 要件が固まっていない段階でも、計画書は書けますか？ A. 書けます。決まっていない点は3章の前提条件に「現時点の想定」として書き、要件定義の完了時に計画を見直すことを5章のマイルストーンに入れます。計画書は一度書いて終わりではなく、分かったことを反映して版を上げていく文書です。

Q. 提案書やプロジェクト憲章とは、どう違いますか？ A. 提案書は「この内容で任せてほしい」と示す文書、プロジェクト憲章は「このプロジェクトを立ち上げる」と認める文書で、どちらも開始前の合意が中心です。計画書は、開始が決まった後に「どう進めるか」を具体的に定める文書で、会議・報告・品質・変更の扱い・完了基準まで踏み込みます。

Q. アジャイル開発でも計画書は必要ですか？ A. 必要な章が変わります。目的・ゴール、体制、会議と報告、品質の考え方、完了の条件は、進め方にかかわらず合意しておくと役に立ちます。機能の細かい範囲と日程は固定せず、「優先順位の決め方」と「区切りごとの見直しの方法」を書く形にします。

まとめ

• プロジェクト計画書は、「何を、いつまでに、だれが、どう進めて完了とするか」を合意する文書。12章の目次テンプレートを骨組みにする。
• 各章は、数字・日付・担当で判定できる形に書く。「適宜」「必要に応じて」は、頻度や条件に置き換える。
• 対象外、前提が崩れた場合の影響、役割ごとの決められることは、後の行き違いを減らす要点になる。
• 会議体と報告ルールは「だれから・だれへ・いつ・何を」の表に、品質目標は確かめ方と時期をそろえた表にする。
• 変更管理は、受け付け・影響の調査・判断する人の基準を決めておく。
• 完了基準は計画の時点で合意し、未解決の課題の扱いと引き継ぎ先まで書く。
• 規模に合わせて章を簡略にし、概要・スコープ・前提と制約・スケジュール・完了基準の5つは省かない。提出前に30項目で確認する。

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。