やっと見つけた❗️初めてPMをやる人が欲しいプロジェクト計画書

writing by Yuichiro Hayashi *このコラムはiPM naviで配信しています


ご存じでしたか? IT業界で働いているZ世代の二十代の5人に一人は、何らかのプロジェクトマネジメント勉強をしています。 なかでも、プロジェクト計画書を作り上げるトレーニングを繰り返しやっている人は、PMの業務に着いても立ち上がりが早く、クライアントからの評価も高いんですね。 そのコツは? それは10,000人以上が読んだ、この記事で答えが見つかります♪

 

監修:プロコンサル MASA 2004年に大手コンサルファームBにジョイン。大手事業会社をクライアントに持ち、クライアント社内で活用する品質マネジメント基準・開発プロセス基準の策定に従事。また、PMOとしてクライアントのプロジェクト推進及び品質維持に貢献しプロジェクトを成功に導いた。 2016年に大手コンサルファームMにジョイン。 大手エネルギーインフラ会社のガバナンス部門にて、大規模システム開発プロジェクトのマネジメント品質管理に従事。PMOとしてプロジェクト運営における問題点の可視化とプロジェクトマネージャおよび上位層への改善提案によりプロジェクトを成功に導いた。 MASAのコラムを読む...

 

こんにちは、プロコンサルの林 雄一郎です。 私が参加しているiPMでは、PM初心者のスキルアップやDX時代に適応したいPMのリスキリングのサポートとして、iPM TRAININGを運営しています。 このコースの一つとして、『プロジェクト計画書の作り方』を講座として提供しています。 今回のコラムは、PMであれば絶対に知っておきたいプロジェクト計画書を作る手順・各目次に沿って何を記載するのかを解説します

 

林 雄一郎のキャリア 2000年に大手コンサルファームBにジョイン。

同社の創業時からパートナーとして、セールス・コンサルティングとあらゆる組織で活躍しビジネスの拡大に貢献。

2005年にコンサルファームを設立。

総数2,000以上のプロジェクトに携わり、経験したプロジェクトの検証と分析から『現場で使えるノウハウやリスク情報』を法人顧客やフリーランスPMOに提供。

2020年に大手クラウドソーシング 取締役としてジョイン。大手コンサルファームBでのセールススキルを活かして同社スタートアップサービスの拡大に貢献。

 

こちらは、『プロジェクト計画書の目次』になります。

あなたが使っている目次と比べて、過不足があったら教えてくださいね😀

さて、初めてPMをやる人って、プロジェクト計画書を作るのに苦戦するものです。 今回は、誰でも簡単にPJ計画書が書けてしまうメソッドを披露したいと思います😀 そんな魔法みたいなことってあるの?と感じるかもしれません!

そのようなものはないんですね。 きちんと手順を押さえて、ルールに従って作っていけば矛盾のない計画書が書けます。 それでは、スタートします。


【無料プレゼント】 大手コンサルファームでも使われるプロジェクト計画書のリアルサンプルがダウンロードできます。 ダウンロードするには、iPM naviにアクセスして『method』メニューから”プロジェクト計画書(リアルサンプル)”ボタンをタッチしてください↓

*ここからのダウンドーロは2022年10月28日(金)までとなります。これ以降にダウンロードをした方は、iPM naviの無料メンバーに登録してコミュニティからダウンロードしてください。

 

【重要】プロジェクト計画書の3つの要素

実は、プロジェクト計画書って大きく3つの要素で構成されています。 ・WHY(なぜプロジェクトを行うのか) ・WHAT(どのような作業を行なって、どんな成果物を作るのか) ・HOW(成功に導くための手段や方法) このような特徴を一冊にまとめています。

プロジェクト計画書は、この3つの要素に対して、PMが知恵を振り絞って苦労しながら作り上げていく言わば「芸術品」なんです。 また、この3つの構成が一つになった時にプロジェクトをスタートすることができます。 そして、計画書に従ってPMはプロジェクトを運営しなくてはなりません。 正しい知識で作られたプロジェクト計画書は、成功への第一歩を踏み出せたと言っても良いでしょうね。 初めに見てもらったプロジェクト計画書の目次に沿って、何をどのように記述すれば良いのかの『ポイント』を解説していきます。 ちゃんとポイントを押さえれば、簡単にPJ計画を書くことができます😀


1.プロジェクトの目的

1.1.プロジェクト立ち上げ経緯

お客さまの業務環境と課題を調査し明記する。 ☑︎プロジェクトの誘因となる市場の要求 ☑︎ビジネス・ニーズ ☑︎お客さま要求 ☑︎技術の進歩 ☑︎法的要求 ☑︎社会的ニーズ

1.2.目的

なにを実現するためのプロジェクトなのかを明記する。 ☑︎なにを手に入れたいのか、手に入れたことでなにがハッピーなのかを明確にする。 ☑︎お客さまの便益とプロジェクト活動が結びつくようにする。 ☑︎目的を数値化する。


1.3.プロジェクトの妥当性

プロジェクトの投資効果を分析した結果を明記する。 ☑︎ROI ☑︎ROA ☑︎ROE ☑︎ORS

1.4.関連組織への影響

プロジェクトを実施することによる関連組織へのポジティブ影響、ネガティブ影響を分析した結果を明記する。 ☑︎今よりも使い勝手の良いシステムになる(悪くなる) ☑︎今よりも業務ボリュームが増える(減る) ☑︎新たなシステムの導入や修正があるや


🗒 memo プロジェクトの目的は、分かっているようで分かっていないPMが多いものです。 お客さまの考えていつ目的と、あなたの意識している目的に乖離があるとプロジェクトは炎上します。 そんなことにならないように、こちらを参考にしてください↓



↑ここまでが『WHY』に当たる部分となります。


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階層目のワークパッケージから主要なマイルストーンを設定する。


🗒 memo 多くのPMは、マイルストーンにイベント(例:リリース、XX工程終了)を設定しています。実はこれって間違いなんですね。 本来のマイルストーンの意味を忘れないでくださいね。 マイルストーンに重要なことを設定しなかったことで、炎上したプロジェクトの実例です↓

4.2.マスタースケジュール

所用期間が求められた全てのワークパッケージからスケジュールを作成し明記する。 ☑︎WBSの第3階層目のワークパッケージ単位に作業を完了させるための所用期間を見積もる。


5.プロジェクト体制

5.1.スキル一覧

ワークパッケージ単位に必要なスキルを洗い出し明記する。 ☑︎ワークパッケージ単位に類似プロジェクトを元にして必要スキルを設定する。

5.2.要員計画

要員計画を明記する。 ☑︎要員の着任と離任のタイミングを計画する。

5.3.プロジェクト体制図

プロジェクトチームに着任する予定のメンバを含めた体制を明記する。 ☑︎指揮命令系統がわかるように体制図はツリー型にする。


🗒 memo スムーズにプロジェクトを進めるには、お客さまにも体制を組んでもらう必要があります。 それでは、どんな体制にしてもらえれば? お客さまを巻き込んだ組織体制の重要性を、こちらの記事で確認してください↓


6.プロジェクト予算

プロジェクト予算の内訳と合計を明記する。 ☑︎ハードウエア費用 ☑︎ソフトウエアライセンス費用 ☑︎開発費用 ☑︎予備費用


7.品質基準

7.1.開発工程の品質基準

開発工程における合格基準を明記する。 ☑︎画面入力・バッチ処理のレスポンスタムを設定する。 ☑︎設計・テスト工程の品質基準を設定する。


🗒 memo

品質を上げるには、とにかくテストの量を増やすことが大事なことは、貴方も承知の上ですよね。 しかし、テストを増やすことで品質はどんどん良くなるのでしょうか? 品質とコストのバランスって大事です。品質とコストの関係を関連記事で確認してください↓

7.2.受入工程の品質基準

ユーザーテスト(お客さま受け入れテスト)の合格基準を明記する。 ☑︎テスト消化・不具合の修正、要望の達成度合いにおける品質基準を設定する。


8.プロジェクトの目標

8.1.品質目標

プロジェクトの品質目標を明記する。 ☑︎品質に関わる部分から絶対条件になり得る数値。

8.2.コスト目標 プロジェクトのコスト目標を明記する。 ☑︎お客さまがプロジェクトを行うために妥当と考えている費用。 ☑︎プロジェクト予算の上限。

8.3.スケジュール

プロジェクトのスケジュール目標を明記する。 ☑︎スケジュールに関わる部分から絶対条件になり得る日付。 (マイルストーン、他プロジェクトのクリティカルタスクも対象と考える)


↑ここまでが『WHAT』に当たる部分となります。



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)リスク管理 リスクの評価分析方法を明記する。


🗒 memo リスクを洗い出していくと、どんどん出てきませんか? リスク事象が多すぎて、うんざりすることもあります。 そんな時は、優先度を決めておきましょう! リスク事象の洗い出しと優先度の設定はこちらを読んでください↓



↑ここまでが『HOW』に当たる部分です。 プロジェクト計画書を作成するうえで、とても重要であり難しい部分でもあります。


プロジェクト計画書って、どのようなもので、なにを書けば良いのかを解説してきました。 この記事を読み終わろうとしている、あなたはPJ計画書の根本的な知識を得ました。 貴方の次の行動は、”プロジェクト計画書を最速で正しく作るノウハウと作成するときに必要とする大手コンサルファームのコンサルが使うメソッド”を覚えてくださいね。 しかし、独学でこれらを身に付けるのは大変難しいです。 そのようなときは、iPM TRAININGをご利用くださいね。 iPM TRAININGでは、オンラインサロンで『プロジェクトマネジメント講座』とプロコンサルのメンタリングを行なっています。 iPM TRAININGは有料ですので、初めはiPM navi(無料)で、『お悩みから解決策を探す』、『新着コラム』を使って、大手コンサルファームならではのノウハウやメソッドを取り入れてみてください😀


最後まで読んでくれて有難う御座いました。

 

わたしのコラムで、あなたのお役に立てれば幸いです。

プロジェクト計画・管理・PMの裏ワザ、こんなようなコラムを配信していこうと思ってます。

ぜひ、今後とも応援を宜しくお願いします。

*Back Numberはこちらです↓