プロジェクトマネジメント

目次

応用情報技術者試験（レベル３）シラバス－情報処理技術者試験における知識・技能の細目－ Ver. 7.0 に基づき，「プロジェクトマネジメント」の対策ノートを作成した。

本稿は，プロジェクトマネージャ試験の対策としても活用できるようにしている。

• プロジェクトマネジメント
• プロジェクトの統合
• プロジェクトのステークホルダ
• プロジェクトのスコープ
• プロジェクトの資源
• プロジェクトの時間
• プロジェクトのコスト
• プロジェクトのリスク
• プロジェクトの品質
• プロジェクトの調達
• プロジェクトのコミュニケーション
• 応用情報技術者 午後 問題のテーマ
• 本稿の参考文献

プロジェクトマネジメント

(1) プロジェクト，及びプロジェクトマネジメントの目的と考え方

① プロジェクトとは何か，プロジェクトマネジメントとは何か

プロジェクト

プロジェクト（project）^[1]とは「プロジェクトの目的を達成するために実施される，開始日と終了日を持つ調整されかつコントロールされたアクティビティで構成されるプロセスの集合体」（ISO 21500 : 2012）である。簡単にいえば，プロジェクトとは「独自の目的・目標を設定し，それを期限までに達成させる一連の活動」である。

特に、期限が定まっていたり、具体的な目標を達成したら終了するような限定性を持った計画のことを意味する。訳語として「計画」が当てられることもあるが、実施の過程を含む概念である。

プロジェクトと定常業務には，以下の違いがある。企業や組織は，プロジェクトと定常・継続業務の 2 つの活動で価値を生み出し，世の中にその価値を提供している。

プロジェクトには，「納期」「品質」「予算」について 1 つの基準を設定し，それを満たすように開発が進められる。しかし，これらの要素は互いに相反する関係にあるため，調整が必要になることがある。また，プロジェクトの実行中に起こるさまざまな問題を，リスクの少ない方法で解決していかなければならない。

プロジェクトマネジメント

「プロジェクトマネジメント」とは，「方法，ツール，手法及びコンピテンシーを，あるプロジェクトに適用すること」（ISO 21500 : 2012）である。簡単にいうと，独自の目的・目標を期限までに達成するため「やりくり」する手法である。

1 つのプロジェクトを成功させるためには，プロジェクトを計画，実行する中でさまざまな管理を行う必要がある。その管理を行う責任者をプロジェクトマネージャ（Project Manager : PM）と呼び，管理のために体系化された知識やツール，技法を適用して，プロジェクトを成功に導く管理活動をプロジェクトマネジメントという。

プロジェクトの環境

プロジェクトポートフォリオマネジメント

プログラム

プログラムマネジメント

プロジェクトガバナンス

ISO 21500 によれば，プロジェクトガバナンスを維持する責任は，プロジェクトを承認して経営的判断を下すプロジェクトスポンサ，又は上級経営レベルでの指導をするプロジェクト運営委員会にある。

プロジェクトライフサイクル

JIS Q 21500:2018「プロジェクトマネジメントの手引」"Guidance on project management" によるとプロジェクトライフサイクル (project life cycle) とは，プロジェクトの開始から終了までが定義されたフェーズの集合である。

プロジェクトの規模や複雑さは様々あるが，① プロジェクト開始，② 組織編成と準備，③ 作業実施，④ プロジェクト終結の 4 段階で表現することができる。

プロジェクトの開始時は不確実性の度合いが最も高いので，プロジェクト目標が達成できないリスクが最も大きい。

プロジェクトライフサイクルにおける典型的なコストと要員数は，プロジェクト開始時に少なく，作業を実行するにつれて頂点に達し，プロジェクトが終了に近づくと急激に落ち込む。

また，ステークホルダの影響力，リスク，不確実性は，プロジェクト開始時に最大であり，プロジェクトが進むにつれて徐々に低下する。変更コストは，プロジェクトが終了に近づれて大幅に増加していく。

プロジェクトの制約

JIS Q 21500:2018「プロジェクトマネジメントの手引」"Guidance on project management" によれば，制約には幾つかの種類があり，しばしば相互依存の関係にあるので，プロジェクトマネージャは他の制約に照らして特定の制約の釣合いをとることが重要である。プロジェクト成果物は，プロジェクトに関する要求事項を満たし，スコープ，品質，スケジュール，資源，コストなど，あらゆる所与の制約に関連付けることが望ましい。制約は，一般に相互に関係していて，一つの制約の変化が，ほかの一つ又は複数の制約に影響を及ぼすことがある。したがって，制約はプロジェクトマネジメントのプロセスの意思決定に影響を与えることがある。

主要なプロジェクトのステークホルダ間で制約に関する意見の合致の達成は，プロジェクト成功の強力な基盤を形成することがある。

制約としては，次のようなものが挙げられる。

• プロジェクトの期間又は目標期日
• プロジェクトの予算の利用可能性
• 人員，施設，機器，材料，インフラストラクチャ，ツール，その他の資源など，プロジェクトの要求事項に関連するプロジェクト活動の実施に必要なプロジェクトの資源の利用可能性
• 要員の健康及び安全に関連する要因
• 受け入れ可能なリスク発現のレベル
• プロジェクトの潜在的な社会又は環境への影響
• 法律，規則及びその他の法的要求事項

JIS Q 21500

JIS Q 21500:2018「プロジェクトマネジメントの手引」"Guidance on project management" は，プロジェクトの実施に重要で，かつ，影響を及ぼすプロジェクトマネジメントの概念及びプロセスに関する包括的な手引を提供する。

この企画が対象とする利用者は，次の者を想定している。

• 上級管理者及びプロジェクトスポンサ：プロジェクトマネジメントの原則及び実務の理解を深めて，プロジェクトマネージャ，プロジェクトマネジメントチーム及びプロジェクトチームへの適切な支援及び指導を行いやすくする。
• プロジェクトマネージャ，プロジェクトマネジメントチーム及びプロジェクトチームの構成員：自らのプロジェクト標準及び実施標準をほかのプロジェクト標準及び実施標準と比較するための共通の基盤をもてるようにする。
• 国家又は組織の規格の作成者：ほかのプロジェクトマネジメント規格と中核レベルで一貫性のあるプロジェクトマネジメント規格の作成に使用する。

PMBOK（Project Management Body Of Knowledge）

プロジェクトマネジメントに関する知識を体系化したもので，業種や分野を問わない汎用性の高い知識体系であることから，国際標準としてさまざまなプロジェクトに利用されている。

PMBOK 第6版では，知識の体系を次表に示す 10 の領域で構成し，これに基づいてプロジェクトを管理していく。

PMBOK 第7版には「過去の版のプロセスベース・アプローチとの整合を無効にする内容は一切存在しない」と書かれているように，PMBOK 第6版は第7版が刊行されても有用で使用することが求められている。ちなみに PMBOK 第6版は 740 ページもあったのに対し，PMBOK 第7版は 274 ページしかない。

PMBOK 第7版の原理原則を次表に示す。

テーラリングとは，元々はオーダースーツを仕立てる時などに使われる言葉である。これがビジネスの世界で使われると，組織や企業が標準プロセスや開発標準などを適用する時に，当該組織や企業にフィットするように“仕立てる”という意味で使われる。システム開発プロジェクトの世界でも，PMBOK ではテーラリングを次のように定義している。

プロジェクトをマネジメントするために，プロセス，インプット，ツール，技法，アウトプットおよびライフサイクル・フェーズの適切な組み合わせを決めること

（出典）PMBOK 第6版

アプローチ，ガバナンス，プロセスが，特定の環境および目前のタスクにより適合するように，それらを慎重に適応させること

（出典）PMBOK 第7版

② プロジェクトで使用するプロセスの三つの主な種類

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

引渡しのプロセス

支援のプロセス

③ プロジェクトマネジメントの五つのプロセス群

プロジェクトマジメントのプロセス群には，立ち上げ，計画，実行，管理，終結の 5 つがある。

立ち上げのプロセス群

立ち上げのプロセスは，プロジェクトフェーズ又はプロジェクトを開始するために使用し，プロジェクトフェーズ又はプロジェクトの目標を定義し，プロジェクトマネージャがプロジェクト作業を進める許可を得るために使用する。

計画のプロセス群

計画のプロセスは，計画の詳細を作成するために使用される。ここでいう詳細とは，プロジェクトの実行をマネジメントすること及びプロジェクトパフォーマンスの測定及び管理をすることができるようなベースラインを確定するために十分であることが望ましい。

実行のプロセス群

実行のプロセスは，プロジェクトマネジメントの活動を遂行し，プロジェクトの全体計画に従ってプロジェクトの成果物の提示を支援するために使用する。具体的には、以下のプロセスが含まれる。

管理のプロセス群

管理のプロセスは，プロジェクトの計画に照らしてプロジェクトパフォーマンスを監視し，測定し，管理するために使用する。その結果，プロジェクトの目標を達成するために必要なときは，予防及び是正処置をとり，変更要求を行うことがある。

PMBOK 第 6 版によると，管理のプロセス群（監視・コントロール・プロセス群）のプロセス群は以下のとおり。

終結のプロセス群

終結のプロセスは，プロジェクトフェーズ又はプロジェクトが完了したことを正式に確定するために使用し，必要に応じて考慮し，実行するように得た教訓を提供するために使用する。

プロジェクト統合マネジメントの「プロジェクトやフェーズの終結」が該当する。

④ プロジェクトマネジメントの十の対象群

各対象群は，あらゆるプロジェクトフェーズ又はプロジェクトに適用するプロセスで構成する。

統合の対象群

統合の対象群には，プロジェクトに関連する様々な活動及びプロセスを特定し，定義し，組み合わせ，一体化し，調整し，管理し，更に終結するために必要なプロセスを含む。

ステークホルダの対象群

ステークホルダの対象群には，プロジェクトスポンサ，顧客及びその他のステークホルダを特定し，マネジメントするために必要なプロセスを含む。

スコープの対象群

スコープの対象群には，作業及び成果物のうち必要とするものだけを特定し，定義するために必要なプロセスを含む。

資源の対象群

資源の対象群には，人員，施設，機器，材料，インフラストラクチャ，ツールなど，適切なプロジェクト資源を特定し，得るために必要なプロセスを含む。

時間の対象群

時間の対象群には，プロジェクト活動のスケジュールを立て，進捗状況を監視してスケジュールを管理するために必要なプロセスを含む。

コストの対象群

コストの対象群には，予算を作成し，進捗状況を監視してコストを管理するために必要なプロセスを含む。

リスクの対象群

リスクの対象群には，脅威及び機会を特定し，マネジメントするために必要なプロセスを含む。

品質の対象群

品質の対象群には，品質の保証及び管理を計画し，確定するために必要なプロセスが含まれる。

調達の対象群

調達の対象群には，製品，サービス又は結果を計画し，入手し，供給者との関係をマネジメントするために必要なプロセスを含む。

コミュニケーションの対象群

コミュニケーションの対象群には，プロジェクトに関連する情報の計画，マネジメント及び配布に必要なプロセスを含む。

(2) プロジェクトの体制と自己管理

① プロジェクトの体制

プロジェクトスポンサ

プロジェクトスポンサは、プロジェクトに対して資金などのリソースを提供する立場の人・グループである。

JIS Q 21500:2018 によれば，プロジェクトスポンサは，プロジェクトを許可し，経営的決定を下し，プロジェクトマネージャの権限を超える問題及び対立を解決する。

プロジェクトマネージャ

プロジェクトマネージャは、豊富な業務経験、情報技術の知識、リーダシップをもち、プロジェクトの運営を管理する役職である。

JIS Q 21500:2018 によれば，プロジェクトマネージャは，プロジェクトの活動を指揮し，マネジメントして，プロジェクトの完了に説明義務を負う。

プロジェクトマネージャがシステム開発プロジェクトを推進するために，システム化計画書に基づいてプロジェクト管理計画書を作成し，承認を得る。

「SE の教科書【完全版】」（深沢隆司，技術評論社，2009年11月25日）によると，プロジェクトマネージャは，次のように説明されている。

プロジェクトマネージャーは，プロジェクトを成功裡に終了できるように，業務システム開発プロジェクトを計画し，指揮し，コントロールします。いわゆるプロジェクトマネジメントを行う人です。

プロジェクトマネージャーは，「コミュニケーションに 90 % 以上もの時間を費やす」とされている職種です。

一般に，このプロジェクトマネジャーという役割が明確になってきたのはここ数年のことで，かつてはこの役割を行う人のことも「SE」と呼ぶ場合も少なくありませんでした。プロジェクトの規模や種類によっては，現在でも SE がプロジェクトマネジメントを行っていることもあります。

（出典）「SE の教科書【完全版】」（深沢隆司，技術評論社，2009年11月25日）

「情報処理教科書 プロジェクトマネージャ 2022年版」（IT のプロ 46 三好 康之，翔泳社，2022年3月22日）では，基本的なプロジェクトマネージャの仕事（行動）は，次の 3 つであるとしている。

• 意思決定をする
• 指示を出す
• 設計や開発作業はしない

（出典）「情報処理教科書 プロジェクトマネージャ 2022年版」（IT のプロ 46 三好 康之，翔泳社，2022年3月22日）

プロジェクトマネジメントチーム

プロジェクトマネジメントチームは、プロジェクトマネージャを含めプロジェクト管理に関わる人達である。

JIS Q 21500:2018 によれば，プロジェクトマネジメントチームは，プロジェクトの活動を指揮し，マネジメントするプロジェクトマネージャを支援する。

PMO (Project Management Office)

プロジェクトマネジメントオフィス（PMO : Project Management Office）は、企業内で並行して実施されている個々のプロジェクトのマネジメント業務の支援、プロジェクトマネージャのサポート、部門間の調整などプロジェクトが円滑に実施されるように支援を行う専門の部署である。PMBOK 第6版では PMO を「プロジェクトに関連するガバナンス・プロセスを標準化し、資源、方法論、ルール及び技法の共有を促進する組織」と定義している。

また，JIS Q 21500:2018 によれば，プロジェクトマネジメントオフィスは，ガバナンス，標準化，プロジェクトマネジメントの教育訓練，プロジェクトの計画及びプロジェクトの監視を含む多彩な活動を遂行することがある。

プロジェクトマネージャが特定のプロジェクト目標の達成に焦点を当て、最も良い方法で与えられた組織の資源をコントロールするのに対し、PMO はプロジェクト間の相互関係をマネジメントし、全てのプロジェクトに対して組織内の共有資源の使用を最適化する。

日本 PMO 協会によれば，一般的な PMO の業務内容は，次のようなものである。

• プロジェクトマネジメント方式の標準化
• プロジェクトマネジメントに関する研修など人材開発
• プロジェクトマネジメント業務の支援
• プロジェクト間のリソースやコストの各種調整
• 個別企業に適応したプロジェクト環境の整備
• その他付随するプロジェクト関連管理業務

② 自己管理

作業計画立案

作業量見積り

進捗管理

品質管理

コスト管理

リスク管理

変更管理

JIS Q 21500:2018 において，是正処理，予防処置，欠陥修正など全ての変更要求は，管理プロセス群の「変更の管理」と実行プロセス群の「プロジェクト作業の指揮」に属する。

変更管理手順の例を下表に示す。

問題発見

問題報告

対策立案

文書化

コミュニケーション

プロジェクトの統合

(1) 統合の対象群が含むプロセス

プロジェクト憲章の作成

PMBOK において，プロジェクト憲章は，プロジェクト統合マネジメントの立上げプロセス群で作成する。

プロジェクト憲章作成前の重要ポイントは，以下の 3 点である。

1. プロジェクト憲章よりも前に作成されたプロジェクトに関連する文書類を入手しまとめること
2. これらの文書をしっかりと読み，内容を理解すること
3. 不明点については文書を作成した関係者にしっかりと確認すること

プロジェクト憲章で最低限明確にする内容は，以下の通り。

プロジェクト全体計画の作成

プロジェクト作業の指揮

プロジェクト作業の管理

JIS Q 21500:2018（プロジェクトマネジメントの手引）によれば，プロセス "プロジェクト作業の管理" の目的は，プロジェクト全体計画に従って，総合的な方法でプロジェクト活動を完了することである。

変更の管理

JIS Q 21500:2018（プロジェクトマネジメントの手引）によれば，プロセス "変更の管理" の目的は，プロジェクト及び成果物に加えられる変更を管理し，次の実施の前に，これらの変更の受け入れ又は棄却を公式にすることである。

プロジェクトフェーズ又はプロジェクトの終結

得た教訓の収集

(2) 主要なインプット及びアウトプット

プロジェクト作業規定書

契約

ビジネスケース

プロジェクト憲章

PMBOK 第 5 版 によれば，「プロジェクト憲章は，プロジェクトの存在を正式に認可し，プロジェクト活動に組織の資源を適用する権限をプロジェクトマネージャーに与えるための文書」とされている。プロジェクト憲章に記載する内容の代表的なものを以下に示す。

• プロジェクトの目的または正当性
• プロジェクトの目標
• 前提条件と制約条件
• 要約予算
• 任命されたプロジェクト・マネージャー，その責任と権限のレベル
• スポンサーやステークホルダー

プロジェクト全体計画（プロジェクト計画及びプロジェクトマネジメント計画）

プロジェクトマネジメント計画書は，どのようにプロジェクトを実施し，監視し，管理するのかを定めるために，プロジェクトを実施するためのベースライン，並びにプロジェクトの実行，管理，及び終結する方法を明確にした文書である。

変更要求

"変更要求" の申請を契機に相互に作用するプロセスグループの組みは，実行，コントロールである。

承認された変更

変更登録簿

是正処置

プロジェクト完了報告書

プロジェクト又はフェーズの終結報告書

得た教訓文書

(3) ツールと技法

ベースライン

ベースライン (baseline) は，監視され，管理されるプロジェクト・パフォーマンスと照らして比較するための参照基準。

CCB（Change Control Board：変更管理委員会）

問題点管理表

プロジェクト評価

プロジェクト評価指標

プロジェクトのステークホルダ

(1) ステークホルダの対象群が含むプロセス

ステークホルダの特定

ステークホルダとは「プロジェクトの任意の局面に利害関係をもつか，影響を及ぼすか，影響されるか，又は影響されると自覚する人，グループ又は組織」（ISO 21500 : 2012）である。一般的に日本語では「利害関係者」と呼ばれる。

プロセス "ステークホルダの特定" の目的は，プロジェクトに影響されるか，又は影響を及ぼす個人，集団又は組織を明らかにし，その利害及び関係に関連する情報を文書化することである。

プロジェクト憲章が承認され，プロジェクトマネージャが任命されたら，プロジェクトマネージャはステークホルダを特定する。

PMBOK での定義におけるプロジェクトとステークホルダの関係は，以下のとおり。

サプライヤ

サプライヤは，契約に基づいてプロジェクトに必要な構成アイテムやサービスを提供する。

スポンサ

スポンサは，プロジェクトに対して資金や現物などの財政的資源を提供する。

プログラムマネージャ

プログラムマネージャは，関連するプロジェクトの調和がとれるように，個々のプロジェクトの支援や指導をする。

納入者

納入者は，プロジェクトが創造するプロダクトやサービスを使用する。

ステークホルダのマネジメント

PMBOK ガイド 第 6 版 における "プロジェクト・ステークホルダー・マネジメント" には，次の 4 つのプロセスが定義されている。

ステークホルダの特定

プロジェクトのステークホルダーを定期的に特定し，プロジェクト成功への関心事，関与，相互依存，影響，および潜在的影響に関連する情報を分析し，文書化するプロセス

ステークホルダ・エンゲージメントの計画

プロジェクトに影響を与える人・グループ・組織を特定して，影響度や関心を分析して，ステークホルダーがプロジェクトへ関与することを促すための戦略を策定するプロセス

ステークホルダ・エンゲージメントのマネジメント

ステークホルダーのニーズや期待に応え，課題に対処し，ステークホルダーの適切な関与を促すためにステークホルダーとコミュニケーションをとり，協働するプロセス

ステークホルダ・エンゲージメントの監視

エンゲージメント戦略と計画の改訂を通して，プロジェクトのステークホルダーとの関係を監視し，ステークホルダーの関与のための戦略をテーラリングするプロセス

ステークホルダ・エンゲージメントのマネジメントには次の活動が含まれる。

• ステークホルダーをプロジェクトの適切な段階で関与させ，プロジェクトの成功へのステークホルダーの継続的なコミットメントを獲得し，確認し，または維持する。
• 交渉やコミュニケーションを通してステークホルダーの期待をマネジメントする。
• ステークホルダー・マネジメントに関連するリスクや潜在的な懸念に対処し，ステークホルダーから提示され得る将来の課題を予測する。
• 特定された課題を明確にし，解決する。

ちなみに，PMBOK では，交渉を成功させるための行動について，次のようなものをあげている。

• 状況を分析する。
• 相手と自分の要求と必要性を区分する。
• 立場ではなく，利害と課題に焦点をあてる。
• 要求は高く，低次は低く，ただし現実的に対処する。
• 譲歩する場合は，何か価値のあるものを生み出しているように振舞う。単純な譲歩はしない。
• 常に，当事者両方が成功したと思えるようにする。これがウィン・ウィンの交渉術である。相手に上手くやられたという思いを決して感じさせない。
• よく傾聴し，明確に表現する。

PMBOK ガイド 第 4 版

(2) 主要なインプット及びアウトプット

ステークホルダ登録簿

ステークホルダ特定と分析が終わったら，それらの結果をステークホルダ登録簿としてしっかりと明文化しておく。ステークホルダ登録簿には，ステークホルダの氏名や評価情報などを記載する。

あるプロジェクトに関わるステークホルダを特定し，その特性を次表の主要なステークホルダ登録簿のように整理する。ステーク登録簿を作成することで，主要なステークホルダに対して適切な対応を取ることができる。

(3) ツールと技法

ステークホルダ分析

ステークホルダ分析には「ステークホルダ分類マトリクス」が役に立つ。縦軸に「プロジェクトへの権限」，横軸に「プロジェクトへの興味・関心」を設定し，それぞれの軸に「高」「低」を設け，2 × 2 のマトリクスを作る。

この分析により，ステークホルダを分類することができ，今後のステークホルダへの対応や優先順位付けや対応方針が明確になる。

プロジェクトのスコープ

(1) スコープの対象群が含むプロセス

プロジェク卜・スコープ・マネジメントは、プロジェクトの遂行に必要な作業を過不足なく含め、プロジェクトを成功させることを目的とした管理プロセスで、以下の作業プロセスが含まれる。

1. スコープマネジメント計画
2. 要求事項収集
3. スコープ（実施範囲）定義
4. WBS 作成
5. スコープコントロール
6. スコープ妥当性確認

スコープの定義

プロジェクトで作成する成果物およびそのための作業範囲をスコープ^[1]と呼ぶ。スコープの定義に不備があると，成果物や作業に漏れが生じ，本来は必要のない作業に時間やコストを費やすなど，プロジェクトの進行に悪影響を及ぼす。そこで，WBS という手法を使ってスコープの洗出しを行う。

WBS（Work Breakdown Structure，作業分解図）の作成

作業を段階的に分解する（トップダウン方式）のための手法である。これにより，プロジェクトの作業は段階階層となり，最下層の作業が実際の管理の単位（ワークパッケージ）になる。PMBOK によれば，WBS で定義するものは，プロジェクトで行う作業を階層的に要素分解したワークパッケージである。

プロジェクトスコープマネジメントにおいて，WBS の作成に用いるローリングウェーブ計画法では，将来実施予定の作業については，上位レベルの WBS にとどめておき，詳細が明確になってから，要素分解して詳細な WBS を作成する。

WBS の作成には、作業の漏れや抜けを防ぎ、プロジェクトの範囲を明確にすると同時に、作業単位ごとに内容・日程・目標を設定することでコントロールをしやすくする目的がある。

活動の定義

活動（アクティビティ）とは，ワークパッケージの基準となっている生活物を生成するための具体的な作業単位に分割したものである。

スコープの管理

プロジェクトを実行している間、プロジェクトスコープと成果物スコープの状況を監視し、スコープの差異や変更が、WBS やスコープ記述書に適切に反映されるように管理するプロセスである。具体的な活動として，連携する計画であった外部システムのリリースが延期になったので，この外部システムとの連携に関わる作業は別プロジェクトで実施すること，が挙げられる。

(2) 主要なインプット及びアウトプット

スコープ規定書

スコープ規定書とは、プロジェクトで対応するシステムの機能や作業内容を定義するドキュメントである。

プロジェクトスコープ記述書とは，プロジェクトの最終状態を定義することによって，プロジェクトの目標，成果物，要求事項及び境界を含むプロジェクトスコープを明確にした文書である。

WBS

プロジェクト目標を達成し，必要な成果物を作成するために，プロジェクト・チームが実行する作業の全範囲を階層的に要素分解したもの。

WBS 辞書 (work breakdown structure dictionary)

WBS 辞書は，WBS の各構成要素について規定した文書。WBS 作成プロセスにおいて生成する文書であり，WBS を補完する。具体的には，各 WBS 要素に対応する作業の詳細の記述や技術的な文書の詳細な記述を行う。

活動リスト

進捗データ

(3) ツールと技法

スコープ（作業及び成果物）

ワークパッケージ

ワークパッケージとは、WBSの最下層に並べられる作業単位で、進捗やパフォーマンスの計測や状況をコントロールするのに用いられる。

要素分解

WBS は通常，レベル 1 にプロジェクトの最終成果を置き，そこから順番にレベル 2 への分解，レベル 3 への分解と徐々に細かくしていく。

100 パーセントルール

100 パーセントルールは，要素分解を行う上で最も重要なルールである。一言でいえば，「子要素をすべて足し合わせると親要素と等しくなる」というものである。

プロジェクトスコープのクリープ

プロジェクトスコープのクリープとは，時間，コスト及び資源の調整が行われず，コントロールされていないプロジェクトスコープの変更である。

プロジェクトの資源

プロジェクト資源マネジメントは，プロジェクトチームのメンバが各々の役割と責任を全うすることでチームとして機能し，プロジェクトの目標を達成することを目的に行われる。

(1) 資源の対象群が含むプロセス

プロジェクトチームの編成

プロジェクトの完遂に必要な能力をもったプロジェクトチームのメンバを招集し，人的資源を得る。

ブルックスの法則（Brooks’s law）とは，「遅れているソフトウェアプロジェクトへの要員追加は，プロジェクトをさらに遅らせる」という，ソフトウェア開発のプロジェクトマネジメントに関する法則のことである。

ブルックスによれば，この法則が成り立つ主な理由は，以下のとおりである。

1. 新たに投入された開発者が生産性の向上に貢献するまでには，時間がかかる。
2. 人員の投下は，チーム内のコミュニケーションコストを増大させる。
3. タスクの分解可能性には限界がある。

資源の見積り

PMBOK によれば，アクティビティの所要期間を見積もる際の資源カレンダーの用途として，アクティビティが必要とする資源を利用できる作業日及びシフトを取得する。

プロジェクト組織の定義

プロジェクトチームの開発

プロジェクトチームの育成の目的は，継続的にプロジェクトチームのメンバのパフォーマンス及び相互関係を改善することである。

資源の管理

プロジェクトチームのマネジメント

プロジェクトチームのマネジメントの目的は，チームのパフォーマンスを最大限に引き上げ，フィードバックを提供し，課題を解決し，コミュニケーションを促し，変更を調整して，プロジェクトの成功を達成することである。

プロジェクトチームのパフォーマンスを評価分析し，分析結果をフィードバックして問題を解決し，変更を調整する。

(2) 主要なインプット及びアウトプット

資源要求事項

プロジェクトの組織図

役割規定書

資源計画

(3) ツールと技法

RAM（Responsibility Assignment Matrix ： 責任分担マトリックス）

RACI チャートは，RAM（責任分担マトリックス）の一種で，二次元の表の各軸に要員名と作業を設定し，それぞれの要員が担う役割および負う責任を作業別に一覧にしたものである。プロジェクト内での責任を明確化するとともに，作業が適切に割り振られる手助けをする。

• Responsible（実行責任）
• Accountable（説明責任）
• Consulted（相談対応）
• Informed（報告先，情報提供）

OBS（Organizational Breakdown Structure：組織ブレークダウンストラクチャ）

RBS（Resource Breakdown Structure：資源ブレークダウンストラクチャ）

タックマンモデル（成立期，動乱期，安定期，遂行期，解散期）

タックマンモデルとは，1965 年にタックマンという心理学者が提唱した手法で，組織を進化させるまでを 5 段階のステージに分けて行う。組織は，体制を整えただけで完了ではなく，さまざまな問題の解決を行って理想の組織にしていく必要がある。

成立期（Forming）

成立期（Forming）は，チームが結成されたばかりの初期段階を指す。この段階では，メンバーがお互いの人となりや能力・考え方・価値観などを把握していないため，不安や緊張感・ぎこちなさが生じがちである。

動乱期（Storming）

メンバの異なる考え方や価値観が明確になり，メンバがそれぞれの意見を主張し合う段階

安定期（Norming）

仕事の進め方や考え方に関する意見の食い違いを乗り越え，メンバー全員が共通の目標や役割を持てるようになった段階

遂行期（Performing）

チームが組織として機能し，成功体験を積めるようになる時期が遂行期（Performing）である。各メンバーは自身の役割を正しく認識し，互いの個性を認め合いながら自信を持って活動するため，次々と成果を出すことができる。

解散期（Adjourning）

どのようなチームでも，未来永劫活動を続けるわけではない。目的を達成できたり，時間の制約を受けたりするとやがて解散となる。この時期が解散期（Adjourning）である。

コンフリクトマネジメント

コンフリクトマネジメントとは，組織の効果やパフォーマンス，学習やグループの成果を高めるため，紛争の肯定的な側面を増やしながら，紛争の否定的な側面を制限するプロセスである。コンフリクト（conflict）とは，「紛争」を意味しており，コンフリクトマネジメントを直訳すると「紛争管理」となる。

PMBOK の中でコンフリクトマネジメントは，プロジェクト憲章の作成プロセスや，チームのマネジメントのプロセス，コミュニケーションのマネジメントのプロセスで使用される人間関係とチームに関するスキルである。

コンフリクトマネジメントを行う際の指針として，コンフリクトの解決に当たっては，過去の経緯ではなく現在の課題に焦点を当てる。

プロジェクトの時間

プロジェクトタイムマネジメントでは，プロジェクトを所定の時期に完了させることを目的とする。プロジェクトだけでなく，プロジェクトに関わる要員それぞれの進捗管理も重要である。

(1) 時間の対象群が含むプロセス

活動の順序付け

活動期間の見積り

スケジュールの作成

スケジュールの管理

(2) 主要なインプット及びアウトプット

活動順序

活動所用期間見積り

活動リスト

スケジュールの制約

スケジュール

(3) ツールと技法

類推見積り

類似のプロジェクトにおける過去のコスト実績を使って，プロジェクトのコストを見積もる。

パラメトリック見積り

パラメトリック見積り（係数見積り）は、過去に蓄積したデータと関連する変数との統計上の関係を使って、見積りを行う手法である。試験でよく登場する "ファンクションポイント法" や "COCOMO" 及び "プログラムステップ法" もパラメトリック見積りの一種である。

IPA の Web ページ内では、「工数などを目的変数として、説明変数に規模や要員などを設定し、数学的な関数として表す方法」と説明されている。

三点見積り

楽観値，悲観値，最頻値を使って，個々のアクティビティのコストを見積もる。

ボトムアップ見積り

ボトムアップ見積りは，作業の内容を十分に把握している場合に使われる。作業の構成要素の工数を見積り，それを積み上げることによって全体の工数を見積もる。

予備設定分析

スケジュールネットワーク分析

PERT (Program Evaluation and Review Technique)

1958 年に米国で開発された工程管理手法。ADM (Arrow Diagramming Method) とクリティカルパスをベースに 3 点見積りの加重平均を用いるという特徴を持つ。

PERT では，最初に作業の前後関係を ADM で図示する。次に，各作業（アクティビティ）の所要期間を見積もる。この見積り段階で 3 点見積り法を使い，最頻値（最も実現の可能性が高い値），楽観値（最良のシナリオで進んだとき），悲観値（最悪のシナリオで進んだとき）の 3 パターンを求める。そうして求めた結果を以下の式を使って期待値を求め，それを各作業の所要期間とする。こうして所要日数を求めるため，リスクを呼応慮したスケジュールが作成できる。

CPM（Critical Path Method：クリティカルパス法）

PERT と同時期に独立して開発されたスケジュール作成方法。作業関係の依存関係だけに着目してクリティカルパスを算出し，スケジュールの柔軟性を判断する。

PDM（Precedence Diagramming Method：プレシデンスダイアグラム法）

個々の作業を四角で囲み、作業同士を矢印で結ぶことで作業順序や依存関係を表現する図法である。作業同士の関係を表すという意味ではアローダイアグラムと同じだが、アローダイアグラムでは作業を矢印で、結合点を丸のノードで示すので、記述方法が根本的に異なる。そして、アローダイアグラムでは、ある作業の終了が別の作業の開始条件となる「終了-開始」(FS：Finish to Start)の依存関係しか表現できませんが、プレシデンスダイアグラムでは「終了-開始」を合わせて計 4 つの関係を記述できることが特徴である。

プレシデンスダイアグラム法では，下図のように個々の作業を表す四角の四隅に数字を記述することがある。それぞれ，次の意味をもつ。

FF 関係（Finish-to-Finish，終了-終了）

「受付が終了したら試験会場への入場を終了する」というように、あるアクティビティの終了が、他方のアクティビティの終了条件になっている関係

FS 関係（Finish-to-Start，終了-開始）

「受付が終了してから試験を開始する」というように、あるアクティビティの終了が、他方のアクティビティの開始条件になっている関係

SF 関係（Start-to-Finish，開始-終了）

「試験が開始されたら受付を終了する」というように、あるアクティビティの開始が、他方のアクティビティの終了条件になっている関係

SS 関係（Start-to-Start，開始-開始）

「受付が開始されたら試験会場への入場を開始する」というように、あるアクティビティの開始が、他方のアクティビティの開始条件になっている関係

また「リード」と「ラグ」は、先行アクティビティに対して、後続アクティビティの開始を前倒しや後ろ倒しする制約がある場合にその時間を表すものである。

リード

先行アクティビティに対して、後続アクティビティの開始を前倒しできる時間

ラグ

先行アクティビティに対して、後続アクティビティの開始を遅らせる時間

クリティカルチェーン

クリティカルチェーン法（CCM : Critical Chain Method）は，イスラエルのエリヤフ・ゴールドラット (Eliyahu M. Goldratt) が提唱した TOC（Theory Of Constraints : 制約条件の理論）に基づくプロジェクト管理手法であり，不確定要素の多いプロジェクトにおいて，人間の心理や行動特性などを踏まえて作業工程の全体最適化や作業期間の短縮を指向するものである。

人（それぞれの作業タスクの作業者）は，作業の所要時間を見積もる際に，遅れが出ないようあらかじめ十分な余裕（安全時間）を確保しようとする特性があることに着目し，この余裕分（バッファ）を個々の作業タスク単位ではなくプロジェクト全体で集約して設定し（これをプロジェクトバッファ，または所要期間バッファという），かつ各作業タスクは 50 % の確率で終了する時間で見積もることによって，作業期間の大幅短縮を図る。また，クリティカルチェーン上にない作業タスクがクリティカルチェーンに合流する部分に安全時間（合流バッファ，またはフィーディングバッファ）を設ける。プロジェクトマネージャは，これらのバッファを調整し管理することで，全体最適な工程管理を行う。

標準タスク法

ソフトウェアの開発作業を標準作業に分解し，それらの標準作業ごとにあらかじめ決められた標準工数を割り当て，それらを合計して規模を見積もる。

アローダイヤグラム (ADM : Arrow Diagramming Method)

アローダイアグラム（arrow diagram，矢線図）とは、複数の要素の間を、それらの関係を意味する矢印で結んだ図。特に、複数の工程や手順の間の前後関係（先行後続）を矢印の向きによって表した図。

アローダイアグラムでは図上にプロジェクトを構成する工程を並べ、直接依存関係にある工程間を矢印で繋いでいく。これにより、ある工程を開始するために終わらせておかなければならない工程を、先頭から簡単にたどっていくことができる。

また、図上にはプロジェクトの開始から終了まで、いくつかの経路が現れることがあるが、経路上の工程の所要時間を足し合わせていくと、それぞれの経路全体の所要時間を求めることができる。その中で最も長い所要時間がプロジェクト全体の工期であり、そのような経路を「クリティカルパス」（critical path）という。

ガントチャート

ガントチャート（Gantt chart）とは、プロジェクトの工程管理などで用いられる図表の一つで、縦に並んだ棒グラフの列で計画や進捗を視覚的に表したもの。1910年代にアメリカの機械エンジニア、経営コンサルタントのヘンリー・ガント（Henry L. Gantt）が考案した。

縦軸に作業項目，横軸に時間をとり，作業に必要な期間を横棒の長さで表記する図法である。作業項目の重なりがわかりやすいので，日程計画の策定に使用されたり，計画と実績を並べて表記することで進捗を管理する方法としても用いられる。

図　ガントチャート

進捗率

計画した作業量に対して，実際に完了している作業量の割合を進捗率と呼び，作業の進捗状況を定量的に評価する。進捗率が 100 % であれば，計画した作業はすべて完了した，ということになる。

マイルストーン

マイルストーン（milestone）とは、里程標、一里塚、道標、などの意味を持つ英単語。転じて、歴史や工程などについて、画期的な出来事、重要な段階、節目、到達点、金字塔といった意味でも用いられる。原義のマイル標は、幹線道路の道路脇に1マイルごとに設置される、起点からの距離を記した標識のこと。

マイルストーンは，その名の通り，進捗管理上のマイルストーンを把握するのに適しており，プロジェクト全体の進捗管理などに利用される。

重み付けマイルストーン法は，ワークパッケージ内の特定のアクティビティをマイルストーンとして設定し，そのマイルストーンに到達したら何 % というように，あらかじめ進捗率を決めておく方法である。例えば，調査完了 20 %，設計完了 50 %，レビュー完了 70 %，承認完了 100 % といった具合である。

システムを開発するときの費用管理と進捗管理を同時に行うために，トレンドチャートを用いる。

トレンドチャートは，システム開発を行うときの費用管理と進捗管理を同時に行うための手法である。プロジェクトスケジュールにおけるマイルストーンが達成された時点で，その時点までの所要期間と予算消化率を評価する。予算消化の状態は縦（Y）軸で見て，進捗は横（X）軸で見るので，マイルストーンの予定の位置より実績の位置低ければ，予算を下回っていることになり，高ければ予算を上回っていることになる。同じ高さならば予算どおりである。また，マイルストーンの予定位置より実績の位置が左にあれば，進捗が予定より早いことになり，右にあれば遅れていることになる。

資源最適化（資源平準化，資源円滑化）

資源平準化と資源円滑化は，スケジュールの作成に際して使用可能な資源最適化の技法の例として定義されている。

資源平準化

資源の制約に基づき，資源の配分を最適化するためにアクティビティの開始日と終了日を調整する技法。共有される若しくは重要な資源が特定の期間や限られた量だけしか使えなかったり，人員などの共有資源が同時に実行される 2 つ以上のアクティビティに割り当てられた場合などに行われる。クリティカル・パスを変更する原因となることが多い。

資源円滑化

資源の要求量が所定の上限を超えないように，アクティビティが属しているフリーフロート（後続アクティビティの最早開始日を遅らせることなく当該アクティビティを遅らせることのできる期間）およびトータルフロート（プロジェクト全体の余裕期間）の範囲内でアクティビティを変更する技法。クリティカル・パスを変更することはない。

What-If シナリオ分析

What-If シナリオ分析では，個々のリスクが現実のものとなったときの，プロジェクトの目標に与える影響の度合いを調べる。

クラッシング

プロジェクトのスケジュールを短縮するために，アクティビティに割り当てる資源を増やして，アクティビティの所要期間を短縮する技法。例えば，メンバの時間外勤務を増やしたり、業務内容に精通したメンバを新たに増員するなど、クリティカルパス上のアクティビティに資源を追加投入して短縮を図る。

ファストトラッキング

開始当初の計画では直列に並んでいた作業を同時並行的に行い期間短縮を図る方法をファストトラッキングという。ただし，本来は順番通りになされるべきであった作業を並行して行うことになるので，順序や前後関係がより複雑になるなどの弊害もある。

次のような方法が，ファストトラッキングに該当する。

• 作業の前後関係を組み直し，実施する順番を変える。
• 作業を分析し，同時に実施できる部分を複数の作業に分割し，並行して実施する。
• 先行作業の一部の成果物が完成した時点で，後続作業を開始する。

ファストトラッキングの具体的な例として，全体の設計が完了する前に，仕様が固まっているモジュールを開発する。

ラグ

リード

傾向分析

プロジェクトマネジメントで使用する分析技法のうち，傾向分析では，時間の計画に伴うプロジェクトのパフォーマンスの変動を分析する。

傾向分析は，プロジェクトの実績を定期的に分析することで，時間経過に伴うプロジェクトのパフォーマンスの変動を調べる手法である。傾向を視覚的に把握するために「ランチャート」と呼ばれる，データを発生順に打点し，それを直線で結んだ折れ線グラフが用いられることがある。

差異分析

差異分析は，プロジェクトマネジメントの実績報告のプロセスにおいて，スコープ，コスト，スケジュールに関して，ベースラインと実績のかい離を明確にするために使用される。

EVM（Earned Value Management）

EVM（Earned Value Management）は，プロジェクトにおける作業を金銭の価値に置き換えて，コストとスケジュールの 2 つを定量的に管理する進捗管理手法である。PV，EV，AC という 3 つの指標を用いることが特徴である。

PV (Planned Value)

プロジェクト開始当初、現時点までに計画されていた作業に対する予算

EV (Earned Value)

現時点までに完了した作業に割り当てられていた予算

AC (Actual Cost)

現時点までに完了した作業に対して実際に投入した総コスト

各指標を比較して、EV - AC がマイナス値であれば完了済み作業に対する予算よりも投入コストが多いのでコスト超過、EV - PV がマイナス値であれば完了済み作業に対する予算が当初の予算よりも少ないので進捗遅れ、と判断することができる。

SPI（スケジュール効率指数）は，PV に対する EV の比率を示す。SPI が 1.0 より大きければスケジュールは進み，1.0 で計画通り，1.0 より小さければスケジュール遅延を意味する。

CPI（コスト効率指数）は，AC に対する EV の比率を示す。1.0 より大きければ実コストが計画より削減，1.0 ちょうどで計画通り，1.0 より小さければコスト超過を意味する。

EAC（完成時総コスト見積り）は，全作業完了までに予測される総コストで，発生済み実コストと残作業見積りの合計として表される。

大日程計画表（マスタスケジュール）

中日程計画表（工程別作業計画）

小日程計画表（週間作業計画）

進捗報告

コンティンジェンシ予備

プロジェクトリスクマネジメントで特定されている既知のリスクが現実化した場合に備えて確保される予備の時間や資金。「既知の未知」に備える。

マネジメント予備

プロジェクトスコープの範囲外の予期できない作業のために確保される予備の時間や資金。「未知の未知」に備える。

プロジェクトのコスト

プロジェクトコストマネジメントは，プロジェクトを決められた予算内で完了させることを目的に行われる。プロジェクトだけでなく，プロジェクトに関わる要員それぞれのコスト管理も重要である。

(1) コストの対象群が含むプロセス

コストの見積り

コストの見積りでは，複数の手法を併用して見積りの精度を高めることがある。

予算の作成

コストの管理

(2) 主要なインプット及びアウトプット

予算

実コスト

予想コスト

(3) ツールと技法

開発に必要なコストは，人件費や資源調達にかかる費用などさまざまある。ここでは，システムのソフトウェア開発のコストを見積もる代表的な手法を説明する。

類推見積り法

過去の類似するシステムを基に開発規模や工数を見積もる手法。

パラメトリック見積り

三点見積り

問題なく作業が完了するという楽観値，トラブルが生じることを想定した悲観値，最も可能性が高いと予測される最頻値から工数を見積もる手法。これら 3 種類の見積りに，それぞれルールに基づいて重みを付け，平均を求めることで，より精度の高い見積りを求める。

ボトムアップ見積り

予備設定分析

ファンクションポイント法

ファンクションポイント（FP : Function Point）法とは，ソフトウェアの機能を，外部入力，外部出力，内部論理ファンクション，外部インタフェースファイル，外部照会の 5 つのファンクションタイプに分けて，それぞれの機能の複雑さに基づいて工数を見積もる手法である。画面や帳票などユーザの目に見える単位で工数を見積もるため，見積もりの根拠をユーザが理解しやすい，という特徴がある。

また，開発に複数のプログラム言語を用いる場合，プログラム言語に依存しない見積りが行えることも特徴である。

ファンクションポイント法の一つである IFPUG 法では，機能を機能種別に従ってデータファンクションとトランザクションファンクションとに分類する。

LOC (Lines Of Code) 法

ソースコードの行数でプログラムの規模を見積もる方法である。従来からある方法だが，担当者によって見積り規模に大きな偏差が出ることから，客観的に計算できる FP 法が普及してきた。

COCOMO（Constructive Cost Model）

COCOMO（Constructive Cost Model）とは、ソフトウェア開発プロジェクトにかかる工数や期間などを見積もる手法の一つ。1981 年に TRW 社のバリー・ボーム（Barry W. Boehm）氏が提唱したもので、過去のソフトウェア開発プロジェクトから得られたデータを元に構築された統計的なモデルである。

COCOMO では、開発するプログラムの想定ソースコード行数を元に、プログラマの習熟度や再利用できるソフトウェアの量などの様々な要因から開発規模を見積もり、これに十数個の補正係数（「コストドライバ」と呼ばれる）を掛け合わせて工数を見積もり、最後に工数から開発期間を見積もる。

COCOMO を適用するには自社における生産性のデータ収集が不可欠である。

COCOMO には，システム開発の工数を見積もる式の一つとして次式がある。

COCOMO の式より，曲線の式を求める。

開発規模と開発生産性（開発規模／開発工数）の関係を表すと下図のようになる。ここで，開発工数の単位は人月，開発規模の単位はキロ行とする。開発規模が大きくなるにつれて，開発生産性は減少していく。

COCOMOⅡ（Constructive Cost Model Ⅱ）

EVM（Earned Value Management）

EVM（Earned Value Management）とは、プロジェクトマネジメントにおいて進捗状況の把握・管理を行う手法の一つ。作業の到達度を金銭などの価値に換算した EV（Earned Value：アーンドバリュー、出来高）という概念で把握する。

進捗遅延やコスト超過を早期に発見することを目的として，EVM 手法を用いたプロジェクト管理の例を示す。EVM 手法では，プロジェクトの計画と実績について，定量的な情報を用いて進捗状況やコスト状況を分析し，評価する。EVM 手法で使う各指標と意味の例を下表に示す。

TCPI（残作業効率指数，To-Complete-Performance-Index）は，進行中のプロジェクトのパフォーマンスを見るための指標であり，次式で求められる。

この式を言葉で表すと，「完成時総予算から出来高を引いたものを、完成時総コスト見積もりから実コストを引いたもので割った値」である。TCPI が 1 を超えていると，完成時総予算を超過するおそれがある。

アーンドスケジュール（ES）理論

コストベースライン

コンティンジェンシ予備

プロジェクトリスクマネジメントで特定されている既知のリスクが現実化した場合に備えて確保される予備の時間や資金。「既知のリスク」に備える。

マネジメント予備

プロジェクトスコープの範囲外の予期できない作業のために確保される予備の時間や資金。「未知のリスク」に備える。

気づいているリスクは既知のリスクである。しかし，気づかないリスクもビジネスには存在する。気づいていないリスクは未知のリスクである。

COSMIC 法

COSMIC（COmmon Software Measurement International Consortium）法は，利用者機能要件と機能プロセスに着目して，機能プロセスごとに 1. ～ 3. の手順で見積りを行う。

1. データ移動を型として識別し，エントリ，エグジット，読込み及び書込みの 4 種類に分類する。
2. データ移動の型ごとに，その呼数に単位規模を乗じる。
3. 2. で得た型ごとの値の合計を，機能プロセスの機能規模とする。

Doty モデル

ソフトウェア開発の工数は、プログラムのステップ数の指数乗に比例するという考え方で開発工数を見積もる手法。

putnam モデル

総開発工数から，それを分解した各開発工程の工数を推定するトップダウン式の手法。

プロジェクトのリスク

開発中には不測の事態がよく発生する。その原因は，人災，天災などさまざまであり，それによる被害も小さいものから大きなものまである。プロジェクトでは，これらの被害の影響を抑えるべく，リスクに備えた対策を用意する必要がある。

PMBOK ではリスクを「プロジェクトの進行に影響を及ぼす不確定の事象や状態」と定義している。プロジェクトに生じるリスクには，計画外の作業の発生や技術的なトラブル，要員数の不足などによるスケジュールの遅れや追加工数の発生などがある。

プロジェクトマネージャ（PM）には，プロジェクトの計画策定において，様々なリスクを想定し，その対応策を計画へ反映するプロアクティブな対応が求められる。

(1) リスクの対象群が含むプロセス

リスクの特定

リスクとは，もしそれが発生すれば，プロジェクト目標に影響を与える不確実な事象あるいは状態のことである。常に将来において起こるものが対象になる。すでに起こっていて明らかなものは課題（または問題点）と呼ばれ，リスクとは区別して管理する。リスクの特定では，可能性のあるリスクを洗い出す。

リスクの情報収集方法としては，参加者が自由にアイディアを出すブレーンストーミングや，専門家の間でアンケートを使用して質問を繰り返すことで合意を形成するデルファイ法，根本原因などが挙げられる。

PMBOK ガイド第 6 版によれば，リスクにはマイナスの影響を及ぼすリスク（脅威）とプラスの影響を及ぼすリスク（好機）がある。

プロセス "リスクへの特定" で実施するものは，プロジェクトのライフサイクルを通じて，プロジェクトの目標に影響を与えることがあるリスク事象及びその特性の決定を繰り返す，である。（出典）JIS Q 21500:2018（プロジェクトマネジメントの手引）

リスクの評価

PMBOK ガイド 第 6 版によれば，リスクの定量的分析で以下を実施する。

• プロジェクトの個別の特定した個別リスクと，プロジェクト目標全体における他の不確実性要因が複合した影響を数量的に分析する。

対象群 "リスク" の活動内容のうち，プロセス "リスクへの評価" で実施するものは，リスクの優先順位を定めるために，各リスクの発生確率及びそのリスクが発生した場合にプロジェクトの目標に及ぼす結果を推定する，である。（出典）JIS Q 21500:2018（プロジェクトマネジメントの手引）

リスクへの対応

洗出しを行ったリスクについて，すべてに対応することはコストの面から考えて現実的ではない。そのため，リスクについて発生する確率と影響を定性的・定量的に分析し，リスクの優先度を設定する。そのうえで，各リスクについて次表に示す対応策を検討する。

リスクの管理

プロセス "リスクへの管理" で実施するものは，プロジェクトの混乱を最小限にするために，リスク対応の有効性を評価しながらのリスク対応の進捗をレビューする，である。（出典）JIS Q 21500:2018（プロジェクトマネジメントの手引）

(2) 主要なインプット及びアウトプット

リスク登録簿 (risk register)

特定されたリスクの記録。それには，分析の結果及び計画された対応を含む。

優先順位付けされたリスク

発生の可能性や影響のみならず他の特性を評価することによって，さらなる分析や行動のためにプロジェクトの個別リスクに優先順位をつける。

ERP ソフトウェアパッケージ導入プロジェクトのリスク管理表の例を示す。

(3) ツールと技法

PMBOK ガイド 第 5 版によれば，プロジェクト・リスク・マネジメントでは，定性的リスク分析でリスクの優先順位を査定し，定量的リスク分析でリスクがプロジェクト目標全体に与える影響を数量的に分析する。

リスクの定性的分析技法

リスクの定性的分析のプロセスでは，プロジェクトの個別リスクに対して，発生確率や影響，他の特性を評価し，さらなる分析や行動のために個々のリスクに優先順位をつける。

定性的リスク分析で使用されるものは，発生確率・影響度マトリックスであり，リスクの発生確率と影響度をマトリックス状に視覚化したデータの表現方法である。

PMBOK では発生確率・影響度マトリックスを「各リスクの発生確率とリスクが発生した場合のプロジェクト目標に及ぼす影響度を格子状に位置づけたもの」としている。

リスクの定量的分析技法

リスクの定量的分析のプロセスでは，プロジェクトの個別リスク等を定量的に分析する。すべてのプロジェクトで必須ではないが，プロジェクトの全体リスクのエクスポージャーを定量化する。

EMV（Expected Monetary Value，期待金額価値）は，定量的リスク分析で用いられるリスクレベルの算定方法で，リスクが顕在化したときの影響金額に発生確率を乗じて求める。リスクは好機と脅威に分けられるため，プラスの結果をもたらすリスクは正の値，マイナスの結果をもたらすリスクは負の値で表す。

感度分析

どのリスクがプロジェクトに対して最も影響が大きいかを判断するのに役立つ定量的リスク分析とモデル化の技法として，感度分析がある。感度分析の結果を示した次の図はトルネード図である。一般的には軸からの変動幅が大きい順に上から並べる。

脅威への戦略

プロジェクトにマイナスの影響を与えるリスク（脅威）への対応戦略には，回避，転嫁，軽減，受容の 4 種類がある。

回避

リスクそのものを取り除いたり、プロジェクトに影響がないようにスコープや目標を縮小・変更する方策。

転嫁

リスクによるマイナスの影響を第三者へ移転する戦略。リスクのある業務・作業のアウトソーシングや、損害保険の契約によってリスクの影響を自社から他社に移転する。

軽減

リスクの影響範囲を狭くしたり、発生確率を低減するような方策。

受容

リスクが現実化した時の影響が許容可能範囲内である時やリスクの除去が困難である場合に、特段対策をせずにそのままにしておくこと。対策費用が予想される損失金額を上回っているときなどに採られる方策。

好機への戦略

プロジェクトにプラスの影響を与えるリスク（好機）への対応戦略には，活用，共有，強化，受容の 4 種類がある。

活用

好機が確実に到来するように、現実化の不確実性を取り除くための戦略

共有

好機を得られる能力の高い第三者にプロジェクトの実行権限の一部、または全部を与える戦略

強化

好機のプラスの影響を増加させたり、その発生確率を高めたりする戦略

需要

積極的な利用はしないが、好機が現実化したときにはその利益を享受しようとする戦略

コンティンジェンシ対応戦略

コンティンジェンシー計画：最悪の事態を想定した計画のことで，災害，事故，不正アクセス，情報漏えいなどを踏まえた不測の事態に対応する計画のこと。

RBS（Risk Breakdown Structure：リスクブレークダウンストラクチャ）

JIS Q 31000

プロジェクトの品質

プロジェクト品質マネジメントでは，プロジェクトのニーズを満足させることを目的とする。プロジェクトでは，必要に応じて行われる継続的プロセス改善活動とともに，方針，手順を通して品質マネジメントを実施する。

(1) 品質の対象群が含むプロセス

品質の計画

品質要求事項や品質標準を定め，プロジェクトでそれを順守するための方法を文書化する。

PMBOK ガイド 第 6 版によれば，プロジェクト品質マネジメントは，品質マネジメント計画，品質保証，品質コントロールの三つのプロセスで構成されている。品質マネジメント計画プロセスのアウトプットであって，品質保証プロセス及び品質コントロール・プロセスのインプットになるものは品質尺度である。

品質保証の遂行

適切な品質標準と運用基準の適用を確実に行うため，品質の要求事項と品質管理測定の結果を監査する。

品質管理の遂行

品質管理の遂行の目的は，確定したプロジェクトの目標，品質要求事項及び規格を満たしそうかどうかを明らかにし，不満足なパフォーマンスの原因及びそれを取り除くための方法を特定することである。

パフォーマンスを査定し，必要な変更を提案するために品質を監視するシステムなどの実行結果を監視し，記録する。QC 七つ道具や新 QC 七つ道具などを駆使する。

(2) 主要なインプット及びアウトプット

品質要求事項

システム開発プロジェクトで構築する情報システムの "品質要求事項" には，システム企画段階で決定され，プロジェクトが立ち上がった段階で，プロジェクトマネージャ（PM）が引き継ぐものもある。その品質要求事項を引き継いだ PM は，それ以降，「品質に対する要求事項」として，品質管理を計画し，実施していく。

このようなプロジェクト開始前の企画段階で決定される要求品質は，最重要の機能要件，および，非機能要件（性能，信頼性，操作性など）として定量目標値として設定される。

品質計画

品質計画は，顧客の要求する品質を確保するために計画を立てるプロセスである。具体的には，顧客の求める要求品質を明確にし，それらを確保するためのレビュー計画，テスト計画を立案する一連のプロセスを指す。

それらの結果は，品質マネジメント計画書としてまとめられ，プロジェクトマネジメント計画書に組み込まれる。

プロジェクトマネージャ（PM）は，システム開発プロジェクトの目的を達成するために，品質管理計画を策定して品質管理の徹底を図る必要がある。このとき，他のプロジェクト事例や全社的な標準として提供されている品質管理基準をそのまま適用しただけでは，プロジェクトの特徴に応じた品質状況の見極めが的確に行えず，品質面の要求事項を満たすことが困難になる場合がある。また，品質管理の単位が小さ過ぎると，プロジェクトの進捗及びコストに悪影響を及ぼす場合もある。

このような事態を招かないようにするために，PM は，例えば次のような点を十分に考慮した上で，プロジェクトの特徴に応じた実効性が高い品質管理計画を策定し，実施しなければならない。

• 信頼性などシステムに要求される事項を踏まえて，品質状況を的確に表す品質評価の指標，適切な品質管理の単位などを考慮した，プロジェクトとしての品質管理基準を設定すること
• 摘出した欠陥の件数などの定量的な観点に加えて，欠陥の内容に着目した定性的な観点からの品質評価も行うこと
• 品質評価のための情報の収集方法，品質評価の実施時期，実施体制などが，プロジェクトの体制に見合った内容になっており，実現性に問題がないこと

進捗データ

レビューにかける工数を算出する場合や，レビューの進捗状況を確認するために，次表のような基準を決めておく。

レビューと同様にテストの進捗状況を把握するための指標を次表に示す。

品質管理測定値

品質管理基準の例として，工程ごとに，レビュー指摘密度，摘出欠陥密度などの指標に関する基準値がある。

検査報告書

是正処置

PMBOK ガイド 第 5 版によれば，プロジェクトへの変更要求のうち，是正処置は，あるタスクが，プロジェクトマネジメント計画書に記載したスケジュールから遅れたので，遅れを解消させるために要員を追加することである。

予防処置

品質不良を発生させる要因（リスク）とそれらに対する予防的対策（リスク管理）には，次表のようなものがある。

(3) ツールと技法

プロジェクトにおける品質管理測定値の活用（データ表現技法の選択など）

費用便益分析

品質コスト（COQ）

プロジェクトの品質コストを適合コストと不適合コストに分類すると次表のようになる。

プロジェクトの調達

プロジェクト調達マネジメントの目的は，作業の実行に必要な資源やサービスを外部から購入，取得するために必要な契約やその管理を適切に行うことである。

(1) 調達の対象群が含むプロセス

調達の計画

プロジェクト調達の意思決定を文書化し，取り組み方を明確にして，納入候補を特定する。

供給者の選定

納入候補から回答を得て，納入者（サプライヤ）を選定し，契約を締結する。供給先を選定するため，基準を予め用意しておくことがある。

発注先選定基準書は，供給元からの提案の等級付けや採点のために作成し使用するものであり，開発会社の候補先に公開する場合もある。選定基準を作成しておくことで，私見によらない公正な選定ができる。また，供給者はより要求に合った提案を作成しやすくなる。

調達の運営管理

(2) 主要なインプット及びアウトプット

調達計画

情報提供・提案・入札・応札・見積りに関する依頼書

契約書又は注文書

選定された供給者リスト

(3) ツールと技法

プロジェクトにおける調達戦略（契約のタイプの選択など）

調達作業範囲記述書（SOW）

PMBOK ガイド 第 5 版によれば，プロジェクト調達マネジメントにおける調達作業範囲記述書に記載すべき項目は，プロジェクト完了後の調達品の運用サポートの内容である。

プロジェクトのコミュニケーション

プロジェクトコミュニケーションマネジメントは，プロジェクト情報の生成，収集，配布，補完，検索，最終的な廃棄を適宜，適切かつ確実に行うためのプロセスから構成される。人と情報を結びつける役割を果たすことが目的である。

プロジェクトマネージャ（PM）は，ステークホルダのニーズと期待を満たすために，適切なコミュニケーション計画を立案し，その計画に則って，プロジェクトを適切に運営する必要がある。

(1) コミュニケーションの対象群が含むプロセス

コミュニケーションの計画

JIS Q 21500:2018（プロジェクトマネジメントの手引）によれば，プロセス "コミュニケーションの計画" の目的は，プロジェクトのステークホルダの情報及びコミュニケーションのニーズを決定することである。

プロジェクトのコミュニケーションマネジメント計画書の内容には，次が含まれる。

• 情報伝達の手段
• 情報を受け取る人又はグループ
• 情報を配布するスケジュール
• 伝達すべき情報の内容，表現形式及び詳細度

ステアリングコミッティ

重要方針の意思決定が必要な時点で開催する。

全体会議

プロジェクト内での意志の統一と情報共有を図るために，プロジェクト関係者全員が出席し，（例として）月次で開催する。

進捗会議

プロジェクトの進捗や課題を協議し，共有する。（例として）週次で開催する。

情報の配布

プロセス "情報の配布" の目的は，プロジェクトのステークホルダに対し要求した情報を利用可能にすること及び情報に対する予期せぬ具体的な要求に対応することである。

情報配布の形態としては，相手の行動にかかわらず情報を提供するプッシュ型と，相手の行動に応じて情報を提供するプル型がある。また，相手の応答を受け取るフィードバック型もある。

コミュニケーションのマネジメント

JIS Q 21500:2018（プロジェクトマネジメントの手引）によれば，プロセス "コミュニケーションのマネジメント" の目的は，プロジェクトのステークホルダのコミュニケーションのニーズを確実に満足し，コミュニケーションの課題が発生したときにそれを解決することである。

(2) 主要なインプット及びアウトプット

進捗報告書

配布情報

(3) ツールと技法

双方向コミュニケーション

電話や会議のようにメンバ間で相互に情報が交わされる様態のコミュニケーション。

プッシュ型コミュニケーション

電子メール，FAX，手紙，メモ，報告書などのように情報の出し手が特定の相手に向かって情報を送る様態のコミュニケーション。

プル型コミュニケーション（pull communication）

プル型コミュニケーションとは，集団内のコミュニケーション手段の類型の一つで，各々が自分の必要な情報を必要なときに引き出す方式。

電子メール

プロジェクトでは，会議資料を電子メールに添付して共有することがある。しかし，プロジェクトメンバによっては多数の電子メールをさばききれず，確認漏れや古い資料を見ての回答が多数発生し，認識齟齬のままプロジェクトが進み，手戻りが生じることもある。

ボイスメール

テレビ会議

紙面

コミュニケーションチャネル

会議におけるコミュニケーション方法として，ビジネス向けチャットツールを使うことがある。令和2年度 プロジェクトマネージャ試験 午後Ⅰ 問題 問3「SaaS を利用した人材管理システム導入プロジェクト」において，ビジネス向けチャットツールの運用ルールが記載されている。

コミュニケーションスキル（積極的傾聴，フィードバック，非言語コミュニケーション，プレゼンテーションほか）

情報の伝達は，プロジェクトの会議においても行われる。したがって，情報伝達も考慮した効率のよい会議体を計画することが必要である。会議においてプロジェクトマネージャがプレゼンテーションを行う機会も多い。その会議の目的や参加者に合わせたプレゼンテーション能力が求められる。

プレゼンテーションには，機能的構成法，演繹的構成法がある。

帰納的構成法

帰納的構成法は，複数の具体的な事実から結論として一般論を展開させるストーリー構成法である。例えば，自社製品の顧客へのプレゼンテーションにおいて，最初に顧客の同業他社の製品導入による複数の成功事例を事実として挙げることで，自社製品を導入すれば大きな効果が期待できるという一般論（仮説）を展開し，当該顧客も導入すれば成功するという結論を訴求するなどの手法である。

演繹的構成法

演繹的構成法は，一般論から具体論に展開していくストーリ構成である。一般的に否定できないような前提，事実，結論の三段論法で展開させる。

応用情報技術者 午後 問題のテーマ

平成21年度 春期以降の応用情報技術者 午後 問題のテーマを示す。

• 令和5年度 秋期 問9 新たな金融サービスを提供するシステム開発プロジェクト
• 令和5年度 春期 問9 金融機関システムの移行プロジェクト
• 令和4年度 秋期 問9 プロジェクトのリスクマネジメント
• 令和4年度 春期 問9 販売システムの再構築プロジェクトにおける調達とリスク
• 令和3年度 秋期 問9 家電メーカでのアジャイル開発
• 令和3年度 春期 問9 プロジェクトのコスト見積り
• 令和2年度 問9 稼働延期に伴うプロジェクト計画の変更
• 令和元年度 秋期 問9 複数拠点での開発プロジェクト
• 平成31年度 春期 問9 システム更改プロジェクトのスケジュールの作成
• 平成30年度 秋期 問9 ERP ソフトウェアパッケージ導入プロジェクトの計画
• 平成30年度 春期 問9 ERP ソフトウェアパッケージ導入プロジェクト
• 平成29年度 秋期 問9 ERP パッケージのベンダ選定
• 平成29年度 春期 問9 システムの移行レビュー
• 平成28年度 秋期 問9 ガソリンスタンド事業における料金システムの更新
• 平成28年度 春期 問9 品質評価
• 平成27年度 秋期 問9 ソフトウェア開発プロジェクトのスコープ管理
• 平成27年度 春期 問9 プロジェクトの人的資源計画とコミュニケーション計画の策定及び実施
• 平成26年度 秋期 問9 リスクマネジメント
• 平成26年度 春期 問9 システム再構築
• 平成25年度 秋期 問9 プロジェクトの人的資源管理
• 平成25年度 春期 問10 EVM (Earned Value Management) を用いたプロジェクト管理
• 平成24年度 秋期 問10 プロジェクト計画
• 平成24年度 春期 問10 SI 案件の赤字プロジェクト対策
• 平成23年度 秋期 問10 会計パッケージの調達
• 平成23年度 春期 問10 ERP パッケージの導入検討
• 平成22年度 秋期 問10 ソフトウェアパッケージ開発プロジェクトでの品質管理
• 平成22年度 春期 問10 EVM (Earned Value Management)
• 平成21年度 秋期 問10 プロジェクトのリスクマネジメント
• 平成21年度 春期 問10 営業支援システム開発プロジェクトの管理

本稿の参考文献

• JIS Q 21500:2018「プロジェクトマネジメントの手引」 "Guidance on project management"
• 伊藤 大輔，「担当になったら知っておきたい「プロジェクトマネジメント」実践講座」，日本実業出版社，2017年2月1日
• 深沢隆司，「SE の教科書【完全版】」，技術評論社，2009年11月25日
• PMO とは？（一般社団法人 日本 PMO 協会）
• プロジェクトリーダーというお仕事

担当になったら知っておきたい「プロジェクトマネジメント」実践講座 [ 伊藤大輔 ] 価格：2420円（税込、送料無料) (2021/9/7時点) 楽天で購入