プロジェクト計画書の書き方と記入例、作成手順

プロジェクト計画書とは

プロジェクト計画書とは、プロジェクトの目的・作るもの・成果物・体制・スケジュール・予算・変更時のルールを、作業を始める前に文書にまとめたものです。関係者はこの文書を見て、何を作り、誰がいつ何を確認するのかを同じ前提で進めます。

システム開発を受託する場合、開発会社は提案書や計画書で開発の進め方を示します。作業スケジュールと役割分担は、発注側と契約で取り決めます（情報サービス産業協会「ソフトウェア開発委託基本モデル契約書」第4条）。計画書のスケジュールと体制は、契約の内容とそろえて書きましょう。

プロジェクト計画書は、関係者が違う前提で動くのを防ぐために書く

プロジェクト計画書が必要なのは、関係者が違う前提で動き出すのを、作業に入る前に防ぐためです。

システム開発では、発注側・開発会社・利用部門・承認者など、複数の関係者が関わります。それぞれが違う前提で動くと、「この機能も含まれていると思っていた」「この日までに返答が必要だと知らなかった」といった問題が起きてしまいます。

プロジェクト計画書は、予定どおりに進めるためだけのものではありません。途中で変更が出たときに、費用・納期・作業範囲を見直すための基準にもなります。

要件定義書は作るものの中身、プロジェクト計画書は進め方を書く

プロジェクト計画書と混同しやすい文書は、要件定義書とプロジェクト憲章です。要件定義書にはシステムに求める機能と条件を書き、プロジェクト計画書にはそれをどう作り進めるかを書きます。

プロジェクト計画書に書く項目と記入例

プロジェクト計画書に書く項目は、目的とゴール、作るもの・作らないもの、成果物、体制と役割、スケジュールと予算、変更時のルールの6つです。

予約管理システムを例にした6項目の記入例

電話で受けている予約をWebで受け付けるためのシステムを作る場合、6つの項目に何を書くかを表にしました。金額や日付は案件ごとに違うため、スケジュールと予算の欄には、何を書くかだけを示しています。

目的・作らないもの・承認者・変更時のルールが抜けると判断が止まる

以下の項目が抜けると、作業の途中で判断が止まってしまいます。

プロジェクト計画書の作成手順（6ステップ）

プロジェクト計画書は、次の6つのステップで書きます。先に書いた項目が、次の項目を決める基準になります。

体制と役割をスケジュールより先に書くのは、発注側の確認日をスケジュールに入れるには、誰が確認し、誰が承認するのかが先に決まっている必要があるからです。目的より先に機能の一覧を作ると、業務の改善に関係の薄い機能まで入ってしまう場合があります。

1. 目的とゴールを書く

最初に書くのは、目的とゴールです。目的には改善したい業務とその理由を、ゴールには達成したと判断できる状態を書きます。「システムを作ること」を目的にせず、どの業務をどう変えたいのかを言葉にしましょう。

ゴールは「予約状況を管理画面で確認できる」「予約一覧をCSVで出力できる」のように、見て確かめられる形で書きましょう。完成したときに達成できたかどうかを、関係者が同じ基準で判断できるためです。

目的とゴールが書けていれば、後から機能を追加するか迷ったときも、業務の改善に関係する内容かどうかで判断できます。

2. 作るもの・作らないものを書く

目的とゴールを書いたら、今回作るものと作らないものを分けて書きます。作らないものには、打ち合わせで話に出たものの、今回は対象外にした機能を書いておきましょう。

作らないものを書くのは、要望を切り捨てるためではありません。初回で作る機能と、後から検討する機能を分けるためです。この区分があれば、追加の依頼が来たときに、今回の見積もりに含まれるのか、別の見積もりになるのかを判断できます。

3. 成果物を書く

作るものが決まったら、納品する成果物を書きます。完成したシステムだけでなく、設計書・テスト結果・操作説明資料のように、作業の途中や最後に渡す資料も成果物として書いておきましょう。

成果物を具体的に書いておかないと、納品のときに、何がそろえば完了なのかを判断できなくなってしまいます。

4. 体制と役割を書く

体制と役割には、作業する人だけでなく、確認する人と最終的に判断する人も書きます。開発会社側の担当者に加えて、発注側の窓口担当者・確認者・承認者も書いておきましょう。

システム開発では、開発会社が設計や開発を進めても、業務の中身は発注側が判断する場面があります。たとえば予約のキャンセル期限、管理者が見られる情報、通知を送る条件などは、発注側の判断が必要です。

計画書には、次の役割ごとに担当者を書きます。

• 開発会社との窓口になる担当者

• 利用部門に確認する担当者

• 仕様変更を判断する人

• 追加費用を承認する人

• リリースしてよいかを判断する人

承認者が書かれていないと、判断が必要な場面で作業が止まってしまいます。

5. スケジュールと予算を書く

体制が決まったら、次はスケジュールと予算です。スケジュールには作業期間と区切りの日を書き、その中に発注側の確認日と承認日も入れます。予算は金額だけでなく、見積もりに含む作業と含まない作業を分けて書きましょう。

見積もりに含む作業として書いておきたいのは、次のような内容です。

• 要件整理や打ち合わせの回数

• 画面や機能の数

• 修正対応の回数

• テストや受け入れ支援の範囲

• 操作説明資料を作るかどうか

予算とスケジュールは、作るものの範囲と連動します。たとえば、予約管理システムに「メール通知機能も追加したい」と後から依頼された場合、その分の開発費用が増えるだけではなく、動作確認やテストの期間も延びる可能性があります。

スケジュールの区切り方を決める基準は、案件で採用している開発手法です。受託開発では、アジャイル開発かウォーターフォール開発かによって、契約の形が変わります。開発手法は、契約を結ぶ前に発注側と合意しておきます（情報処理推進機構「情報システム・モデル取引・契約書（アジャイル開発版）」）。

ウォーターフォール開発なら、要件定義・設計・開発・テストの工程順に区切りの日を置き、要件定義書や外部設計書（画面や帳票などの設計）の確定、納品物の検収といった区切りごとに、発注側の確認日を入れましょう。

アジャイル開発なら、一定の期間で区切った開発（スプリント）を繰り返すため、スプリントが終わるごとに、発注側が成果を確認する日を入れます。

6. 変更時のルールを書く

最後は、変更時のルールです。システム開発では、計画どおりに進めていても、途中で要望が増える・確認が遅れる・外部サービスの仕様が変わるといったことが起こります。

すべてを防ぐことはできないため、「途中で機能を追加したくなったらどうするか」「発注側の確認が遅れたら納期はどうなるか」「外部サービスの変更で仕様を見直すときは誰が判断するか」のように、起こりそうな場面ごとの手続きを先に書いておきます。

計画書に書いておきたいのは、次の内容です。

• 仕様変更を依頼する方法

• 変更内容を誰が確認し、誰が承認するか

• 追加費用が発生する条件

• 納期が変わる条件

• 変更内容をどこに記録するか

連絡の方法も、内容によって分けて書いておきましょう。日々の質問はチャットで受け、仕様変更や追加費用の承認はメールや文書で残すと決めておけば、後から誰が何を了承したのかを確かめられます。

変更時のルールが書かれていれば、追加の要望が出たときも、費用・納期・優先順位を見直して判断できます。

受託開発の計画書には、発注側の作業と確認・承認日も書く

システム開発を受託して計画書を書くときは、開発会社側の作業だけでなく、発注側が担当する作業と、発注側が確認・承認する日も書きます。発注側の作業や確認が遅れると、開発会社も次の作業に進めないためです。

情報サービス産業協会のモデル契約書（第8条）でも、発注側と開発会社の双方にそれぞれの分担作業があるとし、分担作業を遅らせた側は、そのことについて相手方に責任を負うと定めています。

発注側が担当する作業を役割分担に書く

発注側が担当する作業は、開発会社側の作業と同じ表に並べて書きましょう。情報サービス産業協会のモデル契約書（第9条・第39条）では、作業に必要な資料の提供や、要件定義書の確定・納入物の検収は発注側が行うことになっています。

発注側の作業に担当者と期限が書かれていないと、必要な資料や回答がそろわず、開発会社の作業が止まってしまいます。

発注側の確認・承認日をスケジュールに書く

スケジュールには、開発会社の作業期間と並べて、発注側が確認・承認する日を書きます。書いておきたいのは、以下の日です。

• 要件を確認する日

• 設計内容を確認する日

• 画面や機能を確認する日

• テスト結果を確認する日

• リリースしてよいかを判断する日

日付だけではなく、確認する人と確認にかける日数も書いておきましょう。たとえば、設計書を送ったのに発注側の担当者が不在で確認が数日止まると、その間は開発会社も次の作業に進めず、納期が後ろにずれてしまいます。承認者が忙しい場合は、計画書を書く時点で確認日を押さえておきましょう。

発注側がプロジェクト計画書で見るのは、要望が目的と作るものに入っているか

プロジェクト計画書を受け取る発注側の担当者が見るのは、自社の要望が、目的・作るもの・成果物に書き込まれているかです。要望がそのままの文章で載っているかではありません。

たとえば、「電話予約の対応時間を減らしたい」という要望がある場合、計画書には以下の内容が入っている必要があります。

• Webで予約登録できる
• 利用者が予約を変更・キャンセルできる
• 管理者が予約状況を確認できる
• 電話対応が残るケースが整理されている

自社で困っている業務が変わる内容になっているかを基準にして、確認しましょう。

まとめ

プロジェクト計画書の項目は、最初に書く目的とゴールを基準に決めていきます。受託開発では、そこに発注側の作業と確認・承認日を加えます。

まずは記入例の表を見ながら、自分の案件の目的とゴールを1行ずつ書き出してみてください。