AI×テンプレ×実務知見でPM力を支援！
writing by Yuichiro Hayashi
01 プロジェクトの目的を間違えた
計画工程でプロジェクトの目的を明確にしなかったことにより、ユーザーテスト（最終段の受入テスト）で、プロジェクトオーナーよりクレームが入りプロジェクト破綻 。
02 スコープの決め方がわからなかった
プロジェクト計画を検討する中で、スコープを決める手順を知らなかったことで、コスト爆上げ！設計工程でリカバリーを図るがスケジュールの大遅延によりプロジェクト破綻。
03 工数を算出する範囲が漏れていた
プロジェクト計画で全体工数を算出したが、リスク対策用に工数を上乗せしなかった。
総合テスト工程で、想定以上のバグやクライアントからの指摘事項が多くリカバリーができず、プロジェクト破綻。
04 品質基準を適当に設定...
プロジェクト計画で品質基準の作り方が分からず、他のプロジェクト計画書からコピペ。
しかもクライアント合意なし。リリース前日にクライアントの要求を満たしていないことが発覚し、プロジェクト破綻。
05 正しくWBSを作れなかった
間違った手順でWBSを作ったことで、非効率な作業順序によりコスト増大！スケジュール策定も失敗！Wショックでマネジメントができず、プロジェクト破綻。
これらは、正しくプロジェクト計画を立てられずプロジェクトが破綻した実例です。
なぜ、プロジェクトが破綻したのか？
プロジェクト計画の策定に失敗したからです！
PMであれば、プロジェクト計画を立てる時に、
☑︎ 構成を順番通りに
☑︎ 正しい手順で
☑︎ メソッドやノウハウを使って 「プロジェクト計画書」に、まとめ上げていくスキルが必要です。
そのコツは、10,000人以上が読んだ、このコラムで答えが見つかります♪
監修：プロコンサル MASA
2004年に大手コンサルファームBにジョイン。
大手事業会社をクライアントに持ち、クライアント社内で活用する品質マネジメント基準・開発プロセス基準の策定に従事。
また、PMOとしてクライアントのプロジェクト推進及び品質維持に貢献しプロジェクトを成功に導いた。
2016年に大手コンサルファームMにジョイン。
大手エネルギーインフラ会社のガバナンス部門にて、大規模システム開発プロジェクトのマネジメント品質管理に従事。
PMOとしてプロジェクト運営における問題点の可視化とプロジェクトマネージャおよび上位層への改善提案によりプロジェクトを成功に導いた。
こんにちは、プロコンサルの林 雄一郎です。
私が参加しているiPMでは、PM初心者のスキルアップやDX時代に適応したいPMのリスキリングのサポートとして、iPM TRAININGを運営しています。
このコースの一つとして、『プロジェクト計画書の作り方』を講座として提供しています。
今回のコラムは、PMであれば絶対に知っておきたいプロジェクト計画書を作る手順・各目次に沿って何を記載するのかを解説します。
これは、大手コンサルファーム直伝の『プロジェクト計画書の目次』になります。
さて、初めてPMをやる人って、プロジェクト計画書を作るのに苦戦するものです。
今回は、誰でも簡単にPJ計画書が書けてしまうメソッドを披露したいと思います。
そんな魔法みたいなことってあるの？と感じるかもしれません！
そのようなものはありませんが...
きちんと手順を押さえて、ルールに従って作っていけば矛盾のない計画書が書けます。
それでは、スタートします。
| 【重要】プロジェクト計画書の3つの要素
プロジェクト計画書って大きく3つの要素で構成されています。
・WHY（なぜプロジェクトを行うのか）
・WHAT（どのような作業を行なって、どんな成果物を作るのか）
・HOW（成功に導くための手段や方法） このような特徴を一冊にまとめています。
プロジェクト計画書は、この3つの要素に対して、PMが知恵を振り絞って苦労しながら作り上げていく言わば「芸術品」です。
また、この3つの構成が一つになった時にプロジェクトをスタートすることができます。
そして、計画書に従ってPMはプロジェクトを運営しなくてはなりません。
正しい知識で作られたプロジェクト計画書は、成功への第一歩を踏み出せたと言えます。
それでは、3つの要素（WHY・WHAT・HOW）に従って、プロジェクト計画書の目次ごとにに何をどのように記述すれば良いのかの『ポイント』を解説していきます。
｜ WHY
1.プロジェクトの目的
1.1.プロジェクト立ち上げ経緯
お客さまの業務環境と課題を調査し明記する。
☑︎プロジェクトの誘因となる市場の要求
☑︎ビジネス･ニーズ
☑︎お客さま要求
☑︎技術の進歩
☑︎法的要求
☑︎社会的ニーズ
1.2.目的
なにを実現するためのプロジェクトなのかを明記する。
☑︎なにを手に入れたいのか、手に入れたことで、なにがハッピーなのかを明確にする。
☑︎お客さまの便益とプロジェクト活動が結びつくようにする。
☑︎目的を数値で表現する。
1.3.プロジェクトの妥当性
プロジェクト投資効果の分析結果を明記する。
☑︎ROI
☑︎ROA
☑︎ROE
☑︎ORS
1.4.関連組織への影響
プロジェクトを実施することによる関連組織へのポジティブ影響、ネガティブ影響の分析結果を明記する。
☑︎今よりも使い勝手の良いシステムになる（悪くなる）。
☑︎今よりも業務ボリュームが増える（減る）。
☑︎新たなシステムの導入や修正があるか。
| WHAT
2.プロジェクトスコープ
2.1.対象業務と2.2.対象システム
お客さまの要求事項を明記する。
☑︎対象となる業務に対するビジネスニーズをまとめる。
☑︎対象となる業務の効率を良くするためのシステムニーズをまとめる。
2.3.プロジェクト対象外
プロジェクトの除外事項を明記する。
☑︎お客さまとの齟齬・誤解・誤認識を防ぐために対象外の作業をまとめる。
☑︎境界線上にある曖昧な作業をまとめる。
2.4.プロジェクト成果物
プロジェクトの成果物を開発工程単位で明記する。
☑︎システム化範囲を対象に成果物を一覧としてまとめる。
☑︎WBSの第3階層目のワークパッケージを洗い出し順序を設定する。
3.前提条件・制約条件
3.1.関連プロジェクト
あなたのプロジェクトと連携する他のプロジェクト、お客さまのビジネスニーズを強く受けているプロジェクトを明記する。
☑︎あなたのプロジェクトの成功が前提条件となっている他プロジェクト。
☑︎あなたのプロジェクトが他プロジェクトの終了が前提条件となっている。
☑︎他プロジェクトが中止や延期になった場合にあなたのプロジェクトに影響がある。
☑︎他プロジェクトで変更があった場合にあなたのプロジェクトにも大きな影響がある。
3.2.関連システム
あなたのプロジェクトで開発されるシステムと何かしらの関係があるシステム、関連するプロジェクトで開発されるシステムを明記する。
☑︎あなたのプロジェクトのシステムとデータのやり取りを直接行うシステム。
☑︎あなたのプロジェクトのシステムとデータが、直接的に・間接的に使われ処理されるシステム。
3.3.前提条件
品質・コスト・スケジュール・スコープ・コミュニケーション・体制を対象として不確実であることを確実とみなし、成功する要素を推測して明記する。
☑︎条件として成立するものは全て前提条件とする。
3.4.制約条件
お客様からの要望で厳守する必要がある全ての事項を明記する。
☑︎お客さまから既定の予算・リリース日・スケジュールなどの要望。
3.5.重視する要素
お客さまの都合・法律変更等によって全ての目標が達成できない場合の事象を明記する。
☑︎品質
☑︎コスト
☑︎納期
4.スケジュール
4.1.主要マイルストーン
主要なマイルストーンを明記する。
☑︎WBSの第3階層目のワークパッケージから主要なマイルストーンを設定する。
4.2.マスタースケジュール
所用期間が求められた全てのワークパッケージからスケジュールを作成し明記する。
☑︎WBSの第3階層目のワークパッケージ単位に作業を完了させるための所用期間を見積もる。
5.プロジェクト体制
5.1.スキル一覧
ワークパッケージ単位に必要なスキルを洗い出し明記する。
☑︎ワークパッケージ単位に類似プロジェクトを元にして必要スキルを設定する。
5.2.要員計画
要員計画を明記する。
☑︎要員の着任と離任のタイミングを計画する。
5.3.プロジェクト体制図
プロジェクトチームに着任する予定のメンバを含めた体制を明記する。
☑︎指揮命令系統がわかるように体制図はツリー型にする。
6.プロジェクト予算
プロジェクト予算の内訳と合計を明記する。
☑︎ハードウエア費用
☑︎ソフトウエアライセンス費用
☑︎開発費用
☑︎予備費用
7.品質基準
7.1.開発工程の品質基準
開発工程における合格基準を明記する。
☑︎画面入力・バッチ処理のレスポンスタムを設定する。
☑︎設計・テスト工程の品質基準を設定する。
7.2.受入工程の品質基準
ユーザーテスト（お客さま受け入れテスト）の合格基準を明記する。
☑︎テスト消化・不具合の修正、要望の達成度合いにおける品質基準を設定する。
8.プロジェクト目標
8.1.品質目標
プロジェクトの品質目標を明記する。
☑︎品質に関わる部分から絶対条件になり得る数値。
8.2.コスト目標
プロジェクトのコスト目標を明記する。
☑︎お客さまがプロジェクトを行うために妥当と考えている費用。
☑︎プロジェクト予算の上限。
8.3.スケジュール目標
プロジェクトのスケジュール目標を明記する。
☑︎スケジュールに関わる部分から絶対条件になり得る日付。 （マイルストーン、他プロジェクトのクリティカルタスクも対象と考える）
| HOW
9.マネジメント計画
マネジメント計画は、母体組織となるプロジェクトマネジメント・チームの管理方針と実行方法を記述します。
9.1.品質マネジメント計画
(1)マネジメント方針
品質マネジメントに関する当プロジェクトの特徴や当プロジェクトにおける方針を明記する。
(2)品質計画
どの品質規格がそのプロジェクトに関連するかを特定し、どのようにそれを満足させるかを明記する。
また、品質マネジメントチームの役割・組織体制・権限・責任及び品質尺度と品質ベースラインを明記する。
(3)品質管理
品質管理の方法・レビュー対象成果物・レビュー合格基準・評価分析と言った品質をどのように監視コントロールするのかを明記する。
9.2.コストマネジメント計画
(1)マネジメント方針
コストマネジメントに関する当プロジェクトの特徴や当プロジェクトにおける方針を明記する。
(2)コストの予算化
コスト・ベースライン（時系列における累積コスト）を作成したり承認したリする要領を明記する。
(3)コスト管理
コスト管理の手順・評価分析と言ったコストをどのように監視コントロールするのかを明記する。
9.3.スケジュールマネジメント計画
(1)マネジメント方針
スケジュールマネジメントに関する当プロジェクトの特徴や当プロジェクトにおける方針を明記する。
(2)アクティビティ資源の見積もり
プロジェクトにはどのような資源（工数・要員）が、どれくらい・いつからいつまで必要なのかを見積もる手順を明記する。
(3)変更要求のスケジュール化
プロジェクトで何かしらの変更が起こった場合に備えて、再スケジュールの手順・所用期間の見積もり方法を明記する。
(4)スケジュール管理
スケジュール管理の手順・評価分析と言ったスケジュールをどのように監視コントロールするのかを明記する。
9.4.スコープマネジメント計画
(1)マネジメント方針
スコープマネジメントに関する当プロジェクトの特徴や当プロジェクトにおける方針を明記する。
(2)スコープ定義
スコープ対象の検証・プロジェクト成果物の定義・WBSの作成要領を明記する。
(3)変更要求のスコープ化
スコープ化の手順を明記する。
(4)スコープ管理
スコープ管理の方法・評価分析と言ったスコープをどのように監視コントロールするのかを明記する。
9.5.コミュニケーションマネジメント計画
(1)マネジメント方針
コミュニケーションマネジメントに関する当プロジェクトの特徴や当プロジェクトにおける方針を明記する。
(2)コミュニケーションの方法
情報の種類に応じてコミュニケーション方法（相互型・プッシュ型・プル型）を明記する。
(3)報告書
当プロジェクトで利用する報告書類を明記する。
(4)会議体
当プロジェクトで実施する会議体を明記する。
(5)コミュニケーション管理
コミュニケーション管理の方法・評価分析といったコミュニケーションをどのように監視コントロールするのかを明記する。
9.6.組織マネジメント計画
(1)マネジメント方針
組織マネジメントに関する当プロジェクトの特徴や当プロジェクトにおける方針を明記する。
(2)体制計画
スコープの追加、変更に伴う役割分担・体制の再構築の考え方を明記する。
(3)要員計画
要員の割り当て方針・要員の選定方針・要員の着任基準・要員の離任基準・要員の交代基準を明記する。
(4)組織管理
組織管理の方法・評価分析と言った組織をどのように監視コントロールするのかを明記する。
9.7.リスクマネジメント計画
(1)マネジメント方針
リスクマネジメントに関する当プロジェクトの特徴や当プロジェクトにおける方針を明記する。
(2)リスク計画
リスク事象の尺度とリスクの脅威の基準を明記する。
(3)リスク管理
リスクの評価分析方法を明記する。
プロジェクト計画書って、どのようなもので、なにを書けば良いのかを解説してきました。
このコラムを読み終わろうとしている、あなたはPJ計画書の根本的な知識を得ました。
あなたの次の行動は、プロジェクト計画書の目次に沿って、具体的に書き上げていくメソッドの吸収です。
iPM naviで紹介されるコラムを通じて、大手コンサルファーム直伝のメソッドやノウハウを身に付けてください。
最後まで読んでくれて有難う御座いました。