プロジェクトの基礎知識

プロジェクトの定義

プロジェクトは、有期性と独自性を持つ業務であり、日常的に繰り返し行われる業務と区別されます。

有期性

開始と完了が明確になっていることがプロジェクトの特徴です。継続的な業務はプロジェクトとはいいません。

独自性

開始と完了があることは、そのことは１回しか行われないということであり、その遂行の仕方や得られる成果物は独自のものになります。定例的に繰り返し行われる業務はプロジェクトではありません。

たとえば、情報システムの開発やダムの建設などは、それらの検討を開始する時期と、情報システムやダムが完了する時機が明確ですし、出来上がったものも他とは異なるものですし、似たような業務であっても携わる人も違うし環境も違うので独自性があります。それでこれらはプロジェクトであるといえます。
　それに対して、営業活動での顧客訪問や取引情報の入力などは、新規の顧客や新製品の取扱いなど新規性はあっても、日常的に繰返し継続して行う性格のものですから、プロジェクトとはいいません。

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

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

マネジメントは管理と訳されますが、コントロールの意味での管理よりも広い概念です。
　プロジェクト管理は、以前から行われていましたし、それを支援する多様な技法も普及していました。しかし、これまでのプロジェクト管理は、とかくＱＣＴあるいはＴＱＣを管理することに限定されていました。
　　Ｑ（Quality、品質）：期待された機能を実現する成果物
　　Ｃ（Cost、コスト）：予算。人件費なども含む
　　Ｔ（Time、納期）
　現在でも、プロジェクトマネージャの任務は、与えられた予算や人（Ｃ）と期限（Ｔ）の制約のもとで、期待される機能（Ｑ）の成果物－情報システムなど－を実現させることにあります。

最近のプロジェクトマネジメントでは、ＱＣＴを実現するためには、組織、コミュニケーション、リスク、調達などの知識（知識エリア）が重要であり、それを活用して、全体最適の観点からバランスよくマネジメントしようという考えかたへと発展してきました。
　現場実働部隊の運営では、チームメンバ全員がプロジェクトの目的・目標を共有化して、高い動機づけをもつことが重要です。また、プロジェクト期間中には、予期しないトラブルが発生します。それでリスクマネジメントが重要になります。これらもプロジェクトマネジャーの主要な任務だといえます。

プロジェクトマネジメントシステム

そして、プロジェクトマネジメントを全社的な観点から、ＰＤＣＡ（計画－実行－チェック－是正）サイクルを適切に継続的に運営することにより、プロジェクトマネジメントの成熟度を向上させることが重要だと認識されるようになりました。それをプロジェクトマネジメントシステムといいます。
　後述のＰＭＢＯＫは、プロジェクトマネジメントシステムを導入し運営するためのガイドブックだといえます。

プロジェクト管理のトライアングル

プロジェクト管理の成否は、「スコープ（対象範囲）」「コスト（費用）」「時間（納期）」の３つのバランスにかかっています。これらすべてが計画通りに進むのが理想ですが、何らかの事情で達成できないことが多くあります。
　その対処として、
　・達成する範囲を狭くする
　・費用や労力を追加投入する
　・納期を延長する
ことが必要になりますが、そのときこれらの３つの要素のバランスが崩れないように調整することが求められます。

プロジェクト体制

プロジェクトガバナンス

プロジェクト活動を経営の観点から指揮し，管理することです。プロジェクトスポンサまたはプロジェクト運営委員会が担当します。

プロジェクトスポンサ

経営の観点から該当プロジェクトを運営すること、すなわちプロジェクトガバナンスを担当する人です。プロジェクトの影響度により、経営者、部門担当役員、対象業務部長などが担当し、プロジェクトの最高責任者です。
　主な任務は次の通りです。

• プロジェクトの発案あるいは承認
• プロジェクト憲章の作成あるいは承認
• プロジェクト憲章による経営資源の提供
• 高度なレベルでのステークホルダとの調整
• プロジェクト進捗報告のガバナンスの観点による承認と指示
• プロジェクト終結の承認
• プロジェクトの成果を実現するための関係部門への指示

プロジェクト運営委員会

プロジェクトが複数の組織に影響を与える場合、それらの組織の代表者をメンバとし、プロジェクトスポンサを委員長とする委員会を設置することがあります。全体の戦略的方向性に関する指針を提示し、それを組織の大部分に広めるのを支援する任務をもちます。

プロジェクトチームとプロジェクトマネジャー

特定のプロジェクトを実行するには、関係部門から適任者を選抜してチームを編成します（専任者だけでなく兼任者もいます）。そのチームをプロジェクトチームといい、そのリーダーをプロジェクトマネジャーといいます。プロジェクトチームはプロジェクトが完了した時点で解散する臨時的な組織です。

プロジェクトマネジャーは、プロジェクトの要求事項を満たすために、知識、スキル、ツールと技法をプロジェクトへ適用する任務をもち、チームメンバを指揮します。
　情報システム開発プロジェクトを例にすれば、ユーザ企業側でのプロジェクトチームとベンダ企業側でのプロジェクトチームが存在します。通常は請負契約ですので、それらは別個のチームになり、互いのプロジェクトリーダを介して協力体制をとります。
　ユーザ企業ならば、所期の目的を実現するには、業務改革や顧客折衝など情報システム以外の活動がであり、それを含んだ全体の責任は当該部門の部長クラス（システムオーナーという）が行い、プロジェクトマネジャーは、当該部門の部長あるいは情報システム部長から任命された者になります。
　ベンダ企業では、一般にプロジェクトマネジャーという職種があり、対象システムやユーザ企業の業種への知識スキルをもつ者が任命されます。

ＰＭＯ（Project Management Office、プロジェクト管理部門）

ＰＭＯは、プロジェクト組織ではなく継続性を持つ部門です。「管轄する複数のプロジェクトを一元的にマネジメントし、調整を行うことに種々の責任を有する組織の一部門あるいはそのグループ」であり、プロジェクトの関連するガバナンス・プロセスを標準化し、資源、方法論、ツール及び技法の共有を促進するのが任務で、プロジェクトマネジメントへの支援から、プロジェクトを直接マネジメントするまで広範囲にわたります。
　・方法論やベストプラクティス、標準の特定と開発
　・プロジェクトの監査
　・文書の作成とマネジメント
　・プロジェクト間のコミュニケーションと調整

プロジェクトマネジャーとＰＭＯの違い

• プロジェクトマネジャーは特定のプロジェクトの目標に焦点を当て、ＰＭＯはビジネス目標を達成する潜在的な好機として、重要なプログラムのスコープの変更をマネジメントする。
• プロジェクトマネジャーはプロジェクト目標を達成するために、割り当てられた資源をコントロールし、ＰＭＯはすべてのプロジェクトに対して、共有資源の最適化を行う。
• プロジェクトマネジャーは個々のプロジェクトの制約条件をマネジメントし、ＰＭＯはプロジェクト間の相互依存関係等をマネジメントする。

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

大規模、複雑なプロジェクトでは、プロジェクト内部にＰＭＯのような組織を設置することもあります。それをプロジェクトマネジメントチームといいます。プロジェクトマネージャの任務は複雑で、１人のマネージャでは達成が困難な場合があります。
　新規技術の調査、特定のステークホルダとの折衝、文書の整備など、プロジェクトマネージャの周辺業務を支援して当該プロジェクトを成功させることが任務です。

プロジェクトマネジメントの体系

ＰＭＢＯＫガイド

ＰＭＢＯＫ（A Guide to the Project Management Body of Knowledge）は、ＰＭＩ（Project Management Institute）が、１９９６年に策定したもので、プロジェクトマネジメントに関して、一般的に優れた業務慣行として認められている知識を体系化したものです。その後逐次改訂されており、事実上の標準として世界中で広く受け入れられています。
　日本では、ＰＭＩ東京支部がＰＭＢＯＫの普及やＰＭＰ（プロジェクトマネジャー）資格認定などを行っています。

２０１７年のＰＭＢＯＫガイド（第６版）では、アジャイル開発（ＰＭＢＯＫガイドでは「適応型の開発ライフサイクル」と分類）への対応が重視されました。１０の知識エリアごとにアジャイル開発を適用する場合の進め方や考慮点を盛り込み、付録として「アジャイル実務ガイド」がセットされました。

JIS Q 21500

正式名称は「JIS Q 21500:2018 プロジェクトマネジメントの手引」、原規格は「ISO 21500:2012 Guidance on project management」です。すなわちガイドブックであり、ＰＭＢＯＫ「ガイド」と同じ意味合いです。ＰＭＢＯＫを規格にしたものですが、「知識」を目的としていないので、実践を支援する方法論やツールに関する記述はありません。

知識エリア（対象群）、プロセス群、プロセス

ＰＭＢＯＫの体系は、プロジェクトマネジメントを適切に行うための知識を体系化した知識エリアと、プロジェクトの開始から完了までの各段階をＰＤＣＡに基づいたプロセス群の組合せになっています。その組合せにプロセスがあり、何を行うべきか、その方法を示しています。
　JIS Q 21500 では「知識エリア」を「対象群」としています。
参照：プロセス一覧表

知識エリア

ＰＭＢＯＫガイドでは「プロジェクトマネジメント」に必要な知識の「体系」を示したものです。必要となる知識を網羅して体系化することが目的であり、知識そのもの（技法など）の解説を目的としていません。「ツールと技法」では、話題になっているＥＶＭ（アーンドバリューマネジメント）などについては、やや詳細な解説がありますが、全般的には、単に名称を列挙するか数行の定義を記述しているだけです。
　また、知識というと、ＥＶＭやＰＥＲＴなどの技法の知識だと思われがちですが、それは、プロジェクトマネジメントを成功させるための一部分にすぎません。もっと広い観点で「知識」をとらえることが必要です。

知識エリアとして、次の１０エリアをあげています。このうち、スケジュールマネジメント、コストマネジメント、品質マネジメントの３分野がプロジェクトの結果に直接関係する分野で、古典的なＱＣＴの分野です。
　資源マネジメント 、コミュニケーションマネジメント、リスクマネジメント、調達マネジメント、ステークホルダーマネジメントは、そのＱＣＴを実現するために、プロジェクトを円滑に運営するための分野です。そして、統合マネジメントとスコープマネジメントは、それらの分野を統合したものだといえます。

統合マネジメント（一覧表へ）

プロジェクトにおける多種多様な要素を整合性のある実行をするためのもので、以降の各エリアを統合する位置づけになっています。プロジェクト憲章作成のために、ビジネスケース、バネフィットマネジメント計画書を作成します。

スコープマネジメント（一覧表へ）

スコープとは「範囲」のことです。スコープマネジメントとは「プロジェクトの目標である最終成果物を作成するために必要な作業が過不足なく確実に遂行されることを保証する」ために、ＷＢＳを設定（スコープ定義）して、ＰＤＣＡサイクルにより常に最新の状態に保つことが必要ですし、関連法規や顧客要求事項の変更があるとスコープの変更が必要になります（変更管理）。

スケジュールマネジメント（旧タイムマネジメント）（一覧表へ）

納期までにプロジェクトを完成させるための管理です。作業の定義、順序、所要時間見積り、スケジュールの作成と進捗管理をするための分野です。個々のタスクの成果物が予定された期日（マイルストーン）までに達成したことを確認し、遅れが発生したときには対処しなければなりません。
第６版から「スケジュールマネジメント」に改称しました。「タイム」よりもプロジェクトとの結びつきが強い概念である「スケジュール」としたのです。
スケジュールが遅延した場合の開発スコープを保ったまま、スケジュールを短縮するための技法として、次の二つが示されています。

• クラッシング（Crashing）
  クリティカルパス上にあるタスクに対して人員や費用を追加投入することにより、スケジュールを短縮させる方法です。
• ファスト・トラッキング（Fast Tracking）
  先行タスクが完了する前に後続タスクを進めることで、スケジュールを短縮させる方法です。製造業における コンカレントエンジニアリングに似た概念です。

コストマネジメント（一覧表へ）

計画された予算内でプロジェクトを完成させるための管理です。資源計画、コスト積算、予算作成、コスト管理があります。
当初予算の決定には、システム化計画による総開発予算と，各作業を積み上げた見積りを総合的に調整する必要があります。類似プロジェクトの実績も参考にします。
そのとき開発に関係する利用部門の人件費やシステム開発以外の業務改革などにかかる「見えない費用」も算入する必要があります。そして、実績の差異を監視し，必要に応じて計画変更を行う必要があります。特に進捗の遅れはコストの増大を招きます。

品質マネジメント（一覧表へ）

成果物が期待された機能・性能を過不足なく持つことを実現させるための管理です。
「品質」は「コスト」や「納期」と比較して不明確なことが多く、品質を維持するために必要な管理手段やテストの期間・費用などへの制約が厳しくなりがちですが、手抜きをすると、本番移行後に大きなトラブルが発生するリスクがあります。逆に、品質にこだわりすぎて、過剰なコストや時間をかけるのも不適切です。それには、関係者によるレビューの実施が必要です。
情報システム開発で問題なのは、当初の要件が必ずしも明確でなく変更が多いことです。これは納期やコストに大きな影響を与えます。

納期、コスト、品質は以前からプロジェクトで重視されていた事項ですが、モダンプロジェクトマネジメントでは、それらを保証するために以降の事項が重要だとしています。

資源マネジメント（旧人的資源マネジメント）（一覧表へ）

従来は人的資源マネジメントとして、プロジェクトはチーム（組織）で遂行します。その体制を作り、役割分担、責任と権限、要員の確保・育成などを行うためのをする分野でしたが、第６版から、国際標準のISO 21500に準拠し、「人」だけでなく「物資」などもマネジメントの対象に広げました。

コミュニケーションマネジメント（一覧表へ）

チームがバラバラな行動をしたのでは困ります。また、ステークホルダーにタイムリーに報告する必要があります。どのような情報をいつどのように伝達するかの計画を作り、情報を生成、収集、配布、保管、廃棄するプロセスををする分野です。

リスクマネジメント（一覧表へ）

開発要員が病気になったとか、思わぬ障害が発生したなど、プロジェクトではリスク対策が必要です。リスクの特定、定量化、対応策の策定などのリスク管理をする分野です（詳細後述）。

調達マネジメント（一覧表へ）

ハードウェアやソフトウェア、情報システムの外部委託など、多くの調達があります。調達計画、契約、調達などの管理をする分野です。

ステークホルダーマネジメント（一覧表へ）

ステークホルダーとは利害関係者です。社内利用者、顧客、株主、社会、行政官庁など広い分野にわたります。ステークホルダーと良好な関係を築くことが、プロジェクトを成功させる重要な要因です。場合によってはプロジェクトに反対のステークホルダーもいますが、それを協力者に変えることが必要です。コミュニケーションマネジメントから発展した分野です。第５版（２０１２年）から追加されました。

リスクマネジメント

JIS Q 21500でもリスク分析の規定がありますが、ＰＭＢＯＫではより具体的な手順が示されています。

リスクの定義

• リスクとは当初計画がずれてしまう要因のこと
  ・純粋リスク　　マイナスの要因
  ・投機的リスク　プラスの要因
• プロジェクトにおけるリスク
  ・個別のリスク
  ・全体のリスク(プロジェクト憲章に含まれる)
  
• 対応によるリスクの区分
  ・プロジェクトチームで対応ができるリスク→スケジュール遅延やコスト超過など
  ・プロジェクトチームでは対応が難しいリスク→為替の変動や、競合の動き、経済情勢など
• リスクの特定
  ・プロジェクト開始前：リスクの特定プロセス
  ・開始後のリスク：リスクの監視プロセス

リスクマネジメントの手順

• リスクマネジメントの計画
  リスクマネジメント活動を行う方法を定義するプロセスです。プロジェクト文書(リスク登録簿)、プロジェクトマネジメント計画書をインプットとして、データの収集や分析を行い、それらの文書を更新します。
  リスク登録簿：リスクの優先順位されたリスクの一覧表。各工程でリファインされていきます。
• リスクの特定
  リスクマネジメント計画書に基づいて、想定できる個別リスクの要因を特定し、特性をリスク登録簿に追加するプロセスです。
• リスクの定性的分析
  特定した個別リスクについて、主に個別リスクの発生確率とプロジェクトに与える影響度により、高・中・低の等級をつけるプロセスです。リスクマネジメント計画書で定義されている発生確率影響度マトリクスを使って、リスクのデータ表現、データの評価を行ないます。
• リスクの定量的分析
  リスクの定性的分析を行った後で、各個別リスクが、プロジェクト目標全体における他の不確実性要因が複合した影響を数量的に分析するプロセスです。これにより個別リスクの優先順位が与えられます。
• リスク対応の計画
  プロジェクト全体のリスクと個別リスクに対処する方法－回避・転嫁・軽減・受容－を決定するプロセスです。

プロセス

プロセスのタイプ

プロジェクトを動かしていくためのプロセスには以下の３つがあり、それぞれが相互に関与しています。

• プロジェクトマネジメントプロセス
  プロジェクトの立ち上げから完了に至るまでの工程を管理する
• 出荷プロセス
  プロジェクトからでる成果物を管理する
• 支援プロセス
  プロジェクトで発生する作業を支援する

プロセス群

それぞれの知識エリアで必要となる「結果をもたらす連続したアクション」をプロセスといいます。
　各プロセスを、プロジェクトの立ち上げから終結にいたる時間軸でグループ化したものをプロセス群といいます。プロジェクトの進行にあわせて、必要となるプロセスを示すことにより、どの局面で、プロセスを実施すればよいかがわかります。

各プロセスでは、そのプロセスを行うために、どのような情報を用いて（インプット）、どのような結果を得るのか（アウトプット）、インプットからアウトプットを得るのに役に立つツールや技法にはどのようなものがあるか（ツールと技法）を示しています。

プロセスは、次の５つのプロセス群にまとめられます。立ち上げのプロセスと終結のプロセスは、プロジェクトが有期性であることから重要です。計画・遂行・コントロールのプロセスは、ＰＤＣＡサイクルになっています。

立ち上げプロセス群

プロジェクト立上げ時にプロジェクト憲章を定めます。プロジェクトに関する基本方針を記述した正式文書であり、これによりプロジェクトが正式に発足します。
・プロジェクトの目的を明確にし，正式に認可する。
・プロジェクトマネジャーの任命（体制はプロジェクトマネジャーの権限）
・プロジェクトマネジャーに組織の資源を使用する権限を与える。
などが示されています。

計画のプロセス群

プロジェクトを行うための計画を立案して、それを維持します。

実行のプロセス群

実際にプロジェクトの業務を行い成果物を作成します。

監視コントロールプロセス群

プロジェクトの目標を達成するのを保証するために、プロジェクトの進捗をモニタリングして、必要に応じて対策を講じます。

終結プロセス群

プロジェクトまたはタスクの成果物の確認や報告などの完了手続きを行います。

プロセスの例：統合マネジメント

ＰＭＢＯＫでは、各知識エリアのマネジメントを遂行するのに、これらのプロセス群で何を行うか、成果物は何かの観点から（下位の）プロセスを示しています。

統合マネジメントを例に知識エリアとプロセス群の関係を示します。

ＰＭＢＯＫでは、各プロセスの実施に関する「ツールと技法」を列挙し、その簡単な説明と適用での留意事項を示しています。これがＰＭＢＯＫの大半を占めていますが、中途半端になるので、ここでは割愛しました。

• 統合マネジメントの立上げプロセス群
  
  • 4.3.2 プロジェクト憲章の作成
    プロジェクトの基本事項をまとめたプロジェクト企画書で、これを各関連部署に諮り、修正を加えて、承認を受けるものです。承認された後は、プロジェクト全体の基本方針になります。
    成果物（主なアウトプット）：プロジェクト憲章
• 統合マネジメントの計画プロセス群
  
  • 4.3.3 プロジェクト全体計画の作成
    スコープマネジメント、スケジュールマネジメント、コストマネジメントなど他の知識エリアの計画プロセスで作成される補助計画書を定義します。
    補助計画書やベースラインは、ステークホルダーの承認を経て、最終的なアウトプットしてプロジェクトマネジメント計画書に統合されます。計画に基づいて実行した結果は随時プロジェクトマネジメント計画書に反映します。
    成果物：プロジェクト計画、プロジェクトマネジメント計画
• 統合マネジメントの実行プロセス群
  
  • 4.3.4 プロジェクト作業の指揮
    成果物：進捗データ、懸案事項ログ、得た教訓
• 統合マネジメントの監視・コントロールプロセス群
  
  • 4.3.5 プロジェクト作業の管理
    ここでは、実行された作業のスケジュールやコストの把握、計画との差異分析、完成時の予測など作業パフォーマンスが重要になります。
    成果物：変更要求、進捗報告書、プロジェクト完了報告書
  • 4.3.6 変更の管理（統合変更管理）
    変更には、
    　・是正処置：機能・性能などの改善処置
    　・予防処置：リスク発生確率を低減させる処置
    　・欠陥修正：計画の欠陥、実行での瑕疵などの修正
    がありますが、それらをすべて統合変更管理で管理します。
    ・変更管理
    知識エリアから提出された変更要求は変更管理委員会の承認を経て、プロジェクト作業の指揮・マネジメントプロセスに送られて実行されます。その成果物は変更管理委員会のレビューと承認を得て正式なものとなります。変更要求やその後の変更結果は変更ログに記録されます。
    ・構成管理
    成果物と仕様を突き合わせ、正しい構成を保つように管理します。
    成果物：承認された変更、変更登録簿
• 統合マネジメントの終結プロセス群
  
  • 4.3.7 プロジェクトフェーズ又はプロジェクトの終結
    スコープマネジメント計画書で定めたスコープ妥当性確認で承認された成果物の納品作業を行い確認を得ます。すべての成果物について作業が完了したら。プロジェクト完了報告書を作成します。これにはプロジェクト憲章で作成した成功基準との比較ができるデータが含まれている必要があります。
    何らかの事情でプロジェクトが中止した場合であっても、中止した理由、決定のプロセス、中止のための処置をなどを報告書として提出します。
    成果物：完了した調達、プロジェクト又はフェーズの終結報告書、解放された資源
  • 4.3.8 得た教訓の収集
    これまでのプロセスを総括して、今後のプロジェクトマネジメント運営に役立つ事項を文書化します。
    成果物：得た教訓文書

重要用語

プロジェクト憲章（プロジェクトチャーター）

プロジェクト立上げプロセスにおいて、経営者が（あるいは先立って指名されたプロジェクトマネージャが原案を作成し、経営者の承認を得て）プロジェクト憲章を策定し、関係者に周知するものです。ステークホルダ（利害関係者）に対してプロジェクトの存在を正式に認可してもらうことを目的としたものでもあります。

プロジェクトに関する基本事項を文書化したもので、次のような項目からなっています。
　　・プロジェクトの目的または妥当性
　　・プロジェクトの目標及び成功基準
　　・要求事項概要
　　・プロジェクト記述概要（プロジェクトの方針）
　　・リスクの概略
　　・要約マイルストーン、スケジュール
　　・要約予算（概要見積り）
　　・プロジェクト承認要件（実施承認の判断基準や担当者）
　　・プロジェクトマネージャ（責任と権限）
　　・プロジェクト・スポンサー（プロジェクトの最終責任者）

プロジェクトの立上げプロセスにおいて作成され、承認されたらプロジェクトが発足し、プロジェクトマネジャーが任命されます。

プロジェクト全体に関して、プロジェクト憲章をより具体的に記述したのがプロジェクト・スコープ記述書暫定版です。プロジェクト憲章が法律だとすれば、これは政令や通達に相当します。
　プロジェクト立ち上げプロセス群の段階では，まだ正式版が作れるほど検討が進んでいないので、「暫定版」を作成して、プロジェクト憲章とセットにして、プロジェクトを立ち上げます。そして、計画プロセス群の活動中に「正式版」に確定します。

リスクの分類

リスク対処の分類では、「回避」や「損失制御」などのリスク・コントロール、「保険」「受容」などのリスク・ファイナンスに区分するのが通常です（→参照：「リスク・コントロールとリスク・ファイナンス」）が、ＰＭＢＯＫでは、マイナス（脅威）のリスクだけでなくプラス（好機）のリスクも加えて次のように分類し、それぞれの対応戦略を示しています。

　　　　　┌────┬────┐
　　　　　│　脅威　│　好機　│
　　　　　┝━━━━┿━━━━┥
　　　　　│　回避　│　活用　│
　　　　　├────┼────┤
　　　　　│　転嫁　│　共有　│
　　　　　├────┼────┤
　　　　　│　軽減　│　強化　│
　　　　　├────┼────┤
　　　　　│　受容　│　受容　│脅威／好機の両方にある
　　　　　└────┴────┘

脅威への戦略

• 回避：脅威を完全に取り除くために、プロジェクトマネジメント計画を変更すること。プロジェクトの中止、納期延長、範囲の縮小などです。
• 転嫁：脅威による影響を、対応責任も合わせて、第三者に移転すること。保険や保証契約などです。
• 軽減：リスクの大きさ（発生確率×影響度）を受容範囲にまで低減させること。能力の高い発注先の選定、テストの重視などです。
• 受容：リスクを受け入れることを容認すること。災難だと割り切ること、ＱＣＴにリスク対応の余裕をもたせることなどです。

好機への戦略

• 活用：好機が確実に到来するようにすること。能力の高いチーム人選などによる期待以上の品質。コスト低下、納期短縮などです。
• 共有：好機をとらえることのできる組織に、好機を実行する権限を割り当てること。ジョイントベンチャや社内ベンチャ（プロジェクトが成功したら、その経営を任せる）などです。
• 強化：好機の発生確率やプラスの影響を増加させること。チャンス時での資源の追加投入、シナジー効果を狙った範囲拡大などです。
• 受容：積極的な利益追求はしないが、好機実現時には逸することなく利益享受をすること。ハードウェアの価格低下、新技術の出現に即応することなどです。

非事象リスク

ＰＭＢＯＫガイド第６版では、リスクの分類として、次の体系も示しています。

リスク
　├─事象リスク（事象に基づくリスク）
　│　　　　　　設計完了後の顧客からの仕様変更要求や開発関係企業の倒産など
　└─非事象リスク（具体的な事象以外でのリスク）
　　　　├─変動リスク（計画時の各種パラメタ予測値からの乖離）
　　　　│　　　生産性が予想外に低い、テストでのエラー件数が予想外に多いなど
　　　　└─曖昧さリスク（計画時に十分に把握できなかったリスク）
　　　　　　　　要求事項の不完全理解、法的規制、新技術の不確実性、プロジェクトの複雑性など

プロジェクトの細分化

ＷＢＳ（Work Breakdown Structure）

プロジェクトは多数の作業から成り立っています。プロジェクトチームが実行すべき作業を、上位の階層から下位の階層へ段階的に分解し、コスト見積りとスケジュール作成を行えるレベルまでに細分化します。そして、その作業での必要な情報と成果物、それに必要な技術や作業量などを明確にします。
　このようにして、複雑な作業を単純な作業にブレークダウンした体系図、あるいは、それにより管理する方法をＷＢＳといいます。適切なＷＢＳを行うことがプロジェクト運営の基礎になります。

ワークパッケージ

ＷＢＳは、上位ー下位へと階層的に表示されますが、その最下位レベルの要素のことです。ワークパッケージが進捗コントロールの最小基本単位になります。プロジェクトの規模と目的により粒度はさまざまです。
　ワークパッケージは、必要に応じていくつかのアクティビティ（具体的な作業）に分解され、責任担当者や実施組織などのリソースが割り当てられます。

ＷＢＳ辞書

個々のＷＢＳ要素に関する作業の内容と意味を明確に定義したものです。
　　・ＷＢＳの位置：上位ＷＢＳ要素、先行・後続ＷＢＳ要素
　　・関係者：作業担当者、実施責任者、管理責任者、承認者
　　・作業：開始・完了予定、実施に必要な成果物・リソース、完了条件、成果物（仕様）
　　・予想リスク、コスト等
などの内容を常に最新状態に保持したものです。多くのプロセスにおいて参照、更新されます。

ＯＢＳ（Organization Breakdown Structure）

ＷＢＳがプロジェクトの作業と成果物により階層化したのに対して、ＯＢＳはプロジェクト組織を階層的に図式化したものです。ワークパッケージに組織／人員を割り振り、責任や指揮の系統に従って配置するとＯＢＳになります。
　ワークパッケージとＯＢＳをマトリクスの表にすることにより、作業と責任者の対応が明確になります。

その他の関連基準

プログラムマネジメント

プロジェクトと似た用語にプログラムがあります。プログラムとは複数のプロジェクトが互いに関連して並行して行われる場合、その全体を指す概念です。
　プログラムマネジメントとは、「プログラムの戦略目標と成果価値を達成するために、調和を保ちつつ一元的にプログラムをマネジメントすること」と定義されています。戦略目標に整合させるよう、関連する複数プロジェクトに影響する制約条件およびコンフリクトを解消することだといえます。

プログラムは目的達成を対象にし、プロジェクトはそのための目標（手段）の実現を対象にします。
　目的とは、実現したいことです。システム開発でいえば、新サービスを提供する、生産性を向上させるなどのことです。
　その目的を達成するには、多様な目標があります。システム開発だけでなく、組織体制や業務の変更、顧客や関係先との調整が必要ですし、直接関係する基幹系システムだけでなく、その効果を高めるための付帯的なシステムも必要でしょう。

（これに対して、ある部門が独立したプロジェクトを複数抱えていることを、マルチプロジェクトといいます）。

Ｐ２Ｍ（プログラム＆プロジェクトマネジメント）

　経済産業省の指導のもと、エンジニアリング振興協会は、日本版プロジェクトマネジメントとして、Ｐ２Ｍ（Project & Program Management）の知識体系、「プログラム＆プロジェクト標準ガイドブック」を策定しました。ＰＭＢＯＫをベースにしていますが、全体使命としてのプログラムを意識していること、拡張性を重視していることなどの特徴があります。これにも資格制度があり、プロジェクトマネジメント資格認定センターが担当しています。

プロジェクトポートフォリオ

ポートフォリオとは、「戦略的なビジネス目標を達成するための仕事を効果的にマネジメントすることを目的にグループとしてまとめられた、プロジェクト、プログラム、および関連業務の集合である」と定義されています。
　ポートフォリオマネジメントとは「1つ以上のポートフォリオを一元化してマネジメントすること」です。戦略目標を達成するために、プログラム及びプロジェクトの最適な組み合わせを選択して、構成要素の優先順位を決定し、必要な資源を提供することです。

JIS Q 10006（ISO 10006）（プロジェクトにおける品質マネジメントの指針）

プロジェクトマネジメントそのものの手引書ではなく、プロジェクトマネジメントのプロセスにおける品質に関する規格でしたが、２０１９年にJIS Q 21500 の策定により廃止になりました。

JIS Q 21500:2018、ＰＭＢＯＫ（第６版）プロセス一覧

• 対象群（知識エリア）
  「時間」PMBOKでは「監視コントロール」としています。
• プロセス群
  「管理」をPMBOKでは「監視コントロール」としています。
• プロセス
  「x.y.z」は JIS Q 21500:2018 での章立てです。PMBOK では表現はやや異なりますがほぼ同一の内容です。
• ←主なインプット
• →主なアウトプット
  JIS Q 21500:2018 での記述です。PMBOK ではやや異なりますがほぼ同一の内容です。
• ツールと技法
  JIS Q 21500 には、これに関する記述はありません。PMBOK では個々のプロセスに対応して列挙していますが、ここでは。代表的なものを知識エリアで一括しました。