writing by Yuichiro Hayashi *このコラムはiPM naviで配信しています
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）に従って、プロジェクト計画書の目次ごとにに何をどのように記述すれば良いのかの『ポイント』を解説していきます。
contents
・WHAT（どのような作業を行なって、どんな成果物を作るのか）
WHY
1.プロジェクトの目的
1.1.プロジェクト立ち上げ経緯
お客さまの業務環境と課題を調査し明記する。
☑︎プロジェクトの誘因となる市場の要求
☑︎ビジネス･ニーズ
☑︎お客さま要求
☑︎技術の進歩
☑︎法的要求
☑︎社会的ニーズ
1.2.目的
なにを実現するためのプロジェクトなのかを明記する。
☑︎なにを手に入れたいのか、手に入れたことで、なにがハッピーなのかを明確にする。 ☑︎お客さまの便益とプロジェクト活動が結びつくようにする。 ☑︎目的を数値で表現する。
1.3.プロジェクトの妥当性
プロジェクト投資効果の分析結果を明記する。 ☑︎ROI ☑︎ROA ☑︎ROE ☑︎ORS
1.4.関連組織への影響
プロジェクトを実施することによる関連組織へのポジティブ影響、ネガティブ影響の分析結果を明記する。 ☑︎今よりも使い勝手の良いシステムになる（悪くなる）。 ☑︎今よりも業務ボリュームが増える（減る）。 ☑︎新たなシステムの導入や修正があるか。
🗒 memo プロジェクトの目的は、分かっているようで分かっていないPMが多いものです。 お客さまの考えている目的と、あなたの意識している目的に乖離があるとプロジェクトは炎上します。 そんなことにならないように、こちらを参考にしてください↓
WHAT
2.プロジェクトスコープ
2.1.対象業務と2.2.対象システム
お客さまの要求事項を明記する。 ☑︎対象となる業務に対するビジネスニーズをまとめる。 ☑︎対象となる業務の効率を良くするためのシステムニーズをまとめる。
2.3.プロジェクト対象外
プロジェクトの除外事項を明記する。 ☑︎お客さまとの齟齬・誤解・誤認識を防ぐために対象外の作業をまとめる。 ☑︎境界線上にある曖昧な作業をまとめる。
2.4.プロジェクト成果物 プロジェクトの成果物を開発工程単位で明記する。 ☑︎システム化範囲を対象に成果物を一覧としてまとめる。 ☑︎WBSの第3階層目のワークパッケージを洗い出し順序を設定する。
🗒 memo スコープは、お客さまの要望をどこまでプロジェクトに取り込むかを決めます。闇雲にお客さまの『やりたいこと』だけをすスコープ対象にするとスケジュール・コストを圧迫することもあります。 スコープは優先度を意識してください。 スコープの優先度の決め方については、こちらを参考にしてください↓
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.開発工程の品質基準
開発工程における合格基準を明記する。 ☑︎画面入力・バッチ処理のレスポンスタムを設定する。 ☑︎設計・テスト工程の品質基準を設定する。
🗒 memo
品質を上げるには、とにかくテストの量を増やすことが大事なことは、貴方も承知の上ですよね。 しかし、テストを増やすことで品質はどんどん良くなるのでしょうか？ 品質とコストのバランスって大事です。品質とコストの関係を関連記事で確認してください↓
7.2.受入工程の品質基準
ユーザーテスト（お客さま受け入れテスト）の合格基準を明記する。 ☑︎テスト消化・不具合の修正、要望の達成度合いにおける品質基準を設定する。
8.プロジェクト目標
8.1.品質目標
プロジェクトの品質目標を明記する。 ☑︎品質に関わる部分から絶対条件になり得る数値。
8.2.コスト目標 プロジェクトのコスト目標を明記する。 ☑︎お客さまがプロジェクトを行うために妥当と考えている費用。 ☑︎プロジェクト予算の上限。
8.3.スケジュール目標
プロジェクトのスケジュール目標を明記する。 ☑︎スケジュールに関わる部分から絶対条件になり得る日付。 （マイルストーン、他プロジェクトのクリティカルタスクも対象と考える）
HOW
9.マネジメント計画
マネジメント計画は、母体組織となるプロジェクトマネジメント・チームの管理方針と実行方法を記述します。 9.1.品質マネジメント計画
(1)マネジメント方針 品質マネジメントに関する当プロジェクトの特徴や当プロジェクトにおける方針を明記する。 (2)品質計画
どの品質規格がそのプロジェクトに関連するかを特定し、どのようにそれを満足させるかを明記する。 また、品質マネジメントチームの役割・組織体制・権限・責任及び品質尺度と品質ベースラインを明記する。 (3)品質管理 品質管理の方法・レビュー対象成果物・レビュー合格基準・評価分析と言った品質をどのように監視コントロールするのかを明記する。 9.2.コストマネジメント計画 (1)マネジメント方針 コストマネジメントに関する当プロジェクトの