この記事は、「架空プロジェクトを通してシステム開発とドキュメント作成を体験してみる（2022 Late）」の記事の一部です。
プロジェクト計画書の概要
プロジェクト計画書はプロジェクトの背景や目的、内容、スケジュール、体制、予算などを記述したドキュメントで、プロジェクト立ち上げ時に、社内で承認を取るための説明資料として作成されることが一般的です。また、承認後のプロジェクト工程において必要に応じて参考にする原点的なドキュメントになります。
環境によっては「プロジェクト企画書」とか「プロジェクトマネジメントブック（PMB）」とか呼ばれることもありますし、事業の立ち上げの際などは「事業計画書」を兼ねるときもあります。
| 項目 | 内容 |
|---|---|
| 作成目的 | プロジェクト進捗の承認をもらうための說明資料 |
| 記述すべき内容 | 目的、スケジュール、体制、金額、懸念事項（リスク）、ルール等 |
| 作成タイミング | プロジェクト着手前の会議 |
| 対象者 | 意思決定層（非エンジニア）、技術者 |
| ファイル形式 | パワーポイントが一般的かとは思いますが、企業文化に応じて調整してください |
| 備考 | ここでは計画書という表現にしていますが、企画書だったり、プロジェクトマネジメントブックとかと呼ばれることもあります。プロジェクトや会社の文化によって変更してください |
一般的にはどうなのか？が気になる人は後半にある「一般的には（参考）」に先に目を通してもらったほうがいいかもしれません。
サンプルのダウンロード
サンプルのダウンロードはこちらから。
作成してみる
では作成していきましょう。
作成方針・ポイント
意思決定層にも理解できるよう要点を簡潔に記述
プロジェクト計画書は意思決定層の人にプロジェクトの承認をもらうことが作成目的であることが多いので、意思決定層の人が知りたい情報を簡潔に記述し、必要な情報は補足や参考情報で補うのがいいでしょう。
まずはダイジェスト版を作る
また、計画書のような意思決定層が見る資料や一定量以上（パワポ10枚以上くらいが目安？）になることが予想される資料は、まず「ダイジェスト版」的なものを1ページくらいで作成し、方針を上長等に確認、フィードバックを受けた上で本編を作るようにした方が、無駄なく資料を作ることができます。
（ダイジェスト版の例）
構成（目次）を考える
サンプルでは下記のような項目を記述してみました。いわゆる5W2H系。
言葉の表現はさておき要素的には一般的にも必須項目かな？と思います。
- プロジェクトの背景とゴール
- システム概要とWeb化（システム化）の範囲
- 参考：業務フローとWeb化の範囲
- プロジェクト スケジュール
- プロジェクト 体制
- プロジェクト 費用
- 成果物一覧
- 補足：成果物一覧（作成方針）
- コミュニケーション
- 既知の課題と対応方針
また、参考資料として下記を準備しました。
- プロジェクト計画（ダイジェスト）
- 投資対効果
- 株式会社 架空開発概要（外注先会社概要）
ぜひ、自分でも考えてみてください。
各内容を記述する（サンプルの說明）
では、構成に従って作成したサンプルの内容について解説したいと思います。
あまり、出来がいいとは言えませんが、まあ、参考まで。
表紙
構成では割愛していましたが、表紙です。
タイトルを「問合せ受付のWeb化による業務改善 プロジェクト（架空）計画書」としました。
あえて「開発プロジェクト」ではなく「業務改善プロジェクト」としています。
経営層にとっては開発はゴールではなく、業務改善（によるコスト削減等）がゴールなので。
目次
目次はとりあえずこんな感じ。
プロジェクトの背景とゴール
背景やゴール（達成したいこと）を記述します。
サンプルはちょっと文章多いかなと思ってます（できればもっとグラフィカルにしたかった・・・）。
システムの概要とWeb化の範囲
システム概要とシステム化（Web化）の範囲などを說明。ここはシステムによって適宜アレンジ。
参考：業務フローとWeb化の範囲
人によっては「業務がどうなるんだ？」を気にする人もいるので、視点を変えて範囲を說明しています。
スケジュール
WBSがあるならそれをコピペしてもいいけど、粒度が細かすぎることが多いので概要を矢羽で記述し直すことが多いです。
体制
外部メンバーの方を体制図に入れるかどうかは状況次第ですが、主要機能を担う場合は入れておいていいと思います。
なお、偉い人が初見の会社だと、なぜその会社を何故選んだのか？とか言われる可能性があるので、会社說明とか用意しておくのが無難です（参考資料に追加しています）。
費用
項目が複雑な場合は合計金額のみか、カテゴリ合計くらいにしておくほうが良いです（ここではめんどくさいのでExcelから貼り付け）。税込か税抜かはその会社の文化や会計基準などを考慮して決定します。
なお、このプロジェクトでは費用の殆どを開発費が占めるので開発費用しか記述していませんが、一般的には周辺の費用も記述します。代表的なものでは、
- PR費用（宣伝広告費）
- コールセンター等のサポート費用
という感じです。その他、プロジェクトに関して発生する費用は分野を問わず記載しておきましょう。
記載しない場合はせめてその旨（○○は含みません等）記載しておきましょう。サンプルではその方式を採用しています（ただ、楽しただけ）。
成果物一覧
プロジェクト計画書にドキュメント類の成果物一覧を入れることは少ないのですが（要件定義書ですかね）、まあ、この記事はドキュメント作成が重要なので記述しています。
補足：成果物一覧（作成方針）
作成するドキュメントは一般的ですが、少しオレオレ（独自）なところもあるので、作成方針を記述し、それぞれのドキュメントに何を記述するか提示しています（承認してもらいます）。
ITプロジェクトに限らずビジネスにおいて正解があいまいな世界では「承認を得る」ことで、正解を設定することができます。どんなにISO○○に準拠してても承認がない内容はNG。どんなにオレオレでも承認があればそれが正解という世界です。
コミュニケーション
コミュニケーション計画とかともいいます。プロジェクト計画書では細かな設定はせず、会議体とかの設定くらいでしょうか。
といいつつリモートワークが当たり前になった世界なのでツールやチャンネル等を指定したりします。
既知の課題と対応方針
予めわかっている課題や事前調整で偉い人が気にしてた事項などについては明示的に言及しておきます。
そうすることで後でもめずに済みます（もめるなら早めです）。
ここからは参考資料。
プロジェクト計画（ダイジェスト）
最初に作ったものを参考に入れています。
決裁をもらう予定の会議で偉い人が「あ、俺今日、時間ないわ」とか「別の議題が紛糾して時間が押した場合」とかに文字通りダイジェスト說明として使えます。
投資対効果（の計算根拠）
本編に投資対効果を載せた場合は、算出根拠などを聞かれるので参考資料で用意しておくのが（自分のためにも）無難。
自社利用システムの償却は5年。販売目的は3年くらいのことは知っておきましょう。
投資コストがPL/BSにどう影響するのかは最低限把握しておきましょう。
株式会社 架空開発概要（委託先会社概要）
偉い人が初見の会社は会社概要を入れておくほうが無難です。
事務的な要項としては選定理由や与信情報などでしょうか。
一般的には（参考）
実践ガイドブックでは？
プロジェクトの計画という視点では、下記の2点を作成することになっているようです。
- プロジェクト計画書
- プロジェクト要領
計画書は実施内容、目的などを記載するもので、要領は実施に係るルールを記載するものと定義されていますが、民間？では計画書に全部書いちゃうのが一般的かなと思います。
計画書テンプレートの目次は下記のようになっています。
また、計画から抜けやすい項目として、第３編2章 プロジェクト管理 P27にて以下のようなものが指摘されています。
- 関係者との調整や仕様の調整、確定作業
- データ以降関連作業
- テスト関連作業
- 移行リハーサル
- 教育、研修、利用者サポート
- 利用者への連絡やプロモーション
- 業務を実施する環境の変更
- 運用段階での利用状況分析、効果測定
要領テンプレートの章立てとしては、以下のようになっています。
なお、実践ガイドブックではさらにプロジェクト計画書は発注者側と開発会社の両方で作るのが理想とありますが、実際はなかなか難しいですよね。。。（もちろん強制はしていない）
（第3編第7章 設計・開発 P22より引用）