【目次】
・概要
・プロジェクト計画書の構成
・プロジェクト情報
- プロジェクトの概要
- システム構成
- 体制
- マスタスケジュール
・プロジェクト管理計画
- スコープ管理
- スケジュール管理
- コスト管理
- 品質管理
- 資源管理
- コミュニケーション管理
- リスク管理
- 調達管理
- 統合管理
・プロジェクト運営
- 進捗管理
- 課題管理
- リスク管理
- 仕様変更管理
- 不具合管理
- 構成管理
概要
プロジェクト計画書はプロジェクトをどのように遂行するのか取り決めるための設計図です。
プロジェクトを遂行するときには規模により作成する粒度は異なりますが、プロジェクト計画書は必ず作成します。
このプロジェクト計画書を毎回フォーマットから作成するのは非効率であり、読む側としても何が書かれているかわからないので大変です。
一般的には過去のプロジェクトから流用できれば活用し、新規プロジェクトの場合は計画書テンプレートをベースにして作成します。
会社など組織で統一されたフォーマットがあれば、そちらを活用すると良いでしょう。
しかしフォーマットが使用できなかったり、規定フォーマットだけでは情報が足りないと感じる場合もあります。
そこでPMBOKをベースとしたプロジェクト計画書のフォーマット案を解説します。
こちらを参考にしながらプロジェクトの特性に合わせて取捨選択したりカスタマイズ（テーラリング）して活用ください。
プロジェクト計画書の構成
プロジェクト計画の全体構成を記します。
１．プロジェクト情報
１－１．プロジェクトの概要
１－２．システム構成
１－３．体制
１－４．マスタスケジュール
２．プロジェクト管理計画
２－１．スコープ管理
２－２．スケジュール管理
２－３．コスト管理
２－４．品質管理
２－５．資源管理
２－６．コミュニケーション管理
２－７．リスク管理
２－８．調達管理
２－９．統合管理
３．プロジェクト運営
３－１．進捗管理
３－２．課題管理
３－３．リスク管理
３－４．仕様変更管理
３－５．不具合管理
３－６．構成管理
これらの目次からプロジェクトを推進するうえで必要な情報を選択して作成します。
プロジェクトの規模により必要な情報を選択しますが、「１．プロジェクト情報」はプロジェクト遂行するための基本情報なので必ず作成します。
未確定情報がある中で作業着手する場合、いつ確定するのか計画書に明記する必要があります。
この構成はPMBOKの知識エリアをベースとしています。
PMBOKでは「ステークホルダー管理」という知識エリアがありますが、ここでは含んでいません。
ステークホルダー管理はプロジェクト全体で管理するというより、プロジェクトマネージャが内部管理用で使用するためです。
プロジェクト情報
プロジェクトの概要
プロジェクトの基本情報を記載します。
プロジェクトの目的と狙いは、人に伝えることを意識して記載します。
新メンバが参画したときに、全員で同じ方向にベクトルを合わせるための指針となります。
| プロジェクト名 | プロジェクト名称 |
| 作業期間 | プロジェクトの作業期間 |
| 予算規模 | プロジェクトの予算（金額）、人月などの規模 |
| プロジェクト分類 | 組織内でプロジェクトを比較しやすい分類を設定 「請負、準委任」「業務開発、投資案件」など |
| 難易度 | 組織内でプロジェクトを比較しやすい分類を設定 「高、中、低」など |
| セキュリティレベル | システムが要求されるセキュリティレベルを設定 セキュリティインシデント発生したときの社会的影響で選択 |
| プロジェクトの目的と狙い | このプロジェクトを行う業務観点の目的と狙いを記入。 受注したベンダが作成する計画書だとしても、ここで記述するのはユーザ視点である必要がある。 それとは別にベンダ内の目的と狙いがあれば別枠で記載する。 |
システム構成
システム構成図は、システム全体を俯瞰して理解できるように、関連する機器を記載し、ネットワークの線を記載します。
全体像を理解することが目的なので、物理的な詳細情報ではなく概略図で表現します。
プロジェクトでは複数人で動くため、自分たちが何を作るのか全体イメージを統一させる必要があります。
ここではプロジェクトの保有する機器だけでなく、連携するシステムや機器も記載します。
外部システムとの仕様検討やテストなど、システム構成図を見ながら検討することになります。
システム構成図の他に、ネットワークに重点を置いたネットワーク構成図もあります。
こちらは、結線の冗長化、スイッチ、LANケーブルのポート位置、IPアドレスやエイリアスなどの情報を表記します。
体制
組織内の体制図を作成して役割と指揮命令系統を定義します。
作業範囲や責任が不明確になると、誰から指示をもらえばよいか、誰に報告すればよいかわからなくなります。
また体制図の作成にはポイントがあります。
指揮系統は一本化する
１つのチームに複数の人から指揮・命令が出るような体制はＮＧです。
複数人から違う指示が出た場合、どの作業を、どの順番で対応すればよいかわからず現場は混乱します。
指示を出す側も作業量の把握ができないため、作業を出すごとに作業者とタスク調整することになります。
縦方向の担当兼務は避ける
担当者が複数の役割を兼務することはあります。
横の位置でつながっている役割を兼務することも好ましくありませんが、縦の位置にある役割を兼務することは避けるべきです。
例えばプロジェクトリーダが特定のサブシステムのチームリーダを兼務するのは危険です。
作業量は下位のタスクに引きずられることが多いため、チームリーダの作業が手一杯でプロジェクトリーダの役割を果たせなくなります。
また他のサブシステムと比べて自身のチームに注力する傾向が多く、他チームから不公平感があるとクレームが出ることもあります。
マスタスケジュール
マスタスケジュールは、プロジェクト全行程を表現することで、プロジェクトがどのように進んでいくのか、いつ完了するのか明確化します。
また、現在のプロジェクト進捗が予定通りなのか、前倒し／遅延しているのかを確認するためにも利用されます。
このマスタスケジュールには、マイルストーンも表記することを忘れてはいけません。
マイルストーンとは、プロジェクトにおける中間目標地点やイベントなど、スケジュールの目標となるポイントを指します。
マスタスケジュールを作成するときは、マイルストーンと整合性が取れているか確認します。
プロジェクト管理では、WBS作成してタスク単位でスケジュール管理するのですが、このマスタスケジュールと合うように計画を立てる必要があります。
注意点として、WBSは作業状況によりスケジュールの見直しは適宜行いますが、マスタスケジュールを変更することはプロジェクト計画変更という扱いになります。
そのため、プロジェクト計画変更ルールに則った手続きが必要になるので、容易に変更できません。
プロジェクト管理計画
プロジェクト管理計画の章では、実際にプロジェクト推進するための取り決めや管理方法について定義します。
スコープ管理
プロジェクトやフェーズごとに作成する成果物を定義します。
ここで定義したスコープは「スコープ・ベースライン」となり、成果物の基準値となります。
プロジェクト計画段階で何を作るのか定義して全体合意を取ります。
このスコープ・ベースラインを変更するということは作業範囲が変更になることのため予算の見直しも含めて変更管理します。
社内開発であれば予算追加、受注開発であれば再見積もりなどの対応を検討します。
上記の表は成果物スコープのサンプルです。
それ以外にも、スコープ管理では以下の内容についても定義します。
- 成果物の受入・完了基準
- 制約事項
- 前提事項
- 除外項目
スケジュール管理
プロジェクトの進捗管理方法を定義します。
管理対象はマスタスケジュール、およびWBSといった詳細スケジュールであり、予実管理の方法と変更に関する考え方や手続きを明記します。
進捗の管理方法
プロジェクトの進捗状況を把握するための管理方法を計画します。
詳細スケジュールをどのように管理するのか、進捗報告を受けるのかを明確にします。
詳細スケジュールを管理するのは、Excel、ツール、サービスなど様々な方法があります。
どのような方法でも一長一短はあるので、プロジェクト特性に合った方法を選択します。
また進捗状況を確認するために、チーム内のスケジュール更新ルール、進捗報告のフォーマットを決めるといったルールも作成します。
マスタスケジュール変更
マスタスケジュールはプロジェクト計画の範疇であり、プロジェクト全体に影響するため勝手に変更することができません。
プロジェクト計画変更の手続きに則り、変更後の計画で問題ないか上位層の承認を得る必要があります。
マスタスケジュールを変更するのであれば、関係するステークホルダーの予定にも影響を与えることになります。
計画変更の審査を行う前に、あらかじめ変更後のスケジュールで問題ないことを確認している必要があります。
コスト管理
プロジェクトを完遂するために、必要となる見積もりと予算設定、コストの予実管理を行います。
まず、コスト・マネジメント計画を作成します。
ここでは、プロジェクトで発生するコストについての大枠を洗い出し、コスト算出の方法を検討します。
人件費、機器、ライセンスであったり、ツールやプロジェクトルームなど様々なものが考えられます。
次に、想定するコストを算出し、予算設定を行います。
アプリケーション開発であれば、各工程作業の山積みを算出したり、類推見積もり、FPなどの係数モデル見積もりがあります。
そして予算設定をするのですが、そこにリスク費用、マネジメント予備を忘れずに盛り込みます。
リスク費用は想定リスクに対する対策の費用であり、プロジェクトマネージャが管理します。
マネジメント予備は「未知の未知」に対する予算で、まったく想定外の事態が発生した場合の費用であり、スポンサーが管理します。
プロジェクト開始したらコスト・マネジメント計画に則り、コストの予実管理を行います。
規模の大きいプロジェクトの場合、人の出入りが多く人件費のコスト管理が非常に難しいので、EVMの活用を検討します。
品質管理
成果物に対する品質管理について定義します。
品質を分析するためには、あらかじめ品質の指標値と評価方法を設定します。
指標値は、例えば次のような基準値です。
設計書 ：ページ当たりに発生する指摘発生件数
プログラム：KLineあたりの不具合発生件数
開発言語や業務をもとに過去のプロジェクト実績から指標値を算出します。
これらの情報がない場合、IPAのデータ白書を活用することもあります。
品質分析については別の記事で解説しているので参考にしてください。
資源管理
資源管理ではメンバなど人的資源、および機材などの物的資源の管理を定義します。
物的資源についてはPCやソフトウェアのライセンス、プロジェクトルームなど設備や環境で必要なものを整理し、手配方法や時期について明確化します。
社内メンバを活用する場合は、組織内で交渉することもあるでしょう。
もし資源を外部から調達する場合は「調達管理」で実施します。
外部のパートナー会社からメンバを集う場合も該当します。
資源管理では、上記のように社内外から調達するだけでなくチームの育成、マネジメントも行います。
チーム育成によりプロジェクトのパフォーマンスは向上するので、教育などの育成計画を立てます。
コミュニケーション管理
会議体を設定し、「いつ開催する」「誰が参加する」について定義します。
どのような会議が必要なのか検討し、参加者の合意を得る必要があります。
会議で必要な資料や議事録作成の担当といったルールも明確にします。
リスク管理
プロジェクトには何かしらリスクが発生します。
このリスクを完全に無くすことは出来ないため、リスクをコントロールしてプロジェクトを完遂させることが重要になってきます。
そのためリスク顕在化の抑止や発生時の対策を事前に検討します。
このリスク管理はプロジェクト計画段階から始まり、プロジェクト遂行中も継続して監視・メンテナンスを行います。
リスク管理の流れは次の通りです。
※リスク管理については「リスクマネジメント計画」でも解説しています。
①リスクの特定
プロジェクトで、どのようなリスクが発生するのか洗い出します。
過去の類似プロジェクトで作成したリスク管理簿を流用すると効率的です。
プロジェクト特性による注意点であったり、有識者に想定されるリスクをインタビューすることも効果的です。
チームメンバと話し合うことで、担当者視点からの気づきを得ることができるかもしれません。
気になる、不明瞭、自信がない点はリスクにつながりやすいので抽出していくと良いです。
②リスクの定性／定量分析
①で洗い出したリスクに対して、リスク分析を行います。
分析は「定性分析」「定量分析」の2つがあります。
定性分析
リスクごとに発生確率と影響度を「高・中・低」レベルで設定します。
発生確率が高く、影響度も高いものはリスク対策の優先度が上がります。
ちなみに「隕石が降ってくるリスク」のように、考えても仕方ないレベルのリスクがあれば除外します。
リスク管理において、定性分析は必ず実施します。
定量分析
リスクが顕在化したときに、対策にどれくらいのコストと期間が必要なのか、具体的に数字を算出します。
この数字をもとに、リスク対策を分析したりリスク費の算出を行います。
例えばリスク対策のコストが大きい場合、他の対応策を検討したり、顕在化しないための抑止に注力するなどの検討にもつながります。
定量分析は、調査・検討、情報の最新化に時間がかかるので実施しないプロジェクトが多いです。
定量分析はプロジェクトの規模や難易度により実施有無を判断します。
③リスク対策の計画
リスク顕在化の予防策、また顕在化した場合の実施策を計画します。
リスク対策は「回避」「転嫁」「軽減」「受容」のいずれかに分類されます。
回避
リスクをプロジェクトから無くしたり、顕在化しないための方法です。
ただし、回避した先に新しいリスクが発生する場合もあるため注意が必要です。
対策の結果、新しいリスクが発生することを「２次リスク」と言います。
転嫁
回避と似ていますが、第三者にリスクを渡すものであり、影響そのものは消えません。
保険を例としてあげると、わかりやすいでしょう。
軽減
リスク顕在化したとき、その影響を減らすための対策です。
実施したとしてもリスクを完全に消すことは出来ず、リスクや対策が残ります。
これを「残存リスク」と言います。
受容
リスク顕在化したときの対策を計画せず、そのまま受け入れます。
対策を事前に計画することが難しかったり、発生しても影響が小さいリスクの場合に選択します。
④リスク対策の実施
リスクが顕在化したときに、リスク管理で計画していたリスク対策を実施します。
そこで大切なのが、リスク対策を実施後の結果を確認することです。
完全にリスクを排除できず残る「残存リスク」、もしくは対応策を実施したら新しいリスク「２次リスク」が発生する可能性もあります。
もしリスク対策を継続的に実施し続ける場合、その作業はリスク管理から課題管理に移管します。
リスクは不確定の発生事象のことであり、顕在化したリスクは「問題」扱いになります。
⑤リスク監視
工程が進むにつれて、リスクが削除されたり新しく追加されることもあります。
プロジェクト状況が変わることでリスク有無や対策も変わります。
またリスクが顕在化していないのか、プロジェクト状況を定期的にモニタリングする必要もあります。
リスク管理を適切に運用するには、プロジェクト計画に作ったまま放置するのではなく、プロジェクト状況を監視してメンテナンスすることが重要です。
リスク監視、メンテナンスの実施方法については、プロジェクト計画時に運用ルールを策定します。
調達管理
プロジェクトのために外部から調達する場合の方法を定義します。
調達する対象はサービスや製品などありますが、外部に開発作業を発注することも含まれます。
その場合は入札文書の作成や発注先の選定、契約方法の決定など含めます。
統合管理
プロジェクトの進め方、管理の運営方法、プロジェクト計画の変更に関する運用ルール、プロジェクト終結について定義します。
ここでいうプロジェクト計画の変更とは以下の変更も含まれます。
- スコープ・ベースライン
- スケジュール・ベースライン
- コスト・ベースライン
スコープ・ベースラインが含まれていることからわかるように、仕様変更も該当します。
仕様変更する場合の運用ルールも定義し、全体合意を取る必要があります。
プロジェクト運営
プロジェクトを円滑に推進するため、各種ルールを設定してプロジェクト全体の共通ルールとします。
そのためプロジェクトに参加するメンバには必ず共有する必要があります。
もしルール変更する場合はプロジェクト計画書を修正したうえで関係者に共有します。
以下に、プロジェクト運営で定義することが多いルール設定を記載します。
これ以外にもプロジェクト特性を考慮しながら必要な運営ルールを検討します。
進捗管理
プロジェクトの進捗に関する運営ルールを設定します。
進捗情報は適切にルールが設定されていないと正しい実績情報が収集できないので、チーム内で無理なく運用できる方法を検討します。
進捗管理表のサンプルフォーマット
WBS更新ルール
・予定の更新ルール
詳細スケジュールの作業予定を誰が、いつ更新するのかルールを設定します。
各担当者が自由に予定変更できる状況だと、スケジュールの統制が取れなくなるので予定日や担当者の割当を設定するのはチームリーダなど限られた人だけに絞ります。
・実績の更新ルール
詳細スケジュールの実績を誰が更新するのか、いつ最新化するのかルール設定します。
進捗報告会などの報告タイミングから遡って最新化するタイミングを設定することが多いですが、日次で進捗状況を把握したい場合は１日の作業終了時点で更新することもあります。
入力タイミングが明確になっていないと、都度メンバに最新化の依頼を出すことになり運用が煩雑になります。
進捗率の定義
進捗率は未着手だと0%、完了したら100%となりますが、途中段階の進捗率をどのように設定するのかルールを決めます。
担当者任せにすると人によって入力がバラバラになり、進んでいるのか遅延しているのかわからなくなります。
入力の仕方によって作業は進んでいるのに進捗率90%が何日も続いてしまうこともあります。
そのため定量的に判断できるように目安を設けます。
例）
・作成開始：20% 作成完了：50% レビュー中：80% レビュー完了：100%
・全体の作業項目数と実施済の項目数から割合を出す
など
進捗報告手順
進捗報告の資料作成、および会議の流れを明確にします。
どのタイミングで誰が進捗情報を収集／分析して、報告書にまとめるのか等のルールを設定します。
進捗報告会に向けた事前送付の有無、添付資料の取り決めなどのルールも決めます。
ちなみに進捗報告の開催日や参加者などの会議体設定はコミュニケーション管理で行います。
課題管理
プロジェクトを進めていると予定外の作業や検討事項、タスクが発生します。
この課題を見える化しないと対応漏れやメンバ間の認識齟齬などトラブルにつながるため、課題管理表を作成して管理します。
課題管理表のサンプルフォーマット
課題更新ルール
課題管理表の登録、およびチェックするルールを設定します。
特に課題管理の状況を定期的に棚卸しないと、課題管理が形骸化します。
課題対応も担当者を割り当てたから終了ではなく、対応状況が正しいのかも含めて管理する必要があります。
また課題の優先度付け、担当割り振りの仕方、課題の期限設定を必須にするなどのルールも取り決めることで、課題管理は運用しやすくなります。
内部課題／客先課題の取り扱い
課題にはチーム内だけの課題だけでなく客先との課題を管理することもあります。
その場合、内部用と外部用で課題管理を分けるのか、または１本化するか等のルールを検討します。
別々に分けると管理が煩雑になるのですが、１本化すると客先に見せられない課題を記載できないなどの問題もあります。
プロジェクト特性によって運用ルールを決定します。
リスク管理
プロジェクト計画時にリスク管理表を作成しますが、そこで定義したリスクが顕在化していないか、また新たなリスクが発生していないかチェックするルールを決めます。
このルールを設定しないとリスク管理が放置されてしまうので注意してください。
リスク管理表のサンプルフォーマット
リスクの監視と判定
リスク管理表では、リスクごとに顕在化のトリガーを設定しています。
そのトリガーが発生していないか、または発生する予兆がないかチェックします。
このチェックを頻繁に行うルールにすると負荷が高いので、月次など可能な範囲でチェックするタイミングを設けます。
リスク情報更新ルール
リスクが顕在化した場合、その事象はリスクから問題に変更されます。
その場合、リスク管理表から課題管理表に移管するなど取り扱いルールを設定します。
また工程が進むことでリスクがなくなることもあります。
リスクをクローズしてよいか、チーム内の承認ルールを設定します。
仕様変更管理
発生した仕様変更を管理して変更対応の漏れを防ぎます。
また仕様変更は対応有無にかかわらず管理対象とします。
変更には工数が発生するため、他の仕様変更案件と比べて何を対応するのか調整することもあるので、これらの仕様変更を的確に処置するためにも運営ルールが必要になります。
仕様変更管理表のサンプルフォーマット
仕様変更管理ルール
仕様変更管理台帳への記入ルールなど設定します。
ここで管理するのは対応することが決まった仕様変更だけでなく、未対応のものでも調整対象に上がったものはすべて記録します。
今は対応しなくても将来的に別途対応することになる可能性があります。
その時になぜ取り込まなかったのか記録を残すことで、後日同じような相談があったときに反応することができます。
また仕様変更の対応要否をいつ調整するのか、承認者は誰なのか、予算取りなどの手順もルール化します。
不具合管理
設計書レビューの指摘事項、またはテストで検知した不具合の管理ルールを設定します。
不具合管理表のサンプルフォーマット
レビュー記録表のサンプルフォーマット
不具合管理の運営ルール
発生した不具合をどのように管理するのかルール化します。
不具合管理一覧に誰が登録するのか、対応方法を承認する人やタイミングについて設定します。
また不具合情報は品質分析するための重要な諸元データにもなるので、原因区分などの設定ルールも定義します。
構成管理
プロジェクトで作成した成果物の管理ルールを設定しないと、どこに何が格納されているかわからなくなるだけでなく、成果物の紛失、複数人が更新することによるデグレードなどの問題が発生します。
また成果物のバージョン管理も構成管理での重要な役目です。
構成管理システム
プロジェクト管理資料などは共有サーバなどで管理することはあるかもしれませんが、設計書やプログラムなどの成果物はgitやsvnなどの構成管理ツールを使用するのが一般的です。
どのようなツールを使うか、そのツール環境について定義します。
この構成管理システムがトラブルなどでデータ消失しないよう、レポジトリのバックアップ運用も忘れずに検討します。
構成管理対象
基本的に成果物は構成管理ツールを使用しますが、WBSや進捗報告資料のようなプロジェクト管理資料まですべて構成管理ツールで管理するのは非効率です。
そのため、どの成果物を構成管理の対象とするのか設定します。
基本的にはバージョン管理が必要なドキュメントやファイルが対象となります。
構成管理手順
構成管理ツールへの登録、および払い出しのルールを設定します。
特に他メンバと更新対象のファイルが競合する場合の運用ルールを正しく設定しないとデグレートなどのトラブルにつながるので、しっかりとルールを検討する必要があります。
プロジェクト計画書については以上となります。
プロジェクト管理の全体については「プロジェクト管理の全体解説」を参考にしてください。
