プロジェクト計画書の書き方：システム開発で書く項目とテンプレート、発注者と受託側の分担

プロジェクト計画書は、システム開発に着手する前に「何のために、どこまでを、誰が、いつまでに、どんなルールで進めるか」を1冊にまとめ、発注者と受託側が合意するための文書です。この記事では、デジタル庁の標準ガイドラインが定める記載事項を下敷きに、システム開発のプロジェクト計画書に書く項目、そのまま使える目次テンプレートと記入例を示します。あわせて、発注者と受託側のどちらがどの章を書くか、契約形態によって書き手がどう変わるか、いつ更新するかまで整理しました。

まとめ：プロジェクト計画書は目的・範囲・体制・日程・リスクを発注前に合意する文書

プロジェクト計画書の中身は、大きく2層に分かれます。1層目は目的・スコープ・体制・スケジュール・予算といった「何をするか」。2層目は会議体・進捗報告・課題とリスクの扱い・変更手続きといった「どう管理するか」です。デジタル庁の DS-100 は前者を計画書、後者をプロジェクト管理要領として別の文書に分けています。

システム開発を外注する場合、目的・成功指標・対象業務の範囲・予算・社内の体制は発注者にしか書けません。工程の分割、作業の見積り、品質の測り方は受託側が書きます。発注者が自社の章を空欄のまま受託側に任せると、後の仕様変更や追加費用の協議で判断の拠り所がなくなります。

計画書は一度で完成させる文書ではありません。構想段階で素案を作り、要件定義の後と運用開始の前に書き足す前提で始めてください。社内数名で数か月の小規模案件なら、A4で3〜5枚の簡易版で足ります。

プロジェクト計画書とは：要件定義書・WBS・企画書との違いと作成する時期

デジタル庁の標準ガイドラインが定めるプロジェクト計画書の位置付け

政府情報システムの整備ルールであるDS-100 デジタル・ガバメント推進標準ガイドライン（2026年6月12日 デジタル社会推進会議幹事会決定）は、第3編第2章で「プロジェクトの実行に先立ち、プロジェクト計画書及びプロジェクト管理要領を作成する」と定めています。計画書の役割は、ライフサイクルを通じて達成すべき成果を明確にし、各工程の意思決定や関係者との合意で指針として参照することだとされています。

民間のシステム開発にこの規程が適用されるわけではありません。それでも、記載事項が条文の形で列挙されている公開資料は少なく、項目の抜け漏れを点検する基準として使えます。最新版はデジタル社会推進標準ガイドラインの一覧ページで確認できます。

システム企画書・要件定義書・WBS・RFPと比べた役割の違い

プロジェクト計画書と混同されやすい文書は4つあります。違いは「何を決める文書か」と「誰が読むか」で見分けられます。

企画書で投資の可否が決まった後に計画書を書き、計画書のスケジュール欄を作業単位まで分解したものがWBSになります。企画書の項目はシステム企画の構想と計画の2段階で決める範囲、要件の書き方は要件定義書の章立てサンプルと記載項目、作業の分解はWBSの作り方5ステップとシステム開発の例で扱っています。

計画書とプロジェクト管理要領を2冊に分ける理由と1冊で済ませる場合

DS-100 は「何をするか」を計画書に、「どう管理するか」をプロジェクト管理要領に書き分けます。管理要領の記載事項は、ステークホルダー管理・コミュニケーション管理・工程管理・指標管理・リスク管理・課題管理・変更管理・品質管理・記録管理の9つです。

分ける理由は更新の頻度が違うためです。目的や予算は経営判断でしか変わりませんが、会議体や報告様式は工程ごとに見直します。民間の中規模案件でも、計画書本体と管理ルールの章を分けておくと、ルールの改訂のたびに計画書全体の承認を取り直す手間が省けます。小規模案件では1冊にまとめ、管理ルールを後半の章に置けば十分です。

システム開発のプロジェクト計画書に書く項目：目的・スコープから会議体と変更管理まで

DS-100 の計画書の記載事項は、政策目的・対象業務範囲・対象システム・目標とモニタリング・前提条件と制約条件・実施計画・予算・体制の8項目です。民間のシステム開発向けに読み替え、管理要領のうち計画段階で決めておくべき項目を加えると、次のとおりになります。

目的と成功指標：業務上の数値と達成時期まで書く目標欄の記入方法

目的欄には「受発注システムを刷新する」ではなく、刷新で解消したい業務上の問題を書きます。成功指標は、DS-100 が「具体的な指標及びその達成目標年度等」で記載するよう求めているとおり、数値と時期をセットにします。

例として「受注入力1件あたりの処理時間を8分から3分にする（稼働後6か月時点）」「月末締めの残業を月40時間から10時間にする（2027年度）」のように書くと、受入テストや稼働後の評価で使える基準になります。計測方法と計測する人も同じ欄に書いてください。

スコープ：対象業務・対象システム・対象外を明記する範囲の書き方

スコープは、対象業務、対象システム（新設・改修・連携先）、対象外の3点で書きます。最も効くのは対象外の明記です。「既存の会計システムは改修しない。連携はCSV出力まで」「スマートフォン対応は第2期」と書いておくと、開発中に出た要望を追加案件として切り分ける根拠になります。対象外を書かずに進めた案件で要件が少しずつ増えていく現象と、その防ぎ方はスコープクリープとは：原因と防ぎ方、要件追加を変更管理と追加見積で扱う契約の要点で解説しています。

成果物も範囲の一部です。納品するドキュメントの種類（要件定義書・基本設計書・テスト仕様書・操作マニュアル）と、ソースコードの引き渡し有無をこの欄で決めておきます。

体制と役割：発注者・受託側・利用部門の責任者を名前で書く体制図

体制欄には、組織図ではなく「判断する人」を名前で書きます。最低限必要なのは、発注側のプロジェクト責任者（予算と仕様を最終決定する人）、発注側の窓口担当、利用部門の代表者、受託側のプロジェクトマネージャーの4者です。体制図の線の引き方と役割分担表の作り方は、体制図の書き方：システム開発の体制図と役割分担表、発注者・PMO・ベンダーの報告線で扱っています。

DS-100 は体制準備の段階で、情報システム部門だけでなく制度所管部門と業務実施部門を参画させるよう求めています。民間でも、情報システム部門だけで計画書を書くと、利用部門の業務ルールが要件に反映されないまま開発に進む原因になります。

スケジュールとマイルストーン：工程ごとの承認日を置く日程表の書き方

計画書のスケジュールは、工程単位（要件定義・設計・開発・テスト・移行・稼働）の期間と、工程の区切りで行う承認日を示す粒度で足ります。作業単位の日程はWBSに任せます。

見落としやすいのは発注者側の作業です。要件の確認、テストデータの準備、受入テスト、利用者への説明会は発注者が行う作業で、ここが遅れると全体が遅れます。受託側の工程と同じ表に、発注者の作業と期日を並べて書いてください。

予算と前提条件・制約条件：見積の根拠を計画書に残す書き方と費用の内訳

予算欄には総額だけでなく、開発費・ライセンス費・クラウド利用料・保守費を分けて書きます。DS-100 も、必要となる全ての経費項目を洗い出して金額を見積もるよう定めています。

前提条件と制約条件は、見積がどの前提で成り立っているかの記録です。「画面数は40画面程度」「既存データの移行は3年分」「稼働日は2027年4月1日で動かせない」のように書いておくと、前提が崩れたときに見積を見直す話を始めやすくなります。

リスク・課題・変更管理：報告先と判断者を先に決める管理ルール

リスク欄には、想定されるリスクを影響度と発生可能性で並べ、それぞれの対応策と担当者を書きます。「キーパーソンの異動」「連携先システムの仕様変更」「データ移行の品質」は、業務システム開発で繰り返し挙がる項目です。

変更管理は、仕様変更を誰が受け付け、誰が影響（費用・日程）を見積もり、誰が承認するかの手順です。承認者と金額の閾値（例：50万円未満は窓口担当、以上は責任者）まで決めておくと、口頭の追加依頼が積み重なる事態を防げます。

コミュニケーション計画：会議体・頻度・議事録の承認期限の決め方

会議体は、目的ごとに参加者と頻度を分けて書きます。週次の定例（窓口担当と受託側PM）、月次のステアリングコミッティ（責任者が出席し、課題と変更を判断する場）、工程完了時のレビュー会の3種類が基本形です。

議事録は「誰が作り、何営業日以内に誰が承認するか」まで書きます。合意事項が議事録に残っていないと、後で言った言わないの争いになるためです。連絡手段（チャット・メール・課題管理ツール）の使い分けもこの章に置きます。会議体をキックオフで合意する進め方はキックオフミーティングの議題と決めることで解説しています。

プロジェクト計画書のテンプレート：12章の目次例と素案を書く順番、受発注システムの記入例

そのまま使えるプロジェクト計画書の目次テンプレートと12章の構成

システム開発のプロジェクト計画書は、次の12章で組むと前述の項目を過不足なく収められます。

1. プロジェクトの背景と目的
2. 成功指標と計測方法
3. スコープ（対象業務・対象システム・対象外）
4. 成果物一覧
5. 前提条件と制約条件
6. 体制と役割分担
7. スケジュールとマイルストーン
8. 予算
9. リスクと対応策
10. 会議体とコミュニケーション
11. 課題管理と変更管理の手順
12. 品質管理と文書・記録の管理

1〜8章が計画書本体、9〜12章が管理ルールにあたります。中規模以上の案件では9〜12章を別冊のプロジェクト管理要領に切り出します。表紙には版数・改定日・承認者の欄を設け、改定履歴を最終ページに付けてください。

素案を書く順番：目的・スコープ・体制・日程・リスクの5段階の進め方

12章を頭から埋めると、前の章の決定が後の章を縛るため手戻りが出ます。素案は次の順で書くと速く進みます。

1. 目的と成功指標を決め、決裁者の了承を取る
2. 対象業務と対象外を書き、利用部門と範囲を確認する
3. 判断する人を名前で決め、体制を固める
4. 稼働日から逆算して工程と承認日を置く
5. 前提条件とリスクを洗い出し、予算に反映する

1と2は発注者だけで書けます。3以降は受託側の見積や工程案が必要になるため、ベンダー選定後に受託側と一緒に詰めます。

記入例：受発注システム刷新を想定した目的・スコープ欄の書き方

従業員80名の卸売業が、FAXと表計算で回している受発注を刷新する場合の記入例です。

対象外の欄に「取引先向けアプリ」と書いた時点で、開発中に出た「取引先にもスマートフォンで発注してほしい」という要望は第2期の検討事項として扱えます。目的と指標が具体的であるほど、追加要望を本当に今入れるべきかを判断しやすくなります。

発注者と受託側で分けるプロジェクト計画書の分担、準委任と請負で変わる書き手

発注者が書く章と受託側が書く章の線引き、双方の責任者による承認の決め方

計画書は受託側が作って発注者が承認する、という分担で進めがちです。ただ、目的や予算の章を受託側が推測で埋めると、計画書の判断基準が発注者の実情とずれます。章ごとの書き手は次のように分けます。

品質管理・テスト方針の章を別冊のテスト計画書として起こすときの記載項目と終了基準は、テスト計画書とは？書き方と記載項目、テスト仕様書との違いと終了基準の決め方で解説しています。

発注者側に計画書を書く人手や経験がない場合は、発注者の立場で計画書と管理ルールを組み立てる外部支援を入れる選択肢があります。一創の要件定義・RFP作成・PMO支援では、受託ベンダーとは別の立場で計画書の目的・範囲・体制の章をまとめ、ベンダーの工程案の妥当性を確認する形で関わります。

準委任の要件定義と請負の開発で計画書の書き手が変わる理由と民法の規定

契約形態は、計画書で誰がどこまで責任を持つかを決める基準です。民法632条の請負は「仕事の完成」を約束する契約で、受託側が工程と成果物に責任を負います。656条の準委任は事務の遂行を委託する契約で、完成の約束はなく、判断と決定は発注者に残ります。

このため、要件定義を準委任で発注するなら、要件定義工程の計画（何をいつまでに決めるか、誰が決めるか）を主導して書くのは発注者です。設計以降を請負で発注する場合は、受託側が工程と成果物の計画を書き、発注者が書き足すのは受入基準と自社の作業です。RFPの段階でこの分担を示しておくと、提案される計画書の粒度がそろいます。RFPの記載項目はRFPの意味と記載項目、目次テンプレートで整理しています。

プロジェクトマネジメント義務と協力義務：計画書に残す発注者の作業

システム開発の紛争では、受託側のプロジェクトマネジメント義務と、発注者の協力義務がしばしば争点になります。IPAが2020年12月22日に公開した情報システム・モデル取引・契約書（第二版）の見直しのポイントによると、これらの義務は個別事案の判断であるため条項としての追記は見送られ、代わりにユーザとベンダの役割分担とプロジェクトマネジメントに関する記述が見直されました。ベンダの中止提言を踏まえた解約権も、オプション条項として追加されています。

契約書に義務が細かく書かれない以上、発注者が何をいつまでに行うかを具体的に残せる場所は計画書です。要件の確定期限、テストデータの提供日、受入テストの担当者と期間を、体制とスケジュールの章に書いておいてください。

プロジェクト計画書を更新する時期と、作ったまま使われなくなる失敗パターン

構想・ベンダー選定後・要件定義の完了時・稼働前の4時点で書き足す内容

DS-100 は、計画書を着手時点ですべて具体化するのは困難だとして、構想段階、当初計画段階、調達及び設計・開発開始前、運用及び保守開始前、運営段階、サブプロジェクトの組成時、工程完了時の7つの時期を改定の目安に挙げています。民間のシステム開発では、次の4時点に絞ると運用できます。

各時点の改定では、版数を上げて承認者の確認を取り直します。改定しなかった時点があっても、工程の区切りで「変更なし」と記録しておけば、計画書が生きていることを関係者に示せます。

作ったまま更新されない計画書になる失敗パターンと、変更承認時の書き換えルール

最も多いのは、受注直後に受託側がひな形で計画書を作り、承認後に誰も開かなくなるパターンです。目的と成功指標が「業務効率化」のような一般語のままだと、判断に使えないため参照されなくなります。

次に多いのが、仕様変更を議事録とチャットだけで処理し、スコープ欄が初版のまま残るパターンです。稼働直前に「どこまでが当初範囲だったか」で費用の協議がこじれます。変更を承認したら、その場で計画書のスコープ欄と改定履歴を書き換えるルールを管理の章に入れておくと防げます。

目標の実現方法が定まらないまま詳細な計画書を作るのも失敗の元です。DS-100 は、具体的な実現方法が定まっていない場合、規模と期間を限定した試行版で効果を確かめてから計画を立て直す段階的な進め方（実証実験）を検討するよう定めています。

小規模案件でフル版は過剰：A4数枚の簡易版で済ませる条件と規模の目安

関係者が社内の1部門と受託側1社だけで、期間が3か月以内、予算が数百万円規模の案件なら、12章のフル版は過剰です。目的と成功指標、スコープと対象外、体制、日程、変更の承認者の5項目をA4で3〜5枚にまとめた簡易版で運用してください。

反対に、複数部門が利用する基幹業務のシステム、外部システムとの連携が3つ以上ある案件、複数ベンダーが関わる案件では、簡易版で済ませてはいけません。体制と変更管理の書き漏れが、そのまま責任の空白になるためです。複数ベンダーの調整役についてはPMOの役割と外部に任せる判断も参考になります。

プロジェクト計画書のよくある質問：テンプレートの入手先から承認者・更新頻度まで

プロジェクト計画書について、発注担当者から寄せられることの多い質問をまとめました。

プロジェクト計画書のテンプレートはどこで手に入りますか？

公的な資料で項目まで示しているものとしては、デジタル庁の DS-100 第3編第2章が計画書の8項目と管理要領の9項目を列挙しています。様式そのものは配布されていないため、本記事の12章の目次をWordや表計算の見出しに写して使うのが手軽です。社内に過去案件の計画書があれば、それをベースに不足章を足すほうが社内の承認は通りやすくなります。

プロジェクト計画書は発注者と受託側のどちらが作るものですか？

文書としてまとめるのは受託側のプロジェクトマネージャーが多いものの、目的・成功指標・スコープ・予算の上限は発注者が書くべき章です。受託側に全章を任せると、発注者の判断基準が推測で埋まります。工程・成果物・品質管理は受託側、体制と会議体と変更手順は双方で書き、両者の責任者が承認する形にします。

プロジェクト計画書と要件定義書はどちらを先に作りますか？

計画書が先です。計画書で目的・範囲・体制・要件定義工程の進め方を決め、その計画に沿って要件定義を行います。要件定義が終わった時点で、確定したスコープと見積を反映して計画書を改定する流れです。計画書なしで要件定義を始めると、要件をどこまで広げてよいかの基準がなく、要件が膨らみやすくなります。

プロジェクト計画書は誰が承認すればよいですか？

発注側は予算と仕様を最終決定できるプロジェクト責任者、受託側は案件の責任者（部門長やプロジェクトマネージャーの上長）が承認者です。窓口担当者だけの承認では、後で決裁者から目的や予算を覆される余地が残ります。表紙に承認者欄を設け、改定のたびに同じ承認者の確認を取ってください。

プロジェクト計画書はどのくらいの頻度で更新すべきですか？

定期的に更新するより、工程の区切りで改定するのが現実的です。目安はベンダー選定後、要件定義の完了時、稼働の前の3回で、加えて仕様変更を承認した時点でスコープ欄と改定履歴を書き換えます。月次の定例でスコープと日程に差異がないかを確認する議題を固定しておくと、更新漏れに気付けます。

関連記事

• システム開発のプロジェクト管理とは？進め方・QCDと工程/品質/リスク管理と発注側の役割【2026年版】：計画書を作った後の進捗・品質・リスク管理の進め方
• PMOとは？役割・種類とPMとの違い｜システム開発でPMOを外部に任せる判断：計画書の運用を担う管理組織の置き方
• プロジェクト管理とタスク管理の違いとは？ToDo・課題管理との区別とWBSでのつなぎ方：計画書のスケジュールを日々のタスクへ落とす方法
• RFPとは？提案依頼書の意味・目的・記載項目と目次テンプレートを解説：計画書の前段でベンダーへ伝える内容
• 要件定義書の書き方：章立てサンプル・記載項目・レビュー観点を作業手順で解説：計画書の次に作る要件の文書