プロジェクトの計画
プロジェクトマネージャ試験のシラバス － 情報処理技術者試験における知識・技能の細目 － Ver. 6.0 の大項目「2 プロジェクトの計画」についての記述である。
2-1 システム開発方針の設定
プロジェクトの目標及び要求事項を満たすための成果物の開発計画並びに実装に適応するための開発手法を決めて，これに対応した適切なプロジェクトフェーズの設定及び適切なプロジェクトマネジメントのプロセスの選択ができるようにする。
システム開発においては，開発対象システムの特徴，予算，期間，作業効率及び品質を考慮し，開発対象システムに適合するシステム開発ライフサイクルモデル，システム開発手法，開発環境，品質保証・構成管理・文書化などの開発標準を決定する。さらに，システムを運用及び保守して顧客にサービスを提供するリリース作業に関わるシステム開発プロジェクトの範囲を決める必要がある。その上で，迅速なシステム開発やシステムのリリースのために，開発における自動化を促進することも必要となる。
2-2 プロジェクト全体計画の作成
スコープ，時間，コストなどのマネジメントの対象に関して全体調整を図り，一貫性のある実行可能な計画として統合し，プロジェクト計画及びプロジェクトマネジメント計画として文書化する。
プロジェクト計画には，プロジェクトの目標，プロジェクトを遂行するベースラインとしてスコープ，スケジュール，コスト，品質，リスク及び資源，プロジェクトの評価指標の概要などについて記述する。プロジェクト期間を通じてプロジェクト計画は必要に応じて更新し，適正なステークホルダに伝達する。急激な変化，要求事項の不安定性，技術的な知識不足などの不確実性によってプロジェクトライフサイクル全体の予測が困難な場合には，その時点の環境を前提として可能な限り最良の方法で価値
を創成するようなプロジェクト計画とする。その際，その時点で確定していて早期に実施しなければならない作業は詳細に計画し，その時点で未確定で将来実施する作業は，概略を計画して段階的に詳細化することがある。
プロジェクトマネジメント計画は，スコープ，スケジュール，コスト，品質，リスクなどの対象のマネジメントにおける役割，責任，組織及び手順を必要に応じて定義する。計画どおりにプロジェクトを進めるために適切なプロセス，インプット及びアウトプットを選択し，各プロセスに適用する各種管理指標としての目標値や許容範囲，ツール，手法などを決定することによって，プロジェクトマネジメントのプロセスを適切に修整する。また，プロジェクトに影響を与えるプロジェクトの環境，変更要
求への対応方法，プロジェクトフェーズの終結の確認方法，プロジェクト完了後の評価指標の計測方法，ステークホルダによる成果物のレビュー方法や検収方法，プロジェクトの終結確認方法や，ステークホルダに対する進捗状況の報告などの情報の配布方法について記述する。
ロジェクト全体計画は上層の管理者に提出して承認を求める。上層の管理者は，内容を評価しステークホルダとも協議してプロジェクトの実行の是非を決定する。
2-3 スコープの定義
プロジェクトの範囲を定義することによって，目標，要求事項，成果物及び作業を含むプロジェクトスコープを明確にし，スコープ規定書や要求事項として文書化する。要求事項に不安定性があり，初期段階にスコープ定義の確定や顧客との合意が困難な場合は，段階的な要求事項の探索や合意形成などの対応が必要である。この対応において価値を確実に創成するためには，要求事項と創成する価値との関係性を明らかにして，要求事項の優先順位を決定する尺度を創成する価値の大きさとするなどの工夫も必要である。
プロジェクトスコープ規定書は，将来のプロジェクトの決定，並びにプロジェクトの重要性及びプロジェクトの遂行によって現実化する便益を伝達するためのベースとして使用する。
2-4 WBS の作成
プロジェクト計画及びプロジェクトマネジメント計画や要求事項に基づき，階層的に分割する手法でプロジェクトの目標を達成するために必要な作業を特定する。
ワークブレークダウンストラクチャ（WBS）は，プロジェクトフェーズで実施する作業を，成果物に基づき，管理しやすいより小さな作業に階層的に分割して作成する。
分割したWBS の最下位のレベルに定義される作業であるワークパッケージ（WP）ごとに，作業内容，成果物を設定する。WBS，WP，スコープ規定書をスコープベースラインとする。
計画時点で作成する予定の全ての成果物が確定できず，全ての作業をWP にまで分割できない場合は，成果物が確定されてから段階的に詳細なWBS を作成する。
プロジェクトの成果物，組織，リスク，コストなどに対して，それぞれ管理する目的に沿って階層構造のブレークダウンストラクチャが作成される。
2-5 活動の定義
プロジェクトの目標を達成するために，ワークパッケージ（WP）に対応してスケジュールに組み入れて実施すべき全ての作業を特定し，活動（アクティビティ）として定義し，活動リストとして文書化する。全てのプロジェクトフェーズで実施する作業を計画時点で確定できない場合には，段階的に詳細なWBS を作成し，確定したWP に対して活動を定義する。
活動リストは，プロジェクトの計画，実行，管理及び終結の作業の基準となる。
2-6 資源の見積り
活動リストの活動ごとに必要な要員，施設，機器，材料，インフラストラクチャ，ツールなどの資源を見積もって決定する。
初期段階で資源の見積りの精度が低く，ステークホルダとの合意が困難な場合には，プロジェクトの進捗によって段階的な見積りで精度向上やステークホルダとの合意を図るようにする。この対応のために見積り手法を初期は簡易なものとし，段階的に精度の高い手法に変えていくことがある。
次いで，各資源について適切な投入時期と投入量を決定する。これらを資源計画として文書化する。
2-7 プロジェクト組織の定義
プロジェクトに関係する全てのステークホルダから必要なコミットメントを得て，プロジェクトに関連する役割，責任及び権限を，プロジェクトの特徴及び複雑さに従って定義する。また，組織の迅速な意思決定に向けて，組織の枠にとらわれずに，ステークホルダとプロジェクトチームとで直接コミュニケーションできる共創関係となるように定義する必要がある。
プロジェクトチームの全ての構成員及びプロジェクトの作業に直接関係するその他の人々を特定する。また，プロジェクトの実行・管理を確実に実施する要員を選定し，ワークパッケージ（WP）に割り当てて，役割規定書で責任と権限を明確にする。
必要に応じて，外部の組織やプロジェクト外の要員などに対してシステム開発作業の一部を委託したり，情報の提供，技術的コンサルティング，レビュー実施の協力を要請したりする。また，迅速に顧客へサービスを提供するために，成果物の引渡しやシステムのリリース作業を，組織内でプロジェクトと定常業務組織でどのように分担するかを明確にする。
これらをプロジェクトの組織図として文書化する。
2-8 活動の順序付け
プロジェクトの活動間の論理的な関係を特定し，活動順序を文書化する。
プロジェクト内の全ての活動は，ネットワーク図（作業工程図）を用いるなどして，クリティカルパスを決定できるように関係を明らかにする。
活動は，現実的かつ達成可能なプロジェクトのスケジュールの作成のために，先行作業との適正な依存関係及び適正なリード，ラグ，制約，相互依存関係並びに外部との依存関係をもって論理的に順序付けする。
2-9 活動期間の見積り
プロジェクトの各活動を完了するために必要な時間を，活動期間の見積りとして文書化する。
活動期間は，利用できる資源の量と種類及び活動間の関係，能力，日程計画，学習曲線などの対象の影響を受ける。
活動期間は，時間の制約と資源の利用可能性との間のトレードオフとなる。ベースラインに照らして更新した予測に基づく定期的な再見積りも必要である。
活動期間の見積りは，クリティカルパスを特定したときに再考する必要がある。クリティカルパスによって，プロジェクトの完了期日が要求される完了期日よりも遅れることが明らかになった場合は，クリティカルパス上の活動を部分的に修正することが必要となる。
2-10 スケジュールの作成
プロジェクトの活動の開始時間及び終了時間を算定し，マイルストーンを設定して，プロジェクト全体のスケジュールのベースラインを確定する。プロジェクトの環境の急激な変化や高い不確実性などでプロジェクト全体を通したスケジュールの作成が難しい場合は，優先順位の高い要求事項に関わる活動のスケジュールを作成し，要求事項が確定するに伴って，段階的に該当する活動を定義してスケジュールの作成を行う必要がある。
スケジュールは，時間を基準とした実際の進捗を評価する手段である。進捗を測る尺度は，成果物の開発によって創成される価値とするなど，プロジェクトの特徴に合わせて設定する。
スケジュールの作成は，作業の進捗，プロジェクト全体計画の変更，予期するリスクの発生又は消失，及び新しいリスクの特定に応じて，プロジェクトを通じて継続して実施する。また，必要な余裕を考慮し，更に論理的に可能な実施期間の短縮，資源の平準化を図り，スケジュールとして文書化する。
2-11 コストの見積り
各プロジェクトの活動の完了及びプロジェクト全体の完了に必要なコストを見積もって文書化する。初期の段階で高い精度のコスト見積りが難しい場合は，初期にはコストの概算見積りを迅速に行う簡易な手法を用い，プロジェクトの進捗に伴い段階的に，より精度の高い見積り手法に変更するなどの対応が必要である。
活動別に，必要な要員と資源量や資源単価などを基にコストを積算し，プロジェクト推進に付帯して必要なコスト，リスクに備えた予備費又は引当金などを特定して，プロジェクト全体の完了に必要な総コストを得る。コストの見積りの精度が低い場合には，そのことを考慮して予備費を確保するとともに，あらかじめ予備費の使用に関する手順を定めておく。
総コストは，プロジェクトの立ち上げ時に与えられた経済面の制約，組織の予算の作成の方針を勘案して検証する。
2-12 予算の作成
プロジェクトの総コストをWBS の該当する適切なレベルに配分して，プロジェクト全体のコストのベースラインを確定する。コストの見積りがプロジェクトの総コストを決定するのに対して，予算の作成はいつどこでコストを使うかを特定する。
コストベースラインは，コストパフォーマンスをマネジメントする基準である。コストパフォーマンスを測る尺度は，成果物の開発によって創成される価値とするなど，プロジェクトの特徴に合わせて設定する必要がある。
経営層による管理又は特定したリスクに対応する目的で，必要に応じて活動又はその他の作業スコープに割り当てられない引当金又は予備費項目を作成する。
スコープや要求事項の頻繁な変更が想定される場合には，これらの変更に対応して予算をステークホルダと迅速に調整し変更できるように，手順をあらかじめ定めておく。
2-13 リスクの特定
プロジェクトライフサイクルにおいて，発生した場合にプロジェクトの目標の達成にプラスの影響を与えることのある潜在的リスク（機会），又はマイナスの影響を与えることがある潜在的リスク（脅威）及びその特性を決定する。
知識が不完全であるなどの不確実性が，プロジェクトの目標の達成に影響を与えるような場合は，漸進的な開発，プロトタイプ，シミュレーションなどの探索的な手法で不確実性の影響を段階的に最小化・局所化し，リスクとして特定し対応する。
プロジェクトの進捗に従って新たなリスクを認識したり，リスクが変化したりすることがある。したがって，リスクの特定は，反復的なプロセスである。特定したリスクはリスク登録簿に記録する。
2-14 リスクの評価
今後の処置のために，特定した各リスクの発生確率及びそのリスクが発生した場合にプロジェクトの目標の達成に与える影響を推定する。さらに，期間，主要なステークホルダのリスク許容度などのほかの要因を考慮した評価に従ってリスクへの対応の優先順位を定める。
リスクの評価は反復的なプロセスである。
2-15 品質の計画
プロジェクト及びプロジェクトの成果物に適用する品質要求事項及び規格，並びに顧客の満足度を明確にした上で，組織の品質方針や個別システム化計画からの所与の品質要求事項を勘案して，プロジェクトの品質要求事項や規格を満たす方法を確定する。要求事項に不安定性がある場合，要求事項を顧客と合意して実現しても顧客の満足度が上がらないおそれがある。このような場合，システムのリリースによって真の顧客の要求事項が認識されることがある。
したがって，要求事項に不安定性がある場合は，優先順位の高い要求事項に基づき開発したシステムをリリースして，顧客や顧客視点をもつステークホルダが要求事項を検証するなどの，段階的に顧客満足度を評価する対応が必要になる。
また，品質保証と品質管理の遂行方法，品質管理の指標を決定し，準拠すべき開発標準との整合を確認する。さらに，品質保証と関連の深い構成管理について計画する。
また，計画した品質マネジメントを実施するための方法論，技法及び資源を決定する。
プロジェクトのスケジュールに沿って，レビューの種類，責任及び参加者を含めて，全ての品質情報をまとめて品質計画として文書化する。
2-16 調達の計画
調達を開始する前に，調達の戦略及びプロセス全体を適切に策定し，調達計画として文書化する。組織として，コアとなる事業領域とそれ以外の事業領域を区別する戦略を採るような場合は，調達の計画に関しても事業領域の区分けに従って調達対象や契約形態を設定する必要がある。
作業効率，対応可能な要員，予算などを考慮し，システム開発要員，製品，サービスに関して供給者から調達する場合の意思決定が合理的に行えるように，調達のマネジメントの方法を規定し，調達仕様書及び要求事項を作成する。
2-17 コミュニケーションの計画
ステークホルダの情報のニーズ及び全ての法令要求に従った情報のニーズを特定する。また，そのニーズを満たすための適切な手段を明確にする。プロジェクトの環境の急激な変化や高い不確実性が想定される場合は，変化する状況をより頻繁かつ迅速に伝えるというコミュニケーションに対する要求事項がある。
地理的に分散した要員，多様な文化などの要因及び組織的要因は，コミュニケーションに対する要求事項に重要な影響を与える。
コミュニケーションの計画は，ステークホルダの特定及び分析に続いて，また，定期的にレビューし，プロジェクトを通じて継続的に有効性を確保する。
