プロジェクト計画書 「1章 はじめに」

01_プロジェクト管理

プロジェクト計画書を作成する際に計画書の冒頭でどんなことを書くかネタをまとめる。

様々な人が参照する資料では、その資料の本題を書く前にそもそもこの資料は何のための資料なのかという説明書きをする必要がある。その内容を自身の経験をベースに書き起こしておく。

 

プロジェクト計画書の全体(章立て)は こちら

 

1章 はじめに

この章では、プロジェクト計画書を作成する目的やどういう前提で作成されたのかを述べる。完成度の高いドキュメントでは、”このドキュメントはこういう目的、こういう位置づけものである”というような、そのドキュメントの前提が冒頭でしっかりと説明されている。ここでは、自身が目にしてきた計画書の中でよくある記載(最低書かれているべきと思う内容)をピックアップした。もし、プロジェクトに参画された際には、プロジェクト計画書の冒頭を目にして下記以外にもどのようなことが書かれているか、なぜそのようなことが書かれているのかを考え、ご自身の血肉にしてほしい。

 

 

1.1 本書の目的

・プロジェクト計画書の目的を述べる
・このプロジェクト計画書の内容を関係者で合意の上、この内容に従ってプロジェクトは推進されることを明言しておく

例:
「XXXXシステム刷新プロジェクト プロジェクト計画書」(以降「本書」とする)は●●●株式会社(以降「●●●社」とする)及び株式会社▲▲▲(以降「▲▲▲社」とする)と共同で作成するものである。本書の目的は、プロジェクトの目的、範囲、内容をはじめ、プロジェクトの全体像や進め方を●●●社、▲▲▲社およびこれらの関係者で共通認識を持つためのものである。XXXXシステム刷新プロジェクト(以降「本プロジェクト」とする)は、本書の内容に従って進める。

 

 

1.2 本書の位置づけ

・ドキュメントの階層構造を明確にしてプロジェクト計画書の立ち位置を示すとともに、プロジェクト計画書をインプットに今後どのようなドキュメントを作成していくのかを明確にする

例:

補足:
・ここでは、各工程の主な成果物といった粒度で良い。詳細な成果物は各工程の主な成果物となる基本設計書、詳細設計書などの本紙や計画書に記述する
・上記の図で重要なことは、成果物がトレースできることである。なので、工程別に計画書や本紙を漏れなく記載しておきたい
・要件定義書については、実際にはプロジェクト計画書ではなく、企画フェーズの成果物(業務やシステムのTobeを整理したもの)をInputに作成する
・上記「例:」には、プロジェクト管理計画書(プロジェクト管理の進め方)が無いことに注意。加えたかったがどうもうまくいかなかった・・・(AIで作図)

 

 

1.3 前提となる資料

・企画フェーズの成果物を明記しておく
・「1.2 本書の位置づけ」に盛り込む形でも良いかも

例:

本書の内容は、以下の資料を前提として作成する。
・ XXXXシステム更改プロジェクトご提案書 (←開発ベンダーとしてプロジェクト計画を立てる場合)
・ △△△管理システム更改プロジェクト企画書 (←社内でプロジェクト計画を立てる場合)

補足:
プロジェクトを立ち上げる前には、企画というフェーズがある。なぜこのプロジェクトの立ち上げが必要なのか、どんなメリット・デメリットがあるのか、採算が取れるのか、プロジェクトによる業務に支障はないかなど、様々な検討や議論がされている。その結果、プロジェクトで達成すべきことやシステムのリリースの時期が決まり、プロジェクトのが立ち上げを行う。計画を立てる前にプロジェクトに求める要件(リリース次期、業務影響など)が整理されている資料があるかと思うので、何を参考にしてプロジェクト計画書を作成したのかを明確にしておく。企画書や提案書の内容と整合性が取れない(例えば開発内容やリリース日が違うなど)ことにならないよう注意。

 

 

1.4 本書の取扱い

・プロジェクト計画書を修正する際のルールを決めておく
・修正するに至った背景(プロジェクト方針の変更、リリース次期の変更など)がどの会議で決定したのかがトレースできるような記載にするとよい

例:

本書の内容を変更する際には、●●●社および▲▲▲社と合意したうえで実施する。また、本書の変更は変更履歴に「変更日」「本書のバージョン」「変更に至った背景」「変更内容」「変更者」「●●●社承認者」「タラバ社承認者」を明記するものとする。

 

補足:
・プロジェクトは進行に応じて計画が変更することは少なくないのだが、プロジェクト計画書を作成してもそのままメンテナンスされず放置される現場もある。こうなると、計画、成果物、報告の内容の整合性が取れなくなってくる。また、様々な課題についても、計画という軸が無いと解決の糸口もつかめなくなってくるので、追加・修正はこまめに行いたい
・特にプロジェクト全体や各工程の計画の”方針”(つまり、なぜこのような計画にするのかの根拠)は、非常に重要と考える。プロジェクトを推進する中で様々な壁にぶち当たるが、その時、必ず「そもそもこの計画は~」と、原点に立ち返って状況を整理する必要があるから

 

 

1.5 用語集

・プロジェクト固有のワード、固有名詞、表記の揺れが生じやすい単語などを登録しておく。
・別紙にしておくと更新しやすい

例:

表記(かな) カテゴリ(要素) 意味
●●●システム問合せ窓口(●●●しすてむといあわせまどぐち) 組織名 XXXシステムにおける一般ユーザからのお問い合わせを受ける窓口
ユーザ(ゆーざ) 登場人物(一般) 一般のサービスの利用者
システム利用者(しすてむりようしゃ) 登場人物(■■■社) 各拠点のシステム運用担当者
システム管理者(しすてむかんりしゃ) 登場人物(▲▲▲社) システム中央本部のシステム管理者

 

補足:
・表記の揺れなども登録しておくとよい。例えば下記のような語彙は揺れが生じやすい
  → 問合せ/問い合わせ
  → 切替/切り替え/切替え

コメント

PM-Guide-La(PM-ガイドラ)をもっと見る

今すぐ購読し、続きを読んで、すべてのアーカイブにアクセスしましょう。

続きを読む

タイトルとURLをコピーしました