プロジェクト手法の用語をゆるく説明｜PMP試験用語1

アジャイル型のアプローチは、欧米のソフトウェア開発現場で採用され、近年は日本でも流行りつつある方法です。成果を小出しにし、顧客が求める成果物に徐々に近づける方法です。

予測型のアプローチというのは、国内の製造業でも従来から採用されてきた方法です。しっかり計画して、予算の稟議をとおした後に、設計検証を経て一発で製品リリースする方法です。

このように、プロジェクトマネジメントの土台とも言えるプロジェクト手法の用語を、ざっくばらんに説明します。

• アジャイル入門
• プロジェクトライフサイクルの選択
• 予測型、従来型のプロセスマップ
• PMO
• ニーズ分析
• ベネフィット実現計画
• 10の知識エリア

実際の試験用語として厳密に参照されたい場合は、PMPOKや参考書をご確認ください。

アジャイル入門

アジャイル宣言とマインドセット

ソフトウェア業界の思想家リーダーたちは、2001年に「アジャイルソフトウェア開発宣言」を公表することでアジャイル運動を正式なものとしました。

私たちは、ソフトウェア開発の実践あるいは実践の手助けをする活動を通じて、よりよい開発方法を見つけだそうとしている。この活動を通して、私たちは以下の価値に至った。

プロセスやツールよりも個人と対話を、

包括的なドキュメントよりも動くソフトウェアを、

契約交渉よりも顧客との協調を、

計画に従うことよりも変化への対応を、

価値とする。すなわち、左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく。

「アジャイル宣言４つの価値」アジャイル実務ガイドから引用

これらの価値に由来する12の明確な原則。

1. 顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。
2. 要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます。
3. 動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。
4. ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。
5. 意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します。
6. 情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。
7. 動くソフトウェアこそが進歩の最も重要な尺度です。
8. アジャイル・プロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるようにしなければなりません。
9. 技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。
10. シンプルさ（ムダなく作れる量を最大限にすること）が本質です。
11. 最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。
12. チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。

「アジャイル宣言の背後にある12の原則」アジャイル実務ガイドから引用

アジャイルアプローチと他アプローチの範囲

以下の図は、アジャイルの位置づけを示しています。アジャイルが、あらゆる種類のアプローチ・技法・フレームワーク・手法・実務慣行を総称する用語であることを示します。例えばアジャイルとカンバンは、リーンの一部であることを示しています。アジャイルとカンバンは、「価値に焦点」、「小さいバッチ・サイズ」、「ムダの排除」などのリーンが持つ概念を備えています。

一般に、アジャイルの価値と原則を満たすふたつの戦略があります。期待する結果を出すために意図的に設計され、実績が証明されている正式なアジャイル・アプローチを採用します。ふたつの戦略を一言で説明すると、1つ目は計画的なアプローチ方法、2つ目は柔軟なアプローチ方法です。1つずつ詳細に説明します。

1. 期待する結果を出すために計画的,意図的に設計されたアプローチ
2. プロジェクトの状況に適した方法で実務慣行を変更するアプローチ

第一の戦略は、期待する結果を出すために意図的に設計され、実績が証明されている正式なアジャイル・アプローチを採用することです。それを変更したりテーラリングする前に、アジャイル・アプローチを学習し理解するために時間をかけます。時期尚早で行き当たりばったりにテーラリングすると、このアプローチの効果は最小限になり、ベネフィットも制限されます。

第二の戦略は、プロジェクトの状況に適した方法で実務慣行を変更するアプローチです。コア・バリューや原則の進展を実現するために、プロジェクトの状況に適した方法でプロジェクトの状況に適した方法プロジェクトの実務慣行を変更します。タイムボックスを使用してフィーチャーを作成するか、または特定の技法を使って反復的にフィーチャーを洗練します。ひとつの大きなプロジェクトをいくつかのリリースに分割することを検討し、プロジェクトの成功に役立つ変更を実施します。変更は、組織の正式な実務慣行の一部である必要はありません。最終ゴールはアジャイルを行うこと自体ではなく、継続的に価値を顧客に提供し、よりよいビジネス成果を達成することです。

ステーシーマトリクス

ステーシーマトリクスは、ラルフ・ステーシー氏が発表したモデルであり、プロジェクトの不確実性に対する特性を示しています。不確実性が高い、というのは変更が高確率で発生したり、プロジェクトが複雑化しやすいことを示します。以下のマトリクスでは、縦軸に要求事項の不確実性を、横軸に技術の不確実性を表しています。このマトリクスは、開発アプローチを決定するときのガイドとなります。技術の不確実性が高いというのは、ITやAIなど先進の技術が刻一刻とめざましく更新されるようなことを指します。マトリクスに注目すると、単純な領域は予測型（従来型、ウォーターフォール）が向いており、煩雑な領域は適応型（アジャイル）が向いています。混沌の領域では、プロジェクトを行うべきではありません。

プロジェクトライフサイクルの選択

プロジェクトには多くの形態があり、さまざまなアプローチ・ライフサイクルの中から選択して推進します。プロジェクトチームは、成功率の高いアプローチを選択するために、アプローチごとの特徴を理解する必要があります。

プロジェクトライフサイクルの特性

PMIが発行するアジャイル実務ガイドでは、次のように定義される4つのライフサイクルを紹介しています。

1. 予測型ライフサイクル
   • 従来型のアプローチ。計画駆動型ともいう。ほとんどのことを事前に計画し、一回のパスで実行する。
2. 反復型アプローチ
   • 未完成の作業を改善し修正するために、作業のフィードバックができるようにするアプローチ。
3. 漸進型(ぜんしんがた)ライフサイクル
   • 顧客が直ちに使用できる完成した成果物を提供するアプローチ
4. アジャイル型ライフサイクル
   • 作業項目を洗練し頻繁にデリバリーする反復型かつ漸進型のアプローチ

アプローチ	要求事項	アクティビティ	デリバリー	目標
予測型	固定	プロジェクト全体で1回実行	1回のデリバリー	コストのマネジメント
反復型	動的	適切になるまで反復	1回のデリバリー	ソリューションの適切さ
漸進型	動的	増分毎に1回実行	頻繁で小さなデリバリー	スピード
アジャイル型	動的	適切になるまで反復	頻繁で小さなデリバリー	頻繁なデリバリーとフィードバックを適用した顧客価値

アプローチ	要求事項	アクティビティ	デリバリー	目標
予測型	固定	プロジェクト全体で1回実行	1回のデリバリー	コストのマネジメント
反復型	動的	適切になるまで反復	1回のデリバリー	ソリューションの適切さ
漸進型	動的	増分毎に1回実行	頻繁で小さなデリバリー	スピード
アジャイル型	動的	適切になるまで反復	頻繁で小さなデリバリー	頻繁なデリバリーとフィードバックを適用した顧客価値

予測型のアプローチというのは、国内の製造業でも従来から採用されてきた方法です。しっかり計画して、予算の稟議をとおした後に、設計検証を経て一発で製品リリースする方法です。予算と期日を決めてから行うため、予算と期日を守りやすい反面、やりたいこと（要求事項）に沿えない可能性が高いといえます。なぜなら、計画段階ですべての要求事項を捉えることは難しく、試作やテストを行ったあとに潜在的なニーズに気が付くことも少なくありません。ニーズや技術の入れ替わりが激しいソフトウェアの業界では、予測型アプローチに限界が生じ、新しいアプローチが研究されました。それがアジャイル型のアプローチです。なお、予測型のソフトウェア開発で、軽い気持ちで度重なる変更を生じさせ、それがソフトウェア開発者の労働環境を悪くしたことから「デスマーチ」という言葉があります。

アジャイル型のアプローチは、欧米のソフトウェア開発現場で採用され、近年は日本でも流行りつつある方法です。成果を小出しにし、顧客が求める成果物に徐々に近づける方法です。開発側が抱く完成イメージと、顧客が抱く完成イメージとのギャップは生じるものだと考えており、顧客の意見を取り入れながら成果物を小出しします。アジャイル型のアプローチは、スクラムと呼ばれるチームを結成し、イテレーションと呼ばれる2週間程度の活動を繰り返し行います。各イテレーションの終了時にレトロスペクティブと呼ばれる振り返りを行い、課題解決をチームで共有した上で次回のイテレーションに臨みます。成果物は、ユーザーストーリーと呼ばれる顧客の要望リストのようなものが元となり、これをプロダクトオーナーが優先順位付けし、プロダクトバックログとしてストックします。チームは、プロダクトバックログを取り出し、成果物に変えて顧客からレビューをもらいます。顧客の要望事項が変わった場合は、適切にマネジメントしながら変更要求に応えます。具体的にはユーザーストーリーとプロダクトバックログを変更する形で変更に応えます。アジャイル型は変更要求に柔軟に対応し、適切な成果物が得られるまで継続させるアプローチ手法です。

これらの予測型とアジャイル型の間に、反復型と漸進型があります。反復型は予測型に近く、漸進型はアジャイル型に近いです。反復型は、成果物を1回だけ提供します。ソリューションの適切さを重視しており、一度で確実に要求に応えることを重視します。アクティビティ、つまり試作やテストを繰り返し行い、成果物は一発です。建設や機械構造物など、何回も成果物を作れないが失敗は許されない場合にマッチします。その一方、漸進型は、頻繁で小さな成果物の提供を続けます。スピードを重視しており、一度のアクティビティ（試作やテスト）で、サッと納品します。アプリのアップデートなど、ある程度失敗が許されるが早く市場投入したい場面にマッチします。

予測型、従来型のプロセスマップ

「プロセスマップ」ってなに？

まず、「プロセスマップ」と聞いて固まる必要はありません。

プロセスマップとは、プロジェクトを「どんな順番」で「どうやって」進むかの全体図！

特に予測型（従来型）は、
「カッチリ計画→順番に実行→最後に納品」まじめ系優等生プロジェクト。

「予測型（従来型）」とは？

同じく「ウォーターフォール型」のことです。

まるで「高級フレンチのコース料理」のように、順番通りに一品ずつ進んでいきます。

コース料理で例える予測型プロジェクト

プロジェクト工程	フレンチコースで例える
立ち上げ（立ち上げ）	メニューを決める（コースの内容を決める）
計画（プランニング）	材料を仕入れて、順番とレシピを設計
実行（実行する）	実際に調理スタート！盛り付けも含む
監視・制御（Monitoring & Controlling）	味見して「うん、塩加減OK！」とチェック
終結	デザートで締めて、シェフが「ごちそうさま！」

プロジェクト工程	フレンチコースで例える
立ち上げ（立ち上げ）	メニューを決める（コースの内容を決める）
計画（プランニング）	材料を仕入れて、順番とレシピを設計
実行（実行する）	実際に調理スタート！盛り付けも含む
監視・制御（Monitoring & Controlling）	味見して「うん、塩加減OK！」とチェック
終結	デザートで締めて、シェフが「ごちそうさま！」

PMP試験用に！プロセスマップの構造

予測型では「49のプロセス」が5つのプロセス群と10の知識エリアに分類されています。

5つのプロセス群

1. 立ち上げ（立ち上げ）
2. 計画（プランニング）
3. 実行（実行する）
4. 監視・制御（監視と制御）
5. 終結

10の知識エリアは、後述します。

スコープ・管理のプロセスをプロセスマップで見ると？

プロセス名	プロセス群	エリア知識
スコープの計画	計画	スコープ
要望事項の収集	計画	スコープ
スコープの定義	計画	スコープ
WBSの作成	計画	スコープ
スコープの広範囲性確認	監視・制御	スコープ
スコープのコントロール	監視・制御	スコープ

プロセス名	プロセス群	エリア知識
スコープの計画	計画	スコープ
要望事項の収集	計画	スコープ
スコープの定義	計画	スコープ
WBSの作成	計画	スコープ
スコープの広範囲性確認	監視・制御	スコープ
スコープのコントロール	監視・制御	スコープ

このように、「どのプロセス群 × どの知識エリアか？」で地図のどこに属しているかを知るのが「プロセスマップ」です。

試験でよくあるトラップ

• 「プロセス群の名前と意味の混同」
  　→ 計画？監視？どっちだったっけ…となりがち！
• 「マップの全体像を覚えていない」
  　→ 地図なしで登山するようなもの。困難が伴います
• 「アジャイル予測型をごちゃ混ぜ」
  　→ 予測型は「計画命」。 「柔軟対応」は別モードです！

現場あるある

• 「え、計画に３週間もかけるの？」
  　→ それが予測型。設計図を完璧にしてから着工する！
• 「想定外のことが起きたら？」
  　→ 変更管理プロセス徹底的に対応！
• 「終わってから“あ、これ忘れた”」
  　→ それ、計画不足 or スコープ管理ミスです…

まとめ：予測型プロセスマップ＝「緻密に組み上げられた設計図と工程表」

特徴	内容
順番重視	計画→実行→監視→終結の「一直線」
変化に弱い	柔軟性よりも「計画」が命
プロセスマップは必須	どの作業がどの段階・知識エリアに属してるかを意識してください！
試験では出題頻度高	プロセス名・順序・入力/出力は暗記推奨！

特徴	内容
順番重視	計画→実行→監視→終結の「一直線」
変化に弱い	柔軟性よりも「計画」が命
プロセスマップは必須	どの作業がどの段階・知識エリアに属してるかを意識してください！
試験では出題頻度高	プロセス名・順序・入力/出力は暗記推奨！

PMO

PMOとは？

**Project Management Office（プロジェクト・マネジメント・オフィス）**の略で、
「プロジェクトをうまく進めるための『後方支援部隊』」です！

PMOは、プロジェクトマネージャーたちのためにコソッと、でも超重要な仕事をこなしています。

PMがヒーローならPMOは…

PMがヒーローなら、PMOはその秘密基地のスタッフたち！

• PM：現場で戦うヒーロー
• PMO：スーツでパソコンで頑張って支援するインテリ軍団

「この書類、申請済みだよ」
「テンプレートここにあるよ」
「前回のプロジェクト、同じミスしてたから注意ね」

縁の下の力持ち的な存在ですね

PMOの主な役割

項目	内容	例えるなら
標準化	プロジェクト管理のルール・テンプレを整備	「校則を作る生徒会」
教育	PMの育成、ノウハウ共有	「トレーナー兼先輩」
監視・統制	各プロジェクトの状況を確認	「プロジェクトの健康診断係」
リソース管理	人やメンバーの予算を適切に決める	「部活のマネージャー」
戦略アラインメント	経営目標とプロジェクトを一致させる	「経営と現場のパイプ役」

項目	内容	例えるなら
標準化	プロジェクト管理のルール・テンプレを整備	「校則を作る生徒会」
教育	PMの育成、ノウハウ共有	「トレーナー兼先輩」
監視・統制	各プロジェクトの状況を確認	「プロジェクトの健康診断係」
リソース管理	人やメンバーの予算を適切に決める	「部活のマネージャー」
戦略アラインメント	経営目標とプロジェクトを一致させる	「経営と現場のパイプ役」

PMP試験で出るPMOの「3タイプ」

PMOには支援のレベルごとに3つのタイプがあります：

タイプ	支援レベル	とりあえず
支援型（サポート的）	軽めの助け舟	「頼まれたら手伝います」係
制御型（Controlling）	ルール制定して指導	「ルールは守ってね、保留はダメ」係
指示型（ディレクティブ）	PMOが直接指揮する	「PMOがプロジェクトも運営しちゃう」係

タイプ	支援レベル	とりあえず
支援型（サポート的）	軽めの助け舟	「頼まれたら手伝います」係
制御型（Controlling）	ルール制定して指導	「ルールは守ってね、保留はダメ」係
指示型（ディレクティブ）	PMOが直接指揮する	「PMOがプロジェクトも運営しちゃう」係

現場あるある

• 「PMOってExcel職人でしょ？」→ ちがいます。立派な戦略支援部隊です。
• 「PMOは暇そう」→ 裏で泣きながらテンプレ準備してたりします。
• 「またPMOがレビュー差し戻しました…」→ それが仕事なんです、ごめんね
• 「PMOとPMの対立構造」→ チームで協力しましょう💪

まとめ：PMOとはプロジェクトを影から支える「仕組みの守護神」！

• 組織横断でプロジェクトを標準化・最適化！
• タイプ別に支援レベルが違う（支援型・境界型・指示型）
• PMP試験では「PMとの役割の違い」と「PMOのタイプ」が頻出！

ニーズ分析

ニーズ分析って何？

ニーズ分析とは一言で言えば：

「このプロジェクトって、そもそも何のためにやんだっけ？」を突撃活動停止！

つまり、
「それ、本当に必要？」
「誰がそれを求めているの？」
「なぜ今やるの？」
という「根本的な問い」に答えるための調査です。

ケーキ屋で例えるニーズ分析

あなたがケーキ職人だとします。

👩‍💼「バースデーケーキを作って欲しいの」
👨‍🍳「わかりました。何人分？どんな味？ろうそくは？」

…といきなり作り始める前に、分析的にはこうです：

• 「そもそもそのケーキ、なぜ必要なの？」
• 「誰のためのケーキ？」
• 「本当に『ケーキ』でいいの？アイスじゃだめ？」

これが**ニーズ評価（分析ニーズ）です。
プロジェクトの「存在理由」をあぶり出すフェーズです。

ニーズ分析の目的は？

プロジェクトを始める前に、「なぜこのプロジェクトが必要なのか？」を確認して、

• ビジネス上の課題は何か？
• 機会（チャンス）を逃さないためか？
• 問題を解決したいのか？
• それってプロジェクトで解決するのか？

…などを論理的に把握するために行います。

PMP的な視点でのニーズ分析

PMPでは「ニーズ分析」はビジネスケースやプロジェクト憲章の作成に関係してきます。

関連する資料

文書名	ニーズ分析との関係
ビジネスケース	プロジェクトの目的や期待される成果を書く
プロジェクト憲章	何をやるのか・なぜやるかの「公式な宣言」

文書名	ニーズ分析との関係
ビジネスケース	プロジェクトの目的や期待される成果を書く
プロジェクト憲章	何をやるのか・なぜやるかの「公式な宣言」

ニーズ分析の構成要素（概要）

1. 現状把握：今、問題は？
2. 理想の姿：どうなって嬉しいですか？
3. ギャップ分析：今と理想の差はどれくらい？
4. 対応案の検討：プロジェクトで解決できるか？
5. ステークホルダーのニーズ確認：本当の「お客さん」は誰ですか？

現場あるある

• 「社長の一声で始まったけど、誰もどうしてやら分からない」
  　→ ニーズ分析してなかったパターンです💀
• 「とりあえずシステム作ったけど、誰も使ってくれない」
  　→ 必要なかったパターン😇
• 「「これ、うちの課じゃないです」って言われた」 → ニーズを
  　見間違えたパターン🥶

まとめ：ニーズ 分析は「プロジェクトの理由」を探す！

• プロジェクトを始める前に「そもそも必要？」をチェック！
• ビジネスケースやプロジェクト憲章のベースになる！
• 「課題」「機会」「理想と現実のギャップ」を分析する！
• ステークホルダーの期待をすり合わせるのに超重要！

ベネフィット実現計画

ベネフィット実現計画ってなに？

ベネフィット実現計画とは一言でいえば、

「このプロジェクト、やった後に『ちゃんと得する』という計画を立ててました！」

つまり、

• 「作るだけ作って終わり」じゃダメ！
• 「本当に価値が出るまで見届けよう！」

という「アフターケア計画」です。

寿司職人でのたとえ話

あなたが寿司職人だとして、

👨‍💼「シャリ完璧！ネタも新鮮！美しく握れたぞ！」

…だけで終わったらダメなんです。

お客さんが
いらっしゃいました👩‍🍳「美味しかった！また来たね」
と言って、**実際に来てくれて初めて「価値が実現」したってこと。

これが「ベネフィットの実現」です。

PMPではどう問われる？

PMPでは、ベネフィット実現計画はメインにビジネス文書の一部として登場します。

ベネフィット実現計画は、プロジェクトの成果が、正しくビジネス価値につながっていく計画です。

ベネフィット実現計画に含まれる内容（概要）

項目	内容
目的（目標）	何のためのベネフィットか？（例：売上UP）
ベネフィット内容	得られる価値・利益（例：生産性20％向上）
タイムライン	いつ得られる予定？（短期／中期／長期）
責任者	誰が進んでる？（PMだけじゃない！）
評価方法	どうやって「得したか」を測る？（KPIなど）

項目	内容
目的（目標）	何のためのベネフィットか？（例：売上UP）
ベネフィット内容	得られる価値・利益（例：生産性20％向上）
タイムライン	いつ得られる予定？（短期／中期／長期）
責任者	誰が進んでる？（PMだけじゃない！）
評価方法	どうやって「得したか」を測る？（KPIなど）

現場あるあるある

• 「新システム入れたけど、誰も使ってない…」
  　→「成果物は納品したけど、ベネフィット実現してない」
• 「使う人の声を聞かずに計画しちゃった」
  　→ 実際のニーズとズレて、期待した効果ナシ！
• 「成功報告して終わったけど、その後どうなったか不明」
  　→ 「実現できたか誰も追ってない」パターン！

10の知識エリア

10の知識エリアとは？

PMの世界では、プロジェクトを管理する上で必要な知識を10の分野に分けて整理しています。
各分野は「この分野がちゃんとして大事、プロジェクト危ういよ！」という重要な部分です。

エリア知識	映画制作なら…	一言で言うと…
①統合管理	監督	全体のまとめ役
②スコープ管理	脚本家	やること・やらないこと決定
③スケジュール管理	撮影スケジュール係	いつ何をやるか調整
④コスト管理	経理	予算を守れ！
⑤ 品質管理	映像チェック班	出来をチェック！粗くない？
⑥資源管理	キャスティング・スタッフ係	人・モノの手配
⑦コミュニケーション管理	広報・調整係	情報を正しく届ける
⑧ リスク管理	危機対策班	トラブル予防＆対処法
⑨調達管理	外注・業者係	必要なものを外から調達
⑩ステークホルダー管理	観客・観客との対応	みんなを満足させる

エリア知識	映画制作なら…	一言で言うと…
①統合管理	監督	全体のまとめ役
②スコープ管理	脚本家	やること・やらないこと決定
③スケジュール管理	撮影スケジュール係	いつ何をやるか調整
④コスト管理	経理	予算を守れ！
⑤ 品質管理	映像チェック班	出来をチェック！粗くない？
⑥資源管理	キャスティング・スタッフ係	人・モノの手配
⑦コミュニケーション管理	広報・調整係	情報を正しく届ける
⑧ リスク管理	危機対策班	トラブル予防＆対処法
⑨調達管理	外注・業者係	必要なものを外から調達
⑩ステークホルダー管理	観客・観客との対応	みんなを満足させる

それぞれの知識エリアの概略解説

①【統合管理】

統合管理とは、プロジェクト全体のバランスを取る「全体監督」のような存在

• プロジェクト憲章を作る
• 計画を一つに考える（統合計画書）
• 変更も統合的に対応！

「みんな、バラバラに動かないで〜！」って叫んでる人。

---

②【スコープマネジメント】

スコープマネジメントは、「やること・やらないこと」の線引きを行う。

• 要求を訴える
• WBSを作る
• 勝手に作業が増える「スコープクリープ」は要注意⚠️

「注文はショートケーキだけ。チョコケーキは頼まれません！」

---

③【スケジュール管理】

いつ・何を・どの順番でやるか！

• アクティビティ定義
• 順序設定（ネットワーク図）
• ご希望の時間見積りと日程作成

⏰「締切まであと3日！？誰だ、サボってたの！」

---

④【コスト管理】

④【コスト管理】：お金をしっかり管理！

• 見積り
• 予算編成
• 実績との比較（EVM！）

「予算？あ、もう使い切りました…（怖い声）」

---

⑤【品質管理】

⑤【品質管理】：作るものが「ちゃんとしてるか」を保証

• 品質の基準を設定
• チェックと改善

🧐「ほらここ、ネジ緩んでますよ？再チェック！」

---

⑥【資源管理】

⑥【資源管理】：人・モノ・設備の管理

• チームビルディング
• 効果的な役割分担

👷‍♂️「あの人、3つの作業掛け持ちして瀕死状態です！」

---

⑦【コミュニケーションマネジメント】

⑦【コミュニケーションマネジメント】：危険を防ぐ！情報の正しい伝達！

• ステークホルダーとの連絡ルール設定
• 情報のタイムリーな発信・受信

📨「メール届いてないって！？でも送ったのに…！」

---

⑧【リスク管理】

⑧【リスク管理】：トラブルの予測と備え！

• リスクの特定
• 分析（定性／定量）
• 対応計画と監視

🧨「え、発注先が決まる！？想定はしてたけど現実になるとバイヤ！」

---

⑨【調達マネジメント】

⑨【調達マネジメント】：必要なモノ・サービスを「外から調達」！

• 契約管理
• ベンダー選定
• 外気との関係構築

📦「この部品、Amazonじゃダメですよね…？」

---

⑩【ステークホルダー・マネジメント】

⑩【ステークホルダー・マネジメント】：プロジェクトに関わる全ての人々の管理に期待！

• 識別・分析・関与戦略の構想

🙋‍♀️「部長が『この機能は絶対つけろ！』って言ってます…」
→「いや、それは最初の要件にないです！」

まとめ：10の知識エリアはプロジェクト成功の「10人の職人」！

10の知識エリア＝プロジェクト運営の「全体像」
各エリアには「プロセス」が割り当てられている（例：スケジュール管理には6つのプロセス）
それぞれは相互に影響を考える！個別エリアじゃない！

• どれか一人が手を抜くと、プロジェクトは崩れやすい
• 全体を見て、調整しながらのがPMの腕の見せ場
• PMP試験では「この知識エリアで何をするか？」が頻繁に出ます！