はじめに
はじめまして。
当記事はプロジェクト立ち上げ時に必要な資料を作成する手助けとなるように作成しました。
未来の書き方を忘れた自分のために、またキッチリとしたプロジェクト計画書の作成を求められた方の為にこの記事を捧げます。
当記事ではデジタル・ガバメント推進標準ガイドラインに準拠させてプロジェクト計画書を作成します。
（最後に出典を記載しますが、引用は全て当資料から行います）
上述したガイドを読むと、プロジェクトを管理する時にはプロジェクト計画書とプロジェクト管理要領の二つの資料が必要みたいです。
プロジェクト推進責任者は、プロジェクトを計画的に遂行するため、プロジェクトの実行に先立ち、プロジェクト計画書及びプロジェクト管理要領を作成するものとする。
ガイドに書いてある内容をある程度踏襲しつつ、自己流で作っていくので、実際の作成時は上長に確認しつつ進めていってください。
プロジェクト計画書の概要
プロジェクト計画書を作らないと行き当たりばったりの管理になり、プロジェクト管理が属人的になります。
逆に、「この資料に書かれていることに従っていれば、プロジェクトは（ある程度）うまく進めることができる！」
といえるほどの計画書があれば安心ですよね。
※社内向けならエクセルで作っていいと思いますが、お堅い文書ならワードで作りましょう。
ガイドにはプロジェクト計画書は以下のものであると書かれています。
プロジェクト計画書には、少なくとも次のアからクまでに掲げる事項について記載するものとし、プロジェクトの進捗に合わせ、その内容を具体化・詳細化していくものとする。
ア 政策目的
イ 対象業務範囲及びサービス・業務企画の方向性等
ウ 対象とする情報システム
エ 目標及びモニタリング
オ 前提条件・制約条件等
カ 実施計画
キ 予算
ク 体制
プロジェクトごとに柔軟に変更するとして、私はこのように章タイトルを変換しました。
| # | 変更前タイトル | 変更後タイトル |
|---|---|---|
| 1 | 政策目的 | プロジェクトの目的 |
| 2 | 対象業務 | プロジェクトの背景 |
| 3 | 対象とする情報システム | スコープ管理 |
| 4 | 目標及びモニタリング | プロジェクトの目標+スコープ管理 |
| 5 | 前提条件・制約条件 | 変更なし |
| 6 | 実施計画 | スケジュール管理 |
| 7 | 予算 | 記載なし |
| 8 | 体制 | プロジェクト体制 |
※予算は予め確定したりしていることも多いと思うので端折ります。
プロジェクト計画書の構成要素（大枠）は以下の通りです。
- 本書の目的
- プロジェクトの概要
- プロジェクト体制
- スコープ管理
- スケジュール管理
これから各項目について記載していきます。
本書の目的
プロジェクト計画書の目的です。
これがないと始まりません。甲乙を明記して、「対象プロジェクトを円滑に遂行するべく、乙にて計画・運用ルールを定める」とでも書けばいいでしょう。
「デジタル・ガバメント推進標準ガイドライン」に準拠していることも忘れずに記載しましょう。（「政府機関等のサイバーセキュリティ対策のための統一基準」もあるとなおよいです）
プロジェクトの概要
この項目でプロジェクトについて説明していきます。
構成は、
- 概要
- 背景
- 目的
- 目標
- 前提条件・制約条件
くらいが妥当でしょう。
概要
プロジェクトで誰が何をどうやっておこなうかを書きます。
これ以降に記載するもののざっくり総括をする感じです。
背景
なぜそのプロジェクトを行うことになったか、を書きます。
紙→電子化のDXとかなら毎日100枚くらい紙で処理していてコストが～とか、そういうのですね。
目的
プロジェクトをクリアした後に何をするかとかです。
改善提案を行うとかより高い操作性で生産性を上げるとか、本来の目的を書きます。
さっきの例でいくと、紙のコストを削減する。とかです。
目標
プロジェクトの最終マイルストーンとかを書いていきます。（しるべ、ですからね）
これができたらプロジェクトクリアです！
目標があって、それを達成すると本来の目的（ユーザビリティアップとか）が達成される。みたいなイメージです。
前提条件・制約条件
予め示されていればそれを書いてください。
作業期間、対象業務、ハードウェア要件とかフレームワークとかですね。
ここら辺の項目は各プロジェクトで内容が大きく変わってくると思います。
仕様書とか読んで書けばいいでしょう。
プロジェクト体制
プロジェクトに関わる人の体制図をパワポで作ってください。
カウンターパート（こっちの責任者-相手の責任者、こっちの管理者-相手の管理者のように）を線でつないで明示することも忘れずにしましょう。
図表が大きくなりそうなら別紙参照にするのが安定だと思います。
体制図には役職や部署名も忘れずに記載しましょう
次に、WBSをもとに責任分担表を用意して各作業の責任分担もここに作ってしまいましょう。（甲乙両方含め、です）
WBSは自チーム、相手組織の両方の作業をアクティビティレベルにまで分解して記載します。
詳細スケジュールに書き出される際、大いに役立ちますし、何日までにこの作業をしなきゃいけないか、ステークホルダーはみんな気になるのです。
スコープ管理
プロジェクトの作業範囲を定めることが目的です。
- 対象業務
- システム化構成
- 開発方法
が妥当ですかね。
対象業務は何の業務をシステム化するかを明記します。
システム化構成は使用するツール及び環境を二次元表でまとめていくのがベターでしょうか。
開発方法は何で開発するか、ですね。フレームワークがあるならしっかり書きましょう。
スケジュール管理
ここでミスると詰みます。
マスタスケジュール作成→WBS作成→詳細スケジュール作成
っていうフローがやりやすいと思います。
この章では以下の項目は作成しましょう。
- マスタスケジュール
- 詳細スケジュール
- 進捗管理手順
- 進捗率定義
- プロジェクトの終結
マスタスケジュール
契約時点で納期が決まっており、既に組まれていることが多いと思います。
そのため、それを基本的に流用して、計画上裏で作業するものとかがあれば明記すると良さそうです。
詳細スケジュール
WBSとマスタスケジュールをもとにして、各作業にかかる人日を見積もっていきます。
まあ、実働8hと言っても実際のところは残業なしで6hもいけばいい方でしょう。
会議の時間や調査時間は開発とは関係ないですからね。
また、詳細スケジュールはマスタスケジュールと責任分担表のふたつと整合性が取れてないといけません。
そこらへんも考えなきゃいけないので結構大変ですね。
進捗管理手順
日々の進捗管理をどうやって行うかを定義します。
フローチャートにした方がわかりやすいでしょう。
・毎日何時に進捗確認を行うか
・進捗確認会議はいつやるか
・媒体は何でやるか
などを示します。
進捗率定義
進捗率はどこの工程でどれほど進んだ時に何%にするか。って感じの定義です。
レビューまで行けば80%みたいな感じです。
肌感覚じゃダメらしいです。
プロジェクトの終結
どの条件を満たしたらプロジェクトが終結するかを定義します。
これを定義しないとプロジェクトが終われません。
プロジェクトの終了条件、終了日を明記しましょう。
終了条件には甲乙双方が終了に合意していること、貸与されている資産があれば。返却されていることなどは明記しましょう。
おわりに
駆け足でプロジェクト計画書について書きましたが、まだまだ粗いのでもっと文章追加してブラッシュアップしていこうと思います。
時間があれば各テーマごとに資料作成の記事もあげようと思います。
次はプロジェクト管理要領です。
確認事項
資料作成時（印刷時）に忘れてはいけないものを列挙しておきます。
・各資料に機密区分は記載していますか？（社外秘やCONFIDENTIALなど）
・コピーライトは記載していますか？
・印刷時のレイアウトは問題ないですか？ヘッダーに&[ファイル名]で資料名を記載した方が優しいです
・単語や書き言葉、語尾の平仄は合っていますか？
・何の資料かわかるように各ページヘッダーに文書名はありますか？
・改訂履歴はありますか？
・目次はありますか？
・配布日は記載されていますか？
・句読点はちゃんとついていますか？
・ページ番号は入っていますか？
・印刷資料はパンチ穴を開けていますか？
・ステープリングは縦印刷では左上、横印刷では右上になっていますか？
・ファイルを送付する前に、プロパティから個人名は消してますか？
消すか、会社名とかにしておきましょう。