プロジェクトマネージャ試験 の改訂について (令和2年 春期試験より)

高度IT人材として確立した専門分野をもち，システム開発プロジェクトの 責任者として 目標の達成に向けて，責任をもって，プロジェクト全体計画（プロジェクト計画及びプロジェクトマネジメント計画）を作成し，必要となる要員や資源を確保し，計画した 予算，納期， スケジュール，品質 の達成について責任をもって などの計画に基づいて プロジェクトを 実行・ 管理 ・運営 する者

情報システム又は組込みシステムのシステム開発プロジェクトの 目標を達成するために，責任者として ， 当該プロジェクトを計画，実行，管理する業務に従事し，次の役割を主導的に果たすとともに，下位者を指導する。

1. 必要に応じて ，個別システム化構想・計画の策定を支援し，策定された個別システム化構想・計画に基づいて，当該プロジェクト の実行計画 をマネジメントする方法 をプロジェクト全体計画として作成する。
2. 必要となる要員や資源を確保し，プロジェクト組織を定義する。
3. スコープ・ 予算 ，工程， ・スケジュール・品質・リスク などを管理し て，プロジェクトを円滑に 運営 マネジメント する。進捗状況を把握し，問題や将来見込まれる課題を早期に把握・認識し，適切な対策・対応を実施する ことによって，プロジェクトの目標を達成する 。
4. プロジェクトのステークホルダに，適宜，プロジェクト全体計画，進捗状況，課題と対応策などを報告し，支援・協力を得て，プロジェクトを円滑に 運営 マネジメント する。
5. プロジェクトフェーズの区切り及び全体の終了時，又は必要に応じて適宜，プロジェクトの計画と実績を分析・評価し，プロジェクトのその後の 運営 マネジメント に反映するとともに，ほかのプロジェクトの参考に資する。

プロジェクトマネージャの業務と役割を円滑に遂行するため，次の知識・実践能力が要求される。

1. 組織 運営 戦略 及びシステム全般に関する基本的な事項を理解している。
2. 個別システム化構想・計画及び プロジェクトへ ステークホルダ の期待を正しく認識し，実行可能なプロジェクト全体計画を作成できる。
3. 前提・制約の中で， 変化に適応して， プロジェクトの目標を確実に達成できる。
4. スコープ・ 要員・資源・予算・ 工程 スケジュール ・品質 ・リスク などを管理し，プロジェクト チーム の全体意識を統一して，プロジェクトを 運営 マネジメント できる。
5. プロジェクトの進捗状況や将来見込まれるリスクを早期に把握し，変更を管理して，適切に対応できる。
6. プロジェクトの計画・実績を適切に分析・評価できる。また，その結果を その後の プロジェクトの 運営 その後のマネジメント に活用できるとともに，ほかのプロジェクトの参考に資することができる。

プロジェクト， プロジェクトの目標，組織の戦略と価値創成， プロジェクトマネジメント， マネジメントプロセスの修整， プロジェクトの環境，プロジェクトガバナンス，プロジェクトライフサイクル，プロジェクトの制約， 個別システム化計画の作成と承認， プロジェクト憲章の作成，ステークホルダの特定，プロジェクトチームの編成， システム開発方針の設定， プロジェクト全体計画（プロジェクト計画及びプロジェクトマネジメント計画）の作成，スコープの定義，要求事項と 見積り 優先度 ， WBSの作成，活動の定義，資源の見積り，プロジェクト組織の定義，活動の順序付け，活動期間の見積り，スケジュールの作成，コストの見積り，予算の作成，リスクの特定，リスクの評価，品質の計画，調達の計画，コミュニケーションの計画， 提案依頼書（RFP）， 関連法規・標準 など

プロジェクト作業の指揮，ステークホルダのマネジメント，プロジェクトチームの開発，リスクへの対応，品質保証の遂行，供給者の選定，情報の配布，プロジェクト作業の管理，変更の管理，スコープの管理，資源の管理，プロジェクトチームのマネジメント，スケジュールの管理，コストの管理，リスクの管理，品質管理の遂行，調達の運営管理，コミュニケーションのマネジメント， マネジメントプロセスの改善， 機密・契約の管理，プロジェクトに関する内部統制 など

プロジェクトフェーズ又はプロジェクトの終結，プロジェクト の評価指標と 評価手法と適用技術，プロジェクト完了後の評価指標 ， プロジェクトの完了基準， プロジェクト の 計画と実績の差異分析，検収結果の評価，契約遵守状況評価，得た教訓の収集，プロジェクト完了報告の取りまとめ など

1-2 個別システム化計画の承認 [概要]

IT ストラテジスト（ST）が個別システム化計画を審査・承認する組織（以下，承認組織という）に提出し，個別システム化計画の妥当性の審査を経て承認を得ることを支援する。

計画の承認組織は，計画内容の組織の目標に対する充足性を評価した上で，組織にとっての予算の限度，組織が期待する完了時期，確保すべき品質水準，資源の利用可能量などを勘案し，必要に応じて計画内容に対して何らかの制約又は条件を加える可能性がある。ST が，設定された制約が大きな支障とならないかどうかを判断し，必要に応じて個別システム化計画の承認組織と調整するが，その際に支援する。

変化に俊敏に適応して価値を創成するためには，組織の枠にとらわれず活用できる全ての専門知識及びスキルを結集してプロジェクトを推進する必要がある。このようなプロジェクトの推進方法に関して承認組織の理解と合意を得る必要がある。

この個別システム化計画は，プロジェクトフェーズの立ち上げプロセス群及び計画プロセス群のプロセスに対する初期の要求事項となって，後続のプロセスで段階的に詳細化される。

個別システム化計画の承認組織の位置付けと権限は，プロジェクトを立ち上げる組織やプロジェクトの形態によって異なる。

1-3 プロジェクト憲章の作成 [概要]

プロジェクト憲章は，プロジェクトの正式な承認，プロジェクトマネージャ（PM）の任命，初期の要求事項，プロジェクトの目標，期待する成果物及びプロジェクトの経済面について文書化したものである。

PM は，個別システム化計画の承認組織による承認を経て上層の管理者によって任命され，適切な責任と権限が明確にされる。

個別システム化計画を基に，ビジネスニーズ，プロジェクトで現実化する便益，プロジェクトの背景と目的，プロジェクトで達成する目標，解決する問題，PM 及びプロジェクトチームが果たすべき役割と任務，プロジェクト作業を管理する方針やルールを明確にする。また，プロジェクトの範囲，主要なステークホルダ，プロジェクトの制約と前提，概略のスケジュールと予算を明確にする。

プロジェクト憲章の作成における PM の役割は，プロジェクトを立ち上げる組織やプロジェクトの形態によって異なる。確実に便益を現実化するために，PM がプロジェクト憲章の作成に積極的に参加する場合がある。

1-4 ステークホルダの特定 [概要]

プロジェクト憲章やプロジェクトの組織図に基づき，プロジェクトから影響を受けるかプロジェクトに影響を与える個人，集団又は組織を明らかにし，その利害及び関係に関連する情報をステークホルダ登録簿として文書化する。

顧客の要求事項を確実にかつ迅速に満たすためには，組織の内部・外部にかかわらず共創関係を構築して，積極的な参加と関与を求めるべきステークホルダを特定する必要がある。

1-5 プロジェクトチームの編成 [概要]

プロジェクトの完遂に必要な人的資源を得るために，プロジェクトチームの構成員の選定を全面的に管理するか又は選定に参加する。

その際，プロジェクトの成果物を活用して顧客にサービスを提供する作業を考慮し，運用組織及び保守組織との協働の形態を踏まえた構成員を選定する。いつ，どのようにプロジェクトチームの構成員を得て，いつ，どのように構成員をプロジェクトチームから解放するのかを決定する。

プロジェクトチームの編成においては，専門知識及びスキル，個性の相違，チームワークによるパフォーマンス向上の効果などの要因を考慮する必要がある。必要な専門知識及びスキルを結集するために，組織の枠にとらわれない組織横断チームによる活動が必要となる。組織内で人的資源が得られないときは，追加の構成員を雇うか，作業を別の組織に委託することを考慮する。したがって，組織横断チームには顧客又は外部の組織の要員が加わることがある。また，システム開発の方法に適合したプロジェクトチームの構成員数を設定する。

2-3 スコープの定義 [概要]

プロジェクトの範囲を定義することによって，目標，要求事項，成果物及び作業を含むプロジェクトスコープを明確にし，スコープ規定書や要求事項として文書化する。要求事項に不安定性があり，初期段階にスコープ定義の確定や顧客との合意が困難な場合は，段階的な要求事項の探索や合意形成などの対応が必要である。この対応において価値を確実に創成するためには，要求事項と創成する価値との関係性を明らかにして，要求事項の優先順位を決定する尺度を創成する価値の大きさとするなどの工夫も必要である。

プロジェクトスコープ規定書は，将来のプロジェクトの決定，並びにプロジェクトの重要性及びプロジェクトの遂行によって現実化する便益を伝達するためのベースとして使用する。

2-4 WBSの作成 [概要]

プロジェクト計画及びプロジェクトマネジメント計画や要求事項に基づき，階層的に分割する手法でプロジェクトの目標を達成するために必要な作業を特定する。 ワークブレークダウンストラクチャ（WBS）は，プロジェクトフェーズで実施する作業を，成果物に基づき，管理しやすいより小さな作業に階層的に分割して作成する。 分割した WBS の最下位のレベルに定義される作業であるワークパッケージ（WP）ごとに，作業内容，成果物を設定する。WBS，WP，スコープ規定書をスコープベースラインとする。

計画時点で作成する予定の全ての成果物が確定できず，全ての作業を WP にまで分割できない場合は，成果物が確定されてから段階的に詳細なWBSを作成する。

プロジェクトの成果物，組織，リスク，コストなどに対して，それぞれ管理する目的に沿って階層構造のブレークダウンストラクチャが作成される。

2-5 活動の定義 [概要]

プロジェクトの目標を達成するために，ワークパッケージ（WP）に対応してスケジュールに組み入れて実施すべき全ての作業を特定し，活動（アクティビティ）として定義し，活動リストとして文書化する。全てのプロジェクトフェーズで実施する作業を計画時点で確定できない場合には，段階的に詳細な WBS を作成し，確定した WP に対して活動を定義する。

活動リストは，プロジェクトの計画，実行，管理及び終結の作業の基準となる。

2-8 活動の順序付け [概要]

プロジェクトの活動間の論理的な関係を特定し，活動順序を文書化する。 プロジェクト内の全ての活動は，ネットワーク図（作業工程図）を用いるなどして，クリティカルパスを決定できるように関係を明らかにする。

活動は，現実的かつ達成可能なプロジェクトのスケジュールの作成のために，先行作業との適正な依存関係及び適正なリード，ラグ，制約，相互依存関係並びに外部との依存関係をもって論理的に順序付けする。

2-9 活動期間の見積り [概要]

プロジェクトの各活動を完了するために必要な時間を，活動期間の見積りとして文書化する。

活動期間は，利用できる資源の量と種類及び活動間の関係，能力，日程計画，学習曲線などの対象の影響を受ける。

活動期間は，時間の制約と資源の利用可能性との間のトレードオフとなる。ベースラインに照らして更新した予測に基づく定期的な再見積りも必要である。

活動期間の見積りは，クリティカルパスを特定したときに再考する必要がある。クリティカルパスによって，プロジェクトの完了期日が要求される完了期日よりも遅れることが明らかになった場合は，クリティカルパス上の活動を部分的に修正することが必要となる。

2-10 スケジュールの作成 [概要]

プロジェクトの活動の開始時間及び終了時間を算定し，マイルストーンを設定して，プロジェクト全体のスケジュールのベースラインを確定する。プロジェクトの環境の急激な変化や高い不確実性などでプロジェクト全体を通したスケジュールの作成が難しい場合は，優先順位の高い要求事項に関わる活動のスケジュールを作成し，要求事項が確定するに伴って，段階的に該当する活動を定義してスケジュールの作成を行う必要がある。

スケジュールは，時間を基準とした実際の進捗を評価する手段である。進捗を測る尺度は，成果物の開発によって創成される価値とするなど，プロジェクトの特徴に合わせて設定する。

スケジュールの作成は，作業の進捗，プロジェクト全体計画の変更，予期するリスクの発生又は消失，及び新しいリスクの特定に応じて，プロジェクトを通じて継続して実施する。また，必要な余裕を考慮し，更に論理的に可能な実施期間の短縮，資源の平準化を図り，スケジュールとして文書化する。

2-7 プロジェクト組織の定義 [概要]

プロジェクトに関係する全てのステークホルダから必要なコミットメントを得て，プロジェクトに関連する役割，責任及び権限を，プロジェクトの特徴及び複雑さに従って定義する。また，組織の迅速な意思決定に向けて，組織の枠にとらわれずに，ステークホルダとプロジェクトチームとで直接コミュニケーションできる共創関係となるように定義する必要がある。

プロジェクトチームの全ての構成員及びプロジェクトの作業に直接関係するその他の人々を特定する。また，プロジェクトの実行・管理を確実に実施する要員を選定し，ワークパッケージ（WP）に割り当てて，役割規定書で責任と権限を明確にする。

必要に応じて，外部の組織やプロジェクト外の要員などに対してシステム開発作業の一部を委託したり，情報の提供，技術的コンサルティング，レビュー実施の協力を要請したりする。また，迅速に顧客へサービスを提供するために，成果物の引渡しやシステムのリリース作業を，組織内でプロジェクトと定常業務組織でどのように分担するかを明確にする。

これらをプロジェクトの組織図として文書化する。

2-17 コミュニケーションの計画 [概要]

ステークホルダの情報のニーズ及び全ての法令要求に従った情報のニーズを特定する。また，そのニーズを満たすための適切な手段を明確にする。プロジェクトの環境の急激な変化や高い不確実性が想定される場合は，変化する状況をより頻繁かつ迅速に伝えるというコミュニケーションに対する要求事項がある。

地理的に分散した要員，多様な文化などの要因及び組織的要因は，コミュニケーションに対する要求事項に重要な影響を与える。

コミュニケーションの計画は，ステークホルダの特定及び分析に続いて，また，定期的にレビューし，プロジェクトを通じて継続的に有効性を確保する。

2-11 コストの見積り [概要]

各プロジェクトの活動の完了及びプロジェクト全体の完了に必要なコストを見積もって文書化する。初期の段階で高い精度のコスト見積りが難しい場合は，初期にはコストの概算見積りを迅速に行う簡易な手法を用い，プロジェクトの進捗に伴い段階的に，より精度の高い見積り手法に変更するなどの対応が必要である。

活動別に，必要な要員と資源量や資源単価などを基にコストを積算し，プロジェクト推進に付帯して必要なコスト，リスクに備えた予備費又は引当金などを特定して，プロジェクト全体の完了に必要な総コストを得る。コストの見積りの精度が低い場合には，そのことを考慮して予備費を確保するとともに，あらかじめ予備費の使用に関する手順を定めておく。

総コストは，プロジェクトの立ち上げ時に与えられた経済面の制約，組織の予算の作成の方針を勘案して検証する。

2-12 予算の作成 [概要]

プロジェクトの総コストを WBS の該当する適切なレベルに配分して，プロジェクト全体のコストのベースラインを確定する。コストの見積りがプロジェクトの総コストを決定するのに対して，予算の作成はいつどこでコストを使うかを特定する。

コストベースラインは，コストパフォーマンスをマネジメントする基準である。コストパフォーマンスを測る尺度は，成果物の開発によって創成される価値とするなど，プロジェクトの特徴に合わせて設定する必要がある。

経営層による管理又は特定したリスクに対応する目的で，必要に応じて活動又はその他の作業スコープに割り当てられない引当金又は予備費項目を作成する。

スコープや要求事項の頻繁な変更が想定される場合には，これらの変更に対応して予算をステークホルダと迅速に調整し変更できるように，手順をあらかじめ定めておく。

2-13 リスクの特定 [概要]

プロジェクトライフサイクルにおいて，発生した場合にプロジェクトの目標の達成にプラスの影響を与えることのある潜在的リスク（機会），又はマイナスの影響を与えることがある潜在的リスク（脅威）及びその特性を決定する。

知識が不完全であるなどの不確実性が，プロジェクトの目標の達成に影響を与えるような場合は，漸進的な開発，プロトタイプ，シミュレーションなどの探索的な手法で不確実性の影響を段階的に最小化・局所化し，リスクとして特定し対応する。

プロジェクトの進捗に従って新たなリスクを認識したり，リスクが変化したりすることがある。したがって，リスクの特定は，反復的なプロセスである。特定したリスクはリスク登録簿に記録する。

2-14リスクの評価 [概要]

今後の処置のために，特定した各リスクの発生確率及びそのリスクが発生した場合にプロジェクトの目標の達成に与える影響を推定する。さらに，期間，主要なステークホルダのリスク許容度などのほかの要因を考慮した評価に従ってリスクへの対応の優先順位を定める。

リスクの評価は反復的なプロセスである。

3-2 ステークホルダのマネジメント [概要]

ステークホルダの要求事項及び期待を適切に理解し，ステークホルダの関心事を特定して課題を解決する。

プロジェクトマネージャがステークホルダの課題を解決できないときには，課題の処理をプロジェクト組織におけるより上層の管理者に嘆願（エスカレーション）するか又は外部の支援を引き出す。

顧客の要求事項を確実にかつ迅速に満たすには，最も影響の大きいステークホルダと積極的にコミュニケーションすることが必要である。これによって，優先順位の高い課題を解決して，より多くのステークホルダの高い関与を促すようにマネジメントする。

ステークホルダ及びステークホルダがプロジェクトに与える影響を詳細に分析して，優先順位を付けたステークホルダのマネジメントの計画を作成する。

3-7 情報の配布 [概要]

コミュニケーションの計画で定めたように，プロジェクトのステークホルダに対して要求した情報を利用可能にし，また情報に対する予期せぬニーズに対応する。 プロジェクトの環境の急激な変化や高い不確実性を伴う場合には，これらによる影響や課題をできるだけ早く明確にして組織内及び組織を超えた情報の透明性を維持する必要がある。

配布情報は，報告会の開催などによってプロジェクトの状況を正確かつ適切に伝え，情報に対するステークホルダのニーズを満たすようにマネジメントする。

スコープ，品質，コスト，スケジュール，リスクなどの実際のパフォーマンスと計画したパフォーマンスの差異を中心に，差異の今後の見通し，発生した問題の解決状況，変更要求への対応結果を重点報告事項とする。情報の透明性を維持するために，会議やレビューに広くステークホルダの参加を要請したり，プロジェクトの成果物を公開の場に掲示したりする。

3-3 プロジェクトチームの開発 [概要]

継続的にプロジェクトチームの構成員のパフォーマンス及び相互関係を改善し，プロジェクトチームの意識を統一して，活力と主体性のあるプロジェクトチームを開発する。さらに，プロジェクトチームとチーム構成員のパフォーマンス及び相互関係を改善するように必要な教育・訓練にコストと時間を投入する。また，チーム構成員の心身の健康を管理する。

チームとしてパフォーマンスを継続して改善するためには，個々の構成員が得意分野を持ち，かつ広い範囲の作業がこなせるように育成する必要がある。これによって構成員は，チームのパフォーマンスを向上させるスキルを持ち，相互信頼をベースとして自律的にプロジェクトをマネジメントできるようになる。また，顧客にサービスを提供するために必要となる全てのスキルを一つのチーム内に備えることを目指すことも必要になる。

適切な行動の基本原則を，プロジェクトの早い時期に確立することで，誤解及び対立を最小限にとどめることができる。

3-6 供給者の選定 [概要]

システム開発要員，製品，サービスを外部の組織から調達する際に，供給者から情報を入手して，提出された全ての情報をレビューし，審査して，プロジェクトの条件に最適な供給者を選定する。 調達仕様書，要求事項に照らして契約の種類，検収条件を確定し，契約書又は注文書，及び選定された推奨供給者リストとして文書化する。

情報提供，提案，応札又は契約条件の提示に関する依頼はそれぞれの目的が異なるが，依頼には，目的及び提出期限とともに，提供される文書のスコープ，体裁，品質，数量などの詳細な説明を含める。

各供給者の応札の評価は，選択した評価基準に従って実施し，最も適切かつ有益な応札とみなせるものを最終的に選択する。

供給者の選定から最終契約条件を合意するまでに，供給者に対しては双方のリスクを抑制する姿勢で契約交渉を行う。

3-5 品質保証の遂行 [概要]

品質要求事項を満たすために，プロジェクトの進捗に伴って成果物及びプロジェクトのレビューなどを行い，品質の計画を実施する。

品質保証の遂行には，品質要求事項を満たすために必要なプロセス，ツール，手順，技法及び資源の使用を確実にすることを含む。

顧客の満足度を高める価値の創成に向けてシステムを頻繁にリリースする場合，リリースの都度，品質保証の活動の結果を評価して，次のリリースに向けての品質の計画の内容を見直す。

品質の計画の未実施，品質要求事項の未達成の場合，対策を立案し欠陥を除去するなどの品質の改善を図る。また，必要ならば構成管理について変更管理の手続で是正処置を講ずる。

品質保証の手順の改善が必要な場合には，品質の計画の変更管理の手続に向けて変更要求を決定する。

3-4 リスクへの対応 [概要]

プロジェクトの目標の達成にプラスの影響を与えることのある潜在的リスク（機会）を増やして，マイナスの影響を与えることがある潜在的リスク（脅威）を減らすために，選択肢を作成して対策を決定する。プロジェクトの環境の急激な変化や高い不確実性を伴う場合には，プロジェクトの進捗に伴い繰り返しリスクへの対応の結果を評価して，再度リスクの特定，リスクの評価を経て対策の内容を更新する。

資源を投入して活動するために，予算とスケジュールに必要な処置を施してリスクに対応する。リスクへの対応は，そのリスクにとって適切であり，費用対効果が高く，タイムリで現実的であり，ステークホルダに理解され，適正な要員に割り当てられるようにする。

また，リスクへの対応の優先順位を定めてその作業量を見積もり，それをスケジュールに盛り込む。さらに，リスク発生時のコンティンジェンシ計画（緊急時対応計画）やその発動条件を規定する。

脅威のリスクへの対応には，リスクの回避，軽減，転嫁又はリスクを受容してそのリスクが発生したときに使用するコンティンジェンシ計画の作成の判断が含まれる。

4-11 コミュニケーションのマネジメント [概要]

ステークホルダのコミュニケーションに対する要求事項を確実に満たし，コミュニケーションの課題が発生したときには，それを解決する。プロジェクトチームの構成員とステークホルダの円滑なコミュニケーションを通じて，ステークホルダの理解と協力を深める。頻繁な変更がある場合には，これによってコミュニケーションのギャップが生まれないように，また変更に伴い発生したコミュニケーションの課題についても迅速に解決できるように対応する必要がある。

タイムリで正確で偏りのない情報を提供し，コミュニケーションの課題を解決して，未知又は未解決のステークホルダの課題又は誤解によって，プロジェクトが悪影響を受けるリスクを最小化する。

4-5 プロジェクトチームのマネジメント [概要]

プロジェクトチームのパフォーマンスを最大限に引き上げ，パフォーマンスの評価結果をフィードバックし，課題を解決し，コミュニケーションを促し，プロジェクトを成功に導く。チームのパフォーマンスが最大化するようにチームのマネジメントの自律性を高める。このために，チームの構成員の専門スキルの向上に加えて，相互信頼に基づくチームワークのスキルの向上を促進する。また，顧客へのサービス提供の評価結果をプロジェクトチームのマネジメントのプロセスの改善につなげるようにする。

プロジェクトチームのマネジメントの結果，資源の要求事項を改訂することがある。

4-10 調達の運営管理 [概要]

プロジェクトの作業過程で，購入者と供給者との関係をマネジメントし，組織内のチームと外部調達要員が融和して期待する能力が発揮できるようする。

このプロセスでは，供給者のパフォーマンスの監視及びレビュー，定例進捗報告書の受理，並びに契約の種類，品質，遂行状況，適時性及び安全性を含むプロジェクトの全ての要求事項に適合させるための処置を行う。

供給者の契約の未履行に対して，双方協議の上，早期の問題解決に努める。契約内容の変更が発生した場合には，変更内容を明確にした上で契約変更を行う。

プロジェクトの環境の急激な変化や高い不確実性を伴う場合には，調達仕様書及び要求事項が変更に適応できるように契約内容に配慮が必要である。これによって契約全体を変更することなく，迅速に変更に対応できる。

4-9 品質管理の遂行 [概要]

一定期間内における品質保証の遂行状況から，確定したプロジェクトの目標，プロジェクトの品質要求事項及び規格を満たすかどうかを明らかにし，未達成の場合に原因及び是正するための方法を特定する。このプロセスは，プロジェクトライフサイクル全体を通して実施する。

具体的には，成果物及びプロセスの品質を満たすことを監視し，確定済みのツール，手順及び技法を用いて欠陥を発見する。発見した欠陥について考えられる原因を分析し，予防処置及び変更要求を決定する。

品質管理によって，プロセスのパフォーマンス又は製品品質が不十分である原因が特定されることがあり，パフォーマンスの不適合を改善する必要があるときには，是正処置又は変更要求を行う。また，適切なプロジェクト組織の構成員に是正処置及び変更要求を伝達する。

継続して価値を創成するためには，品質のプロセスのパフォーマンスも継続的に向上させる必要がある。この場合には，プロセスのパフォーマンスを，顧客満足度などの価値を表す尺度に基づき定期的に測定して改善状況を評価する。

4-8 リスクの管理 [概要]

一定期間内におけるリスクへの対応の実施状況から，特定したリスクの追跡，新たなリスクの特定及び評価，コンティンジェンシ計画の発動条件の監視及びリスクへの対応の有効性を評価しながら，リスクへの対応の進捗をレビューする。

プロジェクトリスクは，プロジェクトライフサイクルを通じて定期的に，新たなリスクが出現したときに又はマイルストーンに達したときに評価する。

また，プロジェクトの進捗とともに必要に応じて実態に適合するように，リスクの特定とリスクの評価の結果，リスク発生に対する基本的な方針，リスクへの対応の内容を変更する。

システムを頻繁にリリースする場合には，リリースの都度，リスクへの対応の有効性も評価し，必要ならば以降のリリースに向けて改善を図る。さらに，プロジェクトチームのリスクに関わる認識の共有を促進して，リスクマネジメントのパフォーマンスを向上させるようにする。

4-2 変更の管理 [概要]

プロジェクト及び成果物に加えられる変更を管理し，変更を実施する前に，これらの変更要求の受入れ又は棄却を決定する。プロジェクトの環境の急激な変化や高い不確実性に起因する変更は前向きに捉えて，チームが変更に確実にかつ迅速に対応できるように，また変更の実施によってより高い価値を創成できるように管理する。 申請された変更要求に関して内容を確認し，変更登録簿に記録する。変更要求には，変更の概要，変更要求の理由，変更が与え得る影響や変更を実施しない場合の影響の査定などを含む。

変更は，あらかじめ定められた変更管理手順に従ってステークホルダと協議の上，変更することによる便益，変更の範囲，時間，コスト，品質，リスクを分析・評価し，影響の査定結果についてステークホルダの承認を得る。また，承認された変更に関連するプロジェクト計画及びプロジェクトマネジメント計画を変更する。さらに，必要なプロジェクト文書の更新を含めて，変更の実施のために全てのステークホルダにその決定を通知する。必要に応じてコストや作業期間の簡易な見積り方法を活用して，変更が生じた際にステークホルダに迅速な意思決定を促す。

変更要求が承認されると，プロジェクトマネージャは，変更に関わる全てのプロジェクトチームの構成員に対して変更の実施を指示し，変更の実施の状況を確認し，その結果を評価する。また，成果物への変更は，構成管理の手順によって適切に管理する。

5-1 プロジェクトフェーズ又はプロジェクトの終結 [概要]

プロジェクトフェーズ又はプロジェクトを終結するために，供給者からの調達品の検収も含め，全ての最終成果物に関する機能，性能，品質などを検証して全てのプロジェクトマネジメントのプロセス及び活動の完了を確認する。

プロジェクトの終結時点では，終結に影響しないと判断された問題を除き，他の問題は全て解決され，また，承認された変更要求への対応が終了していることを確認する。

プロジェクトに関する全ての成果物をステークホルダに引き渡し，ステークホルダによる検収作業に，適時，適切に対応する。また，残された全ての問題を記録して引継ぎが可能な状態にしておく。プロジェクトによって開発された成果物は，運用組織又は保守組織に引き渡す。

ステークホルダがプロジェクトの成果物を必要としなくなった場合，又は一部若しくは全ての目標が達成できないことが明らかになった場合には，完了前にプロジェクトを中止する必要が生じる。 プロジェクトフェーズの終結の場合は，当該プロジェクトフェーズの終結を確認して，ステークホルダに当該プロジェクトフェーズの終結及び次のプロジェクトフェーズの開始の承認を得る。

全てのプロジェクトの文書類は組織で定められた管理標準に従って収集，保管した上で，ステークホルダにプロジェクトの終結を報告し承認を得て，プロジェクトの全ての活動を完了し，全てのプロジェクト要員及び資源を解放してプロジェクトは終了する。

5-2 得た教訓の収集 [概要]

現在のプロジェクト及び将来のプロジェクトにおける標準値，障害対応などへの参照情報とするために，また，教訓として役立てるために，プロジェクトを評価して，その結果を含めて分析結果をデータベース化して経験を収集する。

プロジェクトライフサイクルのプロジェクトフェーズで適宜収集してきた要員の投入工数，資源の配分量，作業期間，品質，コスト，リスク登録簿，承認された変更，懸案事項などに関する情報を収集し，活動別，プロジェクトフェーズ別，プロジェクト内のチーム別に分類して集計する。これらを基に，プロジェクトフェーズ及びプロジェクトの終結時点での全体プロジェクト計画と実績の差異分析を行う。

また，プロジェクト完了後の評価指標に基づいて，顧客の満足度及び便益の現実化に関すること，プロジェクト作業や成果物の品質に関すること，プロジェクトチームによって得られた成果に関すること，要員の能力や協調体制に関すること，プロジェクトマネジメントの方式に関すること，などを評価する。

望ましい成果が得られなかった点に関しては，次のプロジェクトフェーズ以降での改善策を作成し，より良質な成果が得られるよう評価結果を有効に利用する