プロジェクトの計画書は重要だと理解しているけど、具体的にどのような内容を記載すべきか今一度確認しておきたいですよね。
そこで当記事では計画の立て方やプロジェクト計画書に記載すべき内容と注意点、プロジェクト計画書とプロジェクト憲章の違いなどについて分かりやすく解説します。
- 計画の立て方
- プロジェクト計画書に記載すべき内容
- プロジェクト計画書作成時の注意点
- プロジェクト計画書を作成した後にすべきこと
- プロジェクト憲章とプロジェクト実行計画書の違い
本記事の執筆者
ほとんどのPM(プロジェクトマネージャー)の方はプロジェクト立ち上げ時にしっかりとプロジェクト計画書(マネジメント計画書)を作成されていることでしょう。
しかし、今までの自分の知識や経験に頼って計画書を作成し、プロジェクトを成功させるために押さえておくべきポイントを網羅的に計画書に落とし込めていないPMがいることも事実です。
「いや、これまで俺のやり方で進めてきて失敗しなかったから問題はない。」という方は素晴らしいです。しかし、世の中のPMがどのような方法で計画書を作成しているかを知っているだけでも非常に有益ですよ。
そこで今回は計画を立てる際に押さえておくべき考え方と、実際に世間のPMが何を基準に計画書を記載しているかをお伝えします。
そもそもプロジェクト計画書なんて作成しなくてもどうにかなるだろうと考えている方は、次の記事で「計画書が無いプロジェクトの末路」を紹介していますので是非ご一読ください。
計画の立て方
計画を立てる際の一般的なフレームワークとして5W1Hがあります。しかし、私は6W2Hを意識して計画を立てることをお勧めします。
6W2H
5W1HにWhom(誰に)、How much(いくらで)の2つを加えたものが6W2Hです。
| What(何を) | 顧客が保有している旅行業予約管理システムを刷新する。 |
|---|---|
| Why(なぜ) | 前回の改修から7年が経過したため老朽取り換えを実施する。刷新に当たり、顧客リストの作成業務を効率化させる。 |
| When(いつ) | 2022年1月～2023年12月まで。 |
| Who(誰が) | 本プロジェクトは流通事業部の部長主体の元、パートナー会社3社の協力を得て実施する。 |
| Whom(誰に) | 発注元であるA社向けにシステムを納品する。 |
| Where(どこで) | 東京本社と大阪支店の2拠点で開発を実施する。 |
| How(どのように) | アジャイル開発を適用し、複数回のプロトタイプを作成する。 |
| How Much(いくらで) | 予算はインフラ購入費含めて1億円とする。 |
6W2Hを使うことで「目的」の対象となるWhom(誰に)とビジネスの基礎であるHowMuch(いくらで)を漏らさず計画することができます。
これはプロジェクトに限らず、旅行や登山など生活における計画を立てる際にもベースとなる考え方です。
※「whom(誰に)」の部分は「私のために」「家族のために」などです。
これだけでも、最低ラインの計画を立てることができます。しかし、プロジェクトとは非常に複雑な要素が絡み合っておりそれらのバランスをとることで成り立ちます。
次は「プロジェクト計画書」にはどのような内容を記載すれば良いのかを解説します。
プロジェクト計画書に記載すべき内容
初めに計画書を作成する目的を再度確認してから、実際に計画書に記載すべき項目を解説していきます。
プロジェクト計画書の目的
プロジェクト計画書ではプロジェクトのゴールを達成するまでにどのような手順で作業を実施するかを細かく定めます。
計画書を作成することで、ゴールまでの道筋が明確になります。
また、初めに計画を立てることでプロジェクト実行中に自分たちは今どこまで進んでいるかが数値的にも判断でき、問題が大きくなる前に改善策を打つことができるようになります。
プロジェクト計画書の記載内容
プロジェクト計画書にはPMBOK®の各種知識エリアとして定めた内容、プロジェクト開始時のベースライン、構成管理の方法、変更管理の方法について記載します。
補助計画の情報
PMBOK®ではPMが管理するうえで注意を払うべき領域として「10の知識エリア」が定められています。これらを網羅的に計画することで隙が無い計画書を作成できます。
- プロジェクト統合マネジメント
- プロジェクト・スコープ・マネジメント
- プロジェクト・スケジュール・マネジメント
- プロジェクト・コスト・マネジメント
- プロジェクト品質マネジメント
- プロジェクト資源マネジメント
- プロジェクト・コミュニケーション・マネジメント
- プロジェクト・リスク・マネジメント
- プロジェクト調達マネジメント
- プロジェクト・ステークホルダー・マネジメント
「10の知識エリア」の詳細については次の記事で詳しく解説しています。
ベースラインの情報
プロジェクト開始時点のコスト、スコープ、スケジュールについて定義します。
プロジェクト実行中の進捗管理のベースとなったり、顧客要望による仕様変更のベースになります。
PMBOK®では「コストベースライン」「スコープベースライン」「スケジュールベースライン」の3つを合わせてパフォーマンス測定ベースラインと呼ばれています。
構成管理計画
構成管理を行う目的、方針、ルールを記載します。
構成管理を行う目的
なぜ構成管理を行うのか、構成管理を行うとどのようなメリットがあるのかを記載します。
例：
以下を目的として構成管理を実施する。
- デグレ防止
- 納品物の整合性確保
- 不具合対応時の認識齟齬防止
構成管理方針
どのような思想で構成管理を実施するか、その方針を記載します。
例：
- 設計書は版管理を行うためサブバージョンを導入する。
- 顧客受領資料などは版数管理不要なため、別途用意したストレージで一括管理する。
- 設計書に関する検討事項は、機能単位フォルダ配下に「検討資料」フォルダを作成して管理する。
構成管理ルール
構成管理を行う上で必要なルールを記載します。
例：
◆サブバージョン登録時は以下のルールとする。
- サブバージョンのルートディレクトリは全メンバー共通でC:¥XXX¥XXXとする。
- 設計書名は頭に【設計】を付ける。
- コミット時は「担当名：対応内容」を明記する。
変更マネジメント計画
プロジェクトを進めていくと、当初の計画と現実のギャップが見えてきて計画の修正が余儀なくされる場合があります。
このように変更が発生した場合にはどのような対応をとるべきかを計画します。
メンバーの意見を集約する場を計画しておく
プロジェクトマネージャー1人では決定できないような変更が発生した場合に、どのようなプロセスで変更を実施するのかを計画しします。
例：
- 変更管理委員会(CCB:Change Control Board)を設置する
- CCBはPMが招集する
- 承認された変更は3営業日以内に議事録として関係者に配布する
顧客からの変更依頼に備える
顧客からシステム機能の一部を変更したい、この画面も作ってほしいなどの仕様変更が発生した場合に、どのようなプロセスで変更を受け入れるのかを計画します。
例：
仕様変更が発生した際は、以下の項目を管理する。
- 仕様変更のタイトル
- 仕様変更の概要
- 変更が発生する対象機能
- 変更を実施する時期
- 変更に要する工数
プロジェクト計画書作成時の注意点
ここまでプロジェクト計画書にどのような内容を記載すれば良いか解説してきました。
これで完璧な計画書が書けるかというと答えはNoです。
自分のプロジェクトはどのような特徴があるかをしっかりと把握し、プロジェクトに適した計画書に仕上げていく必要があります。
すべての領域を記載すれば良い訳ではない
PMBOK®の「10の知識エリア」に基づいてすべての内容を計画書に記載すれば良い訳ではありません。
その理由は以下の通りです。
- 1億円を超えるプロジェクトではすべての項目を細かく決めていくと計画書が100ページを超えて、後々変更が発生した際の修正負荷が大きくなりすぎる
- 初めての取引先や新技術導入など不透明さが残る領域について、初めから細かく定義することはできない
- 無理に定義して、プロジェクトメンバーを間違った方向に導いてしまう
- 1週間で完了するような小さなプロジェクトにおいて詳細すぎる計画書は無駄
テーラリング
プロジェクト計画書を記載する際は自分のプロジェクトにはどのような特徴があるかしっかりと見極め、プロジェクトの特徴に沿った計画書に仕上げていきます。
この作業をテーラリング(Tailoring)と言います。
テーラリングとは洋服の仕立て直しという意味です。
オーダーメイドスーツを作る際、寸法取りやデザイニングを行い自分の身体にフィットした一着を作成します。
プロジェクトも同じで、プロジェクトの特徴にフィットした進め方というものがあります。こうしたカスタマイズこそが「テーラリング」です。
PMBOK®ではテーラリングは次のように定義されています。
プロジェクトをマネジメントするために、プロセス、インプット、ツール、技法、アプトプット、ライフサイクル・フェーズの適切な組み合わせをきめること
出典：PMBOK Guide
プロジェクトの内容や特徴にあわせて、各種知識エリアで定めるべき内容を選択的に計画書に落とし込んでいきましょう。
「計画の抜け漏れ」と「意識して実施しない」は全くの別物です。
プロジェクト計画書を作成した後にすべきこと
プロジェクト計画書を作成した後に実行すべき大切な2つの要素を解説します。
- メンバーへの共有
- PDCAサイクルを回す
メンバーへの共有
プロジェクト計画書を作成したら、必ず各チームリーダや主要メンバーに計画書の内容を説明するようにしてください。
プロジェクトの進め方は全員が正しく理解する必要があり、プロジェクト計画書はその柱となります。
PDCAサイクルを回す
プロジェクト計画書を作成したらそこで終わりではありません。
計画書の作成はPDCAのPの部分であり、始まりです。
残念ながら計画書を作成したきりで、プロジェクト途中に計画の見直しを実施しないというPMは相当数います。
「プロジェクト計画書は大切」、「PDCAサイクルを回すことが大切」とそれぞれを理解しているものの、プロジェクト計画書がPDCAのPに該当していると意識的に紐づけできていない場合が多いです。
PDCAを意識して、計画から外れる事象が発生した場合にはその原因をチェックして、計画書に反映しましょう。
プロジェクト憲章とプロジェクト実行計画書の違い
プロジェクト計画書を作成する前にプロジェクト憲章を作れと言われたことはないでしょうか。
記載すべき項目だけを比較すると大体同じような内容が並んでおり、プロジェクト憲章とプロジェクト計画書の違いがわからないという方も多いと思います。
プロジェクト憲章とは、プロジェクトを始めるにあたり何をゴールとするか、どのようなステークホルダーがかかわっているか、いつまでに完了させる必要があるのかを記載するプロジェクトの企画書です。
一方、プロジェクト計画書は、プロジェクトのゴールを達成するまでにどのような手順で作業を実施するかを定めたプロジェクトの計画書です。
このようにプロジェクト憲章とプロジェクト実行計画書の役割は明確に違うのです。
まとめ
今回は、プロジェクトを成功させるための計画書の書き方、および計画書に記載すべき内容や注意事項を解説しました。
◆計画を立てる際は5W1HにWhom(誰に)とHowMuch(いくらで)を追加した6W2Hを意識する。
◆プロジェクト計画書には「PMBOK®10の知識エリアに沿った計画」「ベースライン情報」「構成管理計画」「変更マネジメント計画」を記載する。
◆テーラリングして自分のプロジェクトにフィットした計画に仕立てる。
◆プロジェクト計画書を作成した後はメンバーへの展開とPDCAサイクルを回すことを意識する。
◆プロジェクト憲章は企画書、プロジェクト計画書は計画書。役割を正しく把握する。
では、今回はここまで。
最後まで読んでいただきありがとうございました。
