プロジェクト管理とPMBOK

プロジェクト管理の知識体系を定義するPMBOKの概要と実際のプロジェクト管理への適用

株式会社三菱総合研究所

情報技術研究センター西山聡

【目次】

PMBOKとは

PMBOKとはプロジェクトマネジメントに関する知識体系です。PMIというアメリカにあるプロジェクトマネジメント関係の団体がまとめているものです。現在はPMBOKに従ってプロジェクトマネジメントを実施することがデファクトスタンダードになっています。PMBOKの内容は４年に１回改訂が行われており、２００４年に大規模な改訂が、２００８年末の第４版ではマイナーな改訂が行われました

PMBOKの目的は2つあります。1つめはプロジェクトマネジメントに関する知識をまとめることによってプロジェクトマネジメントを効率的に実施することです。2つめの目的は、言葉の定義を統一し、分野や国の違いによるコミュニケーションミスを防ぐということです。

PMBOKの基本用語

PMBOKの基本用語について説明します。まず、そのプロジェクトにかかわっている利害関係者のことをプロジェクト・ステークホルダーと呼びます。以下、プロジェクト・ステークホルダーの例を挙げます。

プロジェクト・スポンサーは、プロジェクトに対して資金とか資材を提供する人、あるいは組織のことです。プロジェクト・マネジャーは、そのプロジェクトの実施に関して責任を持つ人です。プロジェクト・マネジャーがPMBOKの知識を持っていないとさまざまな問題が生じます。また、大規模なプロジェクトになるとプロジェクト・マネジャー１人だけではプロジェクトの管理ができなくなるため、マネジメントの作業にかかわる人々をプロジェクト・マネジメント・チームとして考えます。他にはプロジェクト・チーム・メンバーという形でプロジェクトの目標に向けた作業を実施する人々がいます。最後にその他のステークホルダーとして、プロジェクトの成果物を利用する人や、組織としての顧客やユーザー等がいます。

まとめると、プロジェクト・スポンサーはプロジェクトを発注する人、プロジェクト・マネジャーをはじめとするプロジェクト・チーム・メンバーはプロジェクトを実施する人、その他のステークホルダーは、何らかの形でそのプロジェクトの成果を利用していく人、ということになります。

その他のPMBOK特有の用語を説明します。要素成果物とは、フェーズごとに作成される成果やサービスのことです。プロジェクトマネジメント・プロセスは、フェーズに分けてプロジェクトを推進する際、そこで実行される一連のアクティビティのことを指します。PMBOKの第３版では４４のプロセスが定義されています。

４４のプロセスは、５つのプロジェクトマネジメント・プロセス群という中で分かれて定義されています。立ち上げプロセス群とは、プロジェクトを定義して認可するプロセス、つまり、実際にプロセスがスタートするときのプロセスです。プロジェクトが立ち上がった後、実際にその中で何をどういう手順にやっていけばプロジェクトの目標が達成できるかということを考えるのが計画プロセス群です。

計画に従って作業を実行するのが実行プロセス群です。プロジェクトを実行している間に、計画したことと実態とがだんだんずれてきます。そこで何が違っているかを監視する必要があります。監視をしてその違いが発生したところで元へ戻すことによりマネジメント管理が実現できます。これらを実施するプロセス群が監視コントロール・プロセス群です。

最後に終結プロセス群があります。プロジェクトで作成した成果物がプロジェクト・スポンサーに正式に認められる、受け入れられることでプロセスは終了します。

実際に一番必要なのは監視コントロール・プロセス群です。プロジェクトが予定通り動いているか、計画との差異があったとしたらどのように計画に近づけていくかということを考えることが一番PMBOKの中で重要な中身になります。

次に段階的詳細化です。プロジェクト開始時にはゴールしか分からないことが多いです。プロジェクトを進めていくうちに実際何をすればいいかというのが具体化されていくため、内容を徐々に詳しくしていく段階的詳細化という考え方も必要になってきます。

次にプロジェクト・フェーズに関する用語です。プロジェクトをフェーズに分けたものをプロジェクト・フェーズと呼びます。プロジェクト・ライフサイクルは、プロジェクト・フェーズの集合として定義されています。前回、ソフトウエアのライフサイクルを説明しましたが、プロジェクトもライフサイクルがあります。ライフサイクルを考えることによって、プロジェクトの成果もプロジェクトを実施した経験が役に立ってくるということがあります。

次に９つの知識エリアですが、何をやるべきかという観点、何を管理すべきか、という観点からみた切り口がこの９つになります。具体的には以下のようになります。

プロジェクト統合マネジメント〜プロジェクトマネジメント全体をどのようにすればよいのかということ。
プロジェクト・スコープ・マネジメント〜プロジェクトの中で何を考える必要があるのか、プロジェクトの対象となっているものは何かを管理していくこと。
タイム・マネジメント〜スケジュール管理。
コスト管理〜資金面の管理。
品質・マネジメント〜品質管理
人的マネジメント〜プロジェクトメンバーの要員の管理。
プロジェクト・コミュニケーション・マネジメント〜要員、プロジェクト・スポンサーなどプロジェクトのステークホルダー間のコミュニケーションを如何に円滑にするかというコミュニケーションの管理をすること。
プロジェクト・リスク・マネジメント〜このプロジェクトを実施する際に、リスクとしては何があってそれをどう管理すべきか、ということ。
プロジェクト・調達・マネジメント〜購入や調達によって外部資源を取り入れ、それをどう管理していくかということ。

まとめると、個々の管理対象として大きく８つあり、さらに全体を管理する統合マネジメントがあって全部で９つの知識エリアになっています。

PMBOK概観

先述したように、PMBOKでは立ち上げプロセス群があってプロジェクトが立ち上がります。立ち上がったプロセスの中で、まず計画プロセスをやって実行します。実行していくうちに不具合がありプロジェクトの進捗が遅れると、もう一回計画プロセスに戻って、スケジュール管理を考え直します。例えば資金的に余裕がなくなってきた場合には、コスト計画をもう一回考え直すといった形で、計画プロセスと実行プロセスがやりとりされます。実行プロセスが終了すると終結プロセスになります。そして、全てのプロセス群の進捗状況等を、監視コントロール・プロセスで監視します。

PMBOK記法

PMBOKの中では独特の表記方法があります。プロセス群は、プロセスのまとまりを意味します。プロセス、プロセス外部、プロセス・フローを図のように表します。

４４のプロセスにも基本の表記方法があり、入力としてある情報と、そのプロセスを実行することによって生み出されるアウトプットとしての情報、入力から出力を考えるときに使うことができるツールと技法、これら３つの組でPMBOKのプロセスは定義されています。

プロジェクトマネジメント・プロセス群

プロジェクトマネジメント・プロセスというのは、プロジェクトの目標を満たすために実行される一連のアクティビティのことで、先述の通り、４４のプロセスがあります。基本的にはPDCA(Plan, Do, Check, Act)というサイクルを回します。

プロジェクトマネジメント・プロセス群は「立上げプロセス群」、「計画プロセス群」「実行プロセス群」「監視コントロール・プロセス群」、「終結プロセス群」の5つのプロセス群からなります。

立ち上げプロセス群から計画プロセス群に入り、計画したものを実行します。計画と実行に差異が出ていないかどうかを監視コントロール・プロセスでチェックします。このサイクルを回すことによって終結に至ります。

個々のプロセスの具体的な説明をします。立ち上げプロセス群では、プロジェクトを定義します。実行可能な形のプロセスとして定義するというのがここの重要な役割です。特にプロジェクトの境界を定義するということが立ち上げプロセス群の目的です。通常のプロジェクトは企業のビジネスニーズと密着に結びついているので、そういったビジネスニーズや、何が求められているかを明確にした上でプロジェクトの目的を明確にします。プロジェクト憲章というものをつくることと、プロジェクト・スコープ記述書暫定版をつくることが立ち上げプロセス群のポイントになります。

プロジェクト憲章は英語ではプロジェクト・チャーターといい、プロジェクトを正式に許可する文書、プロジェクト自身を定義する文書です。この中には、資源（人やお金や調達して得られるもの）を使っていいかということが書かれています。図では契約をインプットとしていますが、プラント建設を例に説明します。産油国から日本の重工プラントメーカーに石油プラント建築の依頼があり契約が発生したとします。その場合プラントメーカーにとっては、産油国の国や企業とのプラント建設契約がインプットになります。なお、社内のシステムを開発する場合は契約はないので、「該当する場合」と注釈が付いています。

プロジェクト作業範囲記述書には、何をこのプロジェクトでやったらいいかということを記述します。組織体の環境要因は、現在、その企業がどういう状況に置かれているかということです。組織のプロセス資産は、例えば類似のプロジェクトを実施したことがあれば、その実施経験を使って新しいプロジェクトを実施すると、効率的に遂行できる可能性があります。２回目、３回目のプロジェクトは過去の経験を生かせるため、プロセス資産というのは、類似プロジェクトに対するその組織としての経験が中心になって書かれていると考えてください。その結果としてプロジェクト憲章が出てきます。プロジェクト憲章の中身については、この後６回目の授業の中で説明します。

次に、プロジェクト・スコープ記述書暫定版作成です。プロジェクト憲章が定まった後、このプロジェクトとして何をやればいいかということを考えます。プロジェクトから生成される製品やサービスをスコープとして考えます。プロジェクト・スコープとは、そのプロジェクトの中で何をすべきか、プロジェクトの範囲を定義するのがスコープだと考えてください。インプットとしては、プロジェクト憲章作成で作られたアウトプットであるプロジェクト憲章と、作業範囲記述書、それから、組織体の環境要因と組織のプロセス資産がそのまま出てくるという形です。

このように、直前のプロセスのインプットがまた同じように次のインプットになるということが特に立ち上げ段階では見られます。これらは引き続き検討対象になるということです。こういった情報をもとにプロジェクト・スコープ記述書の暫定版をつくるというのがこのプロセスになります。

計画プロセス群には非常に多くのプロセスがあります。立ち上げプロセス群の結果を受けて計画フェーズに入ります。プロジェクトマネジメント計画書作成は計画プロセス群ではないので白枠になっていますが、スコープ計画、スコープ定義、WBS作成など、ここでプロジェクトとして何をすべきかを明確にします。

その後、アクティビティ定義から一連の横の部分ではスケジュールに関する検討を行います。アクティビティ定義で具体的なアクティビティ活動に落とし込み、アクティビティ間の順序設定やアクティビティに必要な資源や期間を考慮し、それを取りまとめてスケジュールを作成します。コスト見積もりは、お金がどのくらいかかるかを考慮し、予算を立てます。品質計画は、プロジェクトの結果としてどういった品質を保てばいいかということを考えます。人的資源計画は、何をすべきかが具体的に決まった上で、その中でどのような人をどのように用意すればいいかということを考えるものです。コミュニケーション計画では、プロジェクトメンバー、あるいはステークホルダー間でどういった形でコミュニケーションをとっていくかということを計画します。リスク・マネジメント計画では、プロジェクトにとってのリスクとして何があるかを考えます。例えば経理システムでは、使用する計算機が発売前だとすると、発売スケジュール遅延はリスク要因になります。そういう問題が起きたときにどう対処するかを考えるのがリスク・マネジメント計画です。

リスク識別は、問題点として具体的に何があるかということを考えた上で、リスクの大きさを定性的、定量的に考えます。そして、リスクが起きたときにどう対応していくかということを考えるのがリスク対応計画です。購入・取得計画は、外部から資源を調達する時に、どうやって購入あるいは取得していくのか、それと関連してスケジュールや納期までを考え、実際にいつまでに契約をしてどういう内容で契約を結ぶ必要があるのか、ということを考えます。これらのものがすべて複合的にスケジュールという形でアウトプットとなります。

実行プロセス群では、プロジェクト実行の指揮マネジメント、統合管理を行います。

まず品質管理と品質保証の違いを説明しましょう。品質保証はアウトプットに対してどう保証していくかであるのに対し、品質管理はプロジェクト実施期間中の品質をどうやって担保していくかというものです。

次に、プロジェクトではチームを編成しますが、このプロジェクトに経験がないようなメンバー、新しいメンバーが入ってきたときには、該当するプロジェクトに関しての知識をOJT等で学んでもらい、プロジェクトチームを育成することがあります。

納入者回答依頼は先述の調達と関係があります。「こういったプロジェクトができる人はいますか」と聞いたときに、候補となる納入者から情報をもらうことです。実際にその中で一番フィットした外注業者を決めるというのが納入者決定です。これらが決まった段階で細かい情報をプロジェクトメンバー、ステークホルダーに配布するのが情報配布です。

実行プロセスという名称ですが、上述のことはあまりプロジェクトを実行しているというイメージではありません。監視コントロール・プロセスが重要だと先述しましたが、実は実際のプロジェクトを回しているのは監視コントロール・プロセス群になります。

監視コントロール・プロセス群は、プロジェクト作業の監視コントロールと統合変更管理を行います。プロジェクトに関するドキュメントを変更する時に、PMBOKでは変更管理という手続を踏みます。つまり、プロジェクトを実施している間に計画を変更する必要があった場合、プロジェクト・マネジャーやプロジェクトメンバーが勝手に変更するということをやっていくと、変更したことが当事者以外に知らされないことが出てきます。そうすると、プロジェクト運営上非常に問題が生じるため、プロジェクトの計画類の変更をするときには必ず全てのステークホルダーの中で合意をとるというのが大前提になっています。その方法を書いてある箇所が統合変更管理です。

変更対象となるものが図の下段に並んでいます。スコープ検証とは、スコープが正しいかどうかをチェックすること、プロジェクト・スポンサーの考えていることと定義したスコープが一致しているかどうかを確認することです。

スコープコントロールは、プロジェクトが運営されている中で定義したスコープから外れていないかをチェックします。スケジュールコントロールは、実際のスケジュール管理を行います。コストコントロールはコストの管理を行います。

プロジェクトチームのマネジメントは、プロジェクトチームが想定した形でうまく育成されているか、プロジェクトチームのメンバーで何か不具合があるようなことをやっている人はいないか等を考えます。実績報告は、プロジェクトの進捗・実績報告をきちんと行っているかを確認します。ステークホルダーマネジメントは、ステークホルダー全体の中で意思統一ができているか、プロジェクト・スポンサーの意図に外れていないか、等を確認します。リスクの監視・コントロールは、当初想定したリスクが発生していないかどうかを確認します。契約管理は、外注等の契約を管理します。これらの中に回復不可能な要因が出てきた場合は、それぞれの計画を変えるということで、統合変更管理を行います。

プロジェクトの終結プロセスです。プロジェクトが終わるときには、プロジェクト終結という作業と契約終結という作業が発生します。特に外注業者との契約を終結するというプロセスがあり、それを統合管理で見ていきます。

知識エリア

知識エリアの観点からPMBOKの概要説明をします。

まず、プロジェクト統合マネジメントです。立ち上げプロセス群の要素としては、プロジェクト憲章作成とプロジェクト・スコープ記述書暫定版作成があります。計画プロセス群では、プロジェクトマネジメント計画書作成において、プロジェクトマネジメントをどうやっていくかということを考えていきます。実行プロセス群にはプロジェクト実行の指揮・マネジメントのプロセスを含みます。監視コントロール・プロセス群では、プロジェクト作業の監視コントロールと統合変更管理を行います。終結プロセスでは、プロジェクト終結を行います。

それぞれのプロセスの目的はスライドのようになります。まずプロジェクト憲章がないとプロジェクトとして立ち上がりません。プロジェクト・スコープ記述書暫定版作成では、スポンサーなどから提供される情報をもとに、プロジェクト・スコープ記述書暫定版を作成します。これは第６回でより詳しく説明します。プロジェクトマネジメント計画書作成は、プロジェクトのマネジメントをどのように行うかという計画書です。プロジェクト実行の指揮・マネジメントでは、実際にプロジェクトの監視等をどうやっていくかということを確認します。プロジェクト作業の監視コントロールというのは、計画、実行、終結で分かれる各プロセスで当初の計画との不整合が出てきたときに、それに対して是正処置を検討します。是正処置や予防処置を実施することによって計画書を変更する必要があるということになった場合、統合変更管理でその変更管理を行います。ここではステークホルダー間での合意をとるということが最大のポイントになります。プロジェクト終結プロセスでは、プロジェクト、またはプロジェクトフェーズを終了させます。

プロジェクトスコープマネジメントではプロジェクトの実施範囲の管理を行います。計画プロセス群には、スコープ計画、スコープ定義、WBS作成があります。スコープ計画は、スコープ定義をどう作成して実際に管理していくかということを考えます。ここで決めたスコープ計画に沿った形でスコープ定義をします。それをさらにブレークダウンしてWBS（ワーク・ブレークダウン・ストラクチャー）として、実際の作業項目に展開するというのがWBS作成になります。監視コントロール・プロセス群には、スコープ検証とスコープコントロールがあります。スコープ検証では、ここで定義したスコープの内容がプロジェクトスポンサー等が考えているスコープと外れていないかどうかを検証することと、実際にプロジェクトが回っている段階でスコープがこのスコープ定義から外れた形でプロジェクトが運営されていないかどうかの監視を行います。

それぞれのプロセスの目的を示したのがスライドの表です。スコープ計画では、スコープ定義をつくる前にプロジェクトをマネジメントするための手順を決めます。各種プロセスには必ず最初に計画があります。スコープだったらスコープ計画という形です。そこで決めようとしている内容をどう決めるか、あるいは変更しなくてはならなくなったときにどう変更手続をするかという手続、手順が書かれるのがそれぞれの計画書です。スコープ計画では、プロジェクトスコープを定義、あるいは変更する際の手順を計画書としてまとめるということになります。

スコープ定義では、プロジェクト製品に大きく関連するプロジェクトスコープを詳細化してプロジェクト・スコープ記述書として記述します。ここで書かれたスコープ記述書の内容について変更が生じないように監視するということが必要になってきます。

WBS作成では、プロジェクトを進めていく上でプロジェクトチームが行うべき作業について作業単位という形で分解してワーク・ブレークダウン・ストラクチャーとして記述していきます。

スコープ検証では、作成された成果物の検査を行い、顧客やプロジェクト・スポンサーから求められている内容と外れていないかをチェックして承認を受けます。

プロジェクトの中で何かを変更する場合、ステークホルダー全体で合意を得る必要があることを先述しましたが、承認済みの変更というのはステークホルダー間で合意された変更を表します。ここでの承認済み変更というのは「スコープについて変更してもいいよ」ということが合意されたということです。

スコープ・コントロールでは承認済み変更に基づいてプロジェクト・スコープ記述書、WBS、WBS辞書、スコープ・ベースライン、プロジェクトマネジメント計画書への変更をコントロールします。ここで、スコープ・ベースラインとは、このプロジェクトの中で最低限守るべきスコープという意味です。そして変更のコントロールに加えて、スコープを変更することにより、スケジュールやコストに影響を与えるということが判明した場合は、スケジュールとコストの変更要求を出します。ここもあくまで要求です。変更要求を出して、今度はこの変更要求についてステークホルダー間で変更をしてもよいという承認が得られたら、スケジュールやコストに関する承認済み変更となります。

プロジェクト・タイム・マネジメントは時間管理、スケジュール管理です。

計画プロセス群で実施するのはアクティビティ定義です。具体的に何をすべきかということをアクティビティとして定義します。WBSでは大まかな形でやるべきことがまとまっていましたが、それをさらに分解してアクティビティという形に分解します。分解したものについて実施順序を設定します。そして、それぞれのアクティビティにかかる時間を見積もります。アクティビティ、順序、所要時間が決まると、このプロジェクト全体の実施期間が決まります。それを含めてスケジュール作成としてまとめます。

それぞれのアクティビティに対してお金がどれぐらい要るのか、人として何が要るのかということを考えること、それがアクティビティ資源見積もりです。これを積み上げることによってプロジェクトにかかる実施予算というのが決まります。これはコスト管理への入力になってきます。

スケジュール・コントロールでは、ここで考えたスケジュールが、予定どおり進められているかどうかを監視します。

では次にプロジェクト・コスト・マネジメントについて説明します。コスト・マネジメントというのは、プロジェクトにかかるお金の部分を管理するところです。

コスト見積もりでは、アクティビティを完了するために必要な資源をコストとして算出します。コストの予算化ではそれを時期的に分解します。パフォーマンス測定は、実際に発生したコストが予定より多いか少ないかを把握するために行います。進捗が思わしくないのにコストが出過ぎているとか、逆に進捗がすごく進んでいるのにコストがあまり発生していないという場合は、何か問題がある可能性があります。その辺を見極めるためのベースラインが予算です。承認済み変更要求に基づいてコスト・ベースラインを変更します。これも承認済みというところがキーワードになります。

コストコントロールでは予算化されたコストを管理します。

プロジェクト品質マネジメントについて説明します。プロジェクト品質マネジメントは、でき上がってくる成果物に対しての品質をどう考えていくかというところです。品質計画では、どういう形で成果物に対して品質を考えるかを確認します。品質管理では、プロジェクトの実施している内容を見ながら、想定している範囲で品質が保たれているかどうかを管理します。品質管理の状況がよければ品質保証ができるということになります。品質保証については実行プロセスで、品質管理については監視コントロールプロセスという中で見ていくということになります。

各プロセスの目的を示したものがスライドの表です。品質管理プロセスの結果に基づいて品質保証ができるわけです。あるいは、品質保証ができないとすると、どういうふうに改善すればよいかを考えます。品質管理は、要素成果物やプロセスが品質マネジメント計画通りの品質を確保しているかどうか監視して、適合していない場合にはその原因と改善方法を特定するということです。ですから、管理するのは品質管理で、その品質管理の結果として保証が発生します。順序関係があるので気をつけてください。

プロジェクト人的資源マネジメントについて説明します。人的資源マネジメントとは、プロジェクトメンバーをどう管理していくかということです。プロジェクトメンバーの中には、複数の会社の人間が集まってプロジェクトメンバーとなることもありますので、そのことも含めて管理する必要があります。

先述のアクティビティ定義で、どういう人がどういう時期に何人ぐらい要るかということをアクティビティ資源見積もりで行うと勉強しましたが、人的資源計画とはその中の人の部分をインプットとして、資源計画という形で具体化することです。それを受けてプロジェクト・チームとして編成を行います。併せて、プロジェクト・チームメンバーの技量がある程度のレベルになるように育成します。それから、監視コントロール・プロセス群としては、プロジェクト・チーム自身の管理を行います。

それぞれのプロセスの目的を示したのがこのスライドです。人的資源計画では、誰が誰に何を報告するかというのを決めておかないとプロジェクト・チームの管理ができなくなりますので、役割と責任を決めるだけではなく報告関係を決めます。

プロジェクト・チーム編成では、プロジェクトにメンバーを任命していきます。

プロジェクト・チーム育成では、プロジェクト・チームメンバーの能力を強化してメンバー間の交流を促進するということと、プロジェクト・チームとして計画されたことが実施できるレベルまでパフォーマンスを高めるということが求められています。

プロジェクト・チームのマネジメントでは、プロジェクト・チームメンバーそれぞれについて、言われたことができているかどうかをチェックします。何か劣っている部分があるとすると、何が問題となっているかを把握した上でその解決を図って、チームとしてのパフォーマンスを高めることを考えます。

プロジェクト・コミュニケーション・マネジメントについて説明します。プロジェクトマネジメントの中で一番重要な要素はコミュニケーションです。チームメンバー、あるいはステークホルダー間のコミュニケーションがうまくできるとプロジェクトマネジメントはうまくいくと言われているほど、このコミュニケーション・マネジメントは重要なポイントになります。

具体的には、コミュニケーション計画でチーム間での報告順序を決めたのと同様のことを行います。例えば様々な監視項目の進捗報告をどういう会議で実施するか、どういう会議で何について検討するか、その会議への参加メンバーをどうするか等を決めます。つまり、誰にどういう情報をどういうタイミングで伝えるかということを計画するのがコミュニケーション計画です。情報配布では、決められたコミュニケーションに従って定められている内容を対象者に配布します。監視コントロール・プロセスとしては、実績報告書という形でプロジェクトの進捗状況を含めた実績報告とステークホルダーとのコミュニケーションの管理を行います。

プロジェクト・リスク・マネジメントについて説明します。プロジェクトを実施するにあたり、人が足りなくなる、予算が足りなくなる、想定していた資材・材料が届かない、予定した時期に届かないなど、プロジェクトの進行に問題がある要素として何があるかということを考えて洗い出し、それに対応するというのがプロジェクト・リスク・マネジメントになります。

それぞれのプロセスの目的を表したのがこのスライドです。リスク・マネジメント計画とは、問題が起きたときにどのような手続でリスクを認識し、対応・解決を図るかということを考えます。リスク識別というのは、具体的にその段階でどういうリスクがあるかということを考えます。定性的リスク分析では、ここで考えたリスクというのはどのような性質のものか、どのように起きそうかを、影響度を含めて考えます。定量的リスク分析では、それを金額に置きかえたときに、あるいは発生頻度等を含めて考えたときにどのようなリスクとして位置づけられるかという分析を行います。リスク対応計画では、リスクが発生した場合の対応手段を考えます。リスクは、当初の計画プロセス段階で識別されたものもありますが、それ以外にも発生するものがありますので、これらはリスク監視コントロールのところでチェックしていきます。また、リスクを見極めておく必要がありますが、リスクとはまだ起きていないが起きるとまずいものがリスクです。まずいなと思っているものが起きると、それはリスクではなくて課題になりますので、解決する必要が出てきます。リスクというのは発生する前の問題です。発生してしまうと課題として具体的にそれに対しての解決が必要になるということを覚えておいてください。

プロジェクト調達マネジメントについて説明します。これは外部から製品やサービスを購入、または取得するプロセスで、一般に調達という言い方をします。

それぞれのプロセスの目的をまとめたものがこのスライドです。

購入・取得計画では、購入や取得をするときの計画を立てます。契約計画は契約に関する事項です。特に国の事業等では、入札という形で一番良い条件の納入者を選ぶ場合がありますが、その時に「こういう物品をこういう仕様で買おうと思っているんですが」というようなアンケートを行いながら、納入者としてどのような団体、企業が参加してくるかを、事前に見極めることがあります。このようなプロジェクトに対して参加意思があるかどうかを確認する作業を納入者回答依頼といいます。プロポーザルの内容や金額で決める場合もありますが、このようなプロセスを経て納入者を決定します。作業の中では、当然購入やサービス提供に関しての契約が発生しますので、その契約管理と終了した後の契約終結というプロセスが存在します。