PMP Study Hall 01 Flashcards
(43 cards)
ステークホルダーは、プロジェクトのために購入した機材が予定より高品質なものだと知り、コストがかさむことを懸念してプロジェクト・マネジャーに尋ねところ、割引価格で購入したという答えでした。
プロジェクト・マネジャーは、ステークホルダーに逐次情報共有するために何をすべきだったでしょうか？
A.コミュニケーション・マネジメント計画書を更新する。
B.機材の差し替えについてのリスク分析結果を伝える。
C.統合変更管理を実施する。
D.品質検査の結果を文書化する。
正解：C 統合変更管理を実施する。
プロジェクトマネジャーは、統合変更管理により、プロジェクト要素への変更の評価およびマネジメント、承認の取得、スコープや成果物の変更に関するステークホルダーへの情報共有を確実に行うべきでした。そうすれば、機材の差し替えに対するステークホルダーの懸念に対しもっと体系的かつ透明性の高い対応ができたはずです。
変更管理の必要性を認識する
プロジェクト計画と異なる機材が導入された ➝ プロジェクトの変更が発生した 変更管理プロセスなしに導入すると、ステークホルダーとの認識ズレが生じる
2️⃣ 「統合変更管理」が適用されるケースを考える
PMBOKにおける統合変更管理（Integrated Change Control） とは： ✅ プロジェクトのスコープ、コスト、品質、リスクなどに影響を及ぼす変更を評価・承認・文書化するプロセス
✅ 変更を正しく管理し、関係者と適切に調整することが目的
✅ 本件では、「予定より高品質な機材を導入する変更」が発生しており、この変更の影響を分析し、適切に管理する必要がある
3️⃣ 他の選択肢との比較
A（計画書の更新） → 変更管理を行わずに計画書を修正するだけでは、変更の影響が十分に評価されない B（リスク分析の伝達） → 機材の品質変更がリスクになるかどうかの分析も重要だが、まずは変更管理を実施することが優先 D（品質検査の記録） → 品質が適切であることを記録するのは重要だが、ステークホルダーに説明責任を果たすには不十分
Difficult
プロジェクト・マネジャーは、プロジェクト終了時にはいつもレトロスペクティブ・セッションを実施しています。しかしスポンサーはこれを時間と予算のムダと見なし、今後のプロジェクトではレトロスペクティブを大幅に縮小するか、行わないように指示しました。
この指示はどのような結果をもたらす可能性があるでしょうか？
A.将来プロジェクトでの改善案の特定より課題の議論を重視するようになる。
B.プロジェクトの一部の所見に基づくチームのプロセス改善の機会がなくなる。
C.プロジェクトのパフォーマンスに関してステークホルダーの所見を重視するようになる。
D.タイム・マネジメント計画書の更新が適切に行われなくなる。
正解：A 将来プロジェクトでの改善案の特定より課題についての議論に焦点が移る。
レトロスペクティブを行わないと、将来プロジェクトの改善より課題を重視するようになり、チームは学習、適応、プロセス改善ができなくなる可能性があります。
1️⃣ レトロスペクティブの役割を理解する
振り返りの機会を提供し、チームの成長と改善を促す プロジェクトで発生した課題を特定し、次回以降のプロジェクトで活かすためのアクションを決める
2️⃣ レトロスペクティブが縮小・中止された場合の影響を考える
チームは 課題の議論 ばかりになり、具体的な改善策を話し合う機会が減る プロジェクトで発生した問題を議論することはあっても、根本的な解決策を見つける機会が失われる 結果として、チームの成長が阻害され、同じ問題が繰り返されるリスクが高まる
3️⃣ Aが正解である理由
Aは、「改善策の特定が減ることで、問題を議論することばかりになってしまう」 という直接的な影響を述べている 他の選択肢（B, C, D）は、レトロスペクティブの削減の影響を正しく捉えていない、または影響が間接的すぎる
✅ まとめ
レトロスペクティブがなくなると、課題の議論は続くが、それを改善策につなげる機会が減る その結果、問題解決よりも「問題の共有」ばかりが優先されるようになる これを正しく表しているのが「A. 将来プロジェクトでの改善案の特定より課題の議論を重視するようになる」
Difficult
スクラム・マスターが担当するハイブリッド型プロジェクトで、チーム内でのコンフリクトが発生しています。この場合、どのようにコンフリクト・マネジメントに取り組むべきでしょうか？
A.チームと協力してコンフリクトの原因を特定し、原因となっているメンバーを外す。
B.コンフリクトのリストを作成し、今後の進め方についてチームで投票をする。
C.コンフリクトを構造的なものと対人的なものに分類する。
D.デイリー・スクラムでコンフリクトをレビューして早期解決を図る。
正解：C コンフリクトを構造的なものと対人的なものに分類する。
スクラムマスターは、コンフリクトを分類することで根本原因を特定し、対処方法を考えることができます。構造的なコンフリクトとは、非現実的な納期や不明確な期待といったチーム外部の要因によって生じるものです。対人的なコンフリクトとは、性格の不一致や作業スタイルの違いといった、チーム・メンバー間の相違点に起因するものです。コンフリクトの根本原因が判明すれば、それに対処する計画を立てられます。
選択肢のキーワード
C. コンフリクトを構造的なものと対人的なものに分類する。 ✅（正解）
→ 「コンフリクトを構造的と対人的に分類する」
構造的な問題（役割の重複、リソース不足、プロセスの不備など） 対人的な問題（コミュニケーション不足、価値観の違いなど） それぞれに異なるアプローチが必要なため、適切な解決策を導きやすくなる。
D. デイリー・スクラムでコンフリクトをレビューして早期解決を図る。
→ 「デイリー・スクラムでコンフリクトをレビュー」
デイリー・スクラムは進捗確認が主目的であり、長時間の議論には適さない。 コンフリクト解決の場としては不適切。
Moderate
プロジェクト・マネジャーは、プロジェクト成果物の評価に関して何人かのステークホルダー間で意見が分かれていることを知りました。
プロジェクト・マネジャーは次にどのような行動を取るべきでしょうか？
A.プロジェクトの要求文書をレビューして分析する。
B.承認済みのスコープ記述書をレビューする。
C.当該ステークホルダーとの会議を実施する。
D.プロジェクトのリスクとその対応策を書いた文書を更新する。
正解：C 当該ステークホルダーとの会議を実施する。
ステークホルダー間で意見の不一致について話し合い合意形成を図ります。
選択肢のキーワード（定義リスト形式）
A. プロジェクトの要求文書をレビューして分析する。
→ 「要求文書のレビュー」
要求文書にはステークホルダーのニーズが記載されているが、成果物の評価に関する意見の違いを直接解決できるわけではない。
すでに承認された要件がある場合、それを変更できるかどうかも含めて議論する必要がある。
B. 承認済みのスコープ記述書をレビューする。
→ 「スコープ記述書のレビュー」
スコープ記述書にはプロジェクトの範囲や成果物の基準が記載されているため、評価の基準を確認するためには有効。
しかし、意見の違いを直接解決するためには、関係者と話し合う方が重要。
C. 当該ステークホルダーとの会議を実施する。 ✅（正解）
→ 「ステークホルダーとの会議」
意見の違いがあるなら、まずは直接対話し、何が問題なのかを明確にする必要がある。
ステークホルダーの期待と成果物の実態をすり合わせることで、納得感のある結論を導ける。
D. プロジェクトのリスクとその対応策を書いた文書を更新する。
→ 「リスク文書の更新」
成果物の評価に関する意見の違いは、リスク管理の問題というよりも期待マネジメントの問題。
まずは意見の違いを調整することが優先であり、即座にリスク文書を更新するのは適切ではない。
🧠 どのように思考して正解を導き出せばよいのか？
「成果物の評価」の文脈を正しく理解する
成果物の評価に関する意見の違いがあるということは、期待と実際のギャップがある可能性が高い。
そのため、成果物の基準を確認しつつ、関係者間で意見をすり合わせるプロセスが必要。
まずは直接対話することが最優先
文書（要求文書やスコープ記述書）を見直すのも有効だが、それだけでは意見の相違を解消できない。
「なぜ評価が分かれているのか？」 を明らかにするには、ステークホルダーと直接話すのが最も効果的。
「リスク管理」ではなく「期待マネジメント」が重要
ステークホルダーの意見の不一致は、リスク管理というより期待のすり合わせの問題。
したがって、リスク文書を更新するよりも、会議を実施して解決策を模索するのが適切なアプローチ。
結論：
まずは「C. 当該ステークホルダーとの会議を実施する」を選び、意見の違いを整理・調整するのが最も効果的な解決策となる。
Moderate
ある企業が、自社の命運をかけた新製品を発売しようとしています。ステークホルダーは成功の鍵を握る要因として、市場ニーズへの適合、競合製品への迅速な対応、アジリティの3つを特定しました。
プロジェクトを成功に導くために、プロジェクト・マネジャーは何をすべきでしょうか？
A.マーケティング・チームと連携して販促活動を行い市場の変化に対応する。
B.あらゆる課題に対処できるようにプロジェクトの予算と資源を十分に確保する。
C.プロジェクトに積極的に参加し、進捗の監視、必要な変更、データの収集などを行う。
D.ステークホルダーをスタンドアップミーティングに招待してプロジェクトの成功に積極的に関与してもらう。
正解：A マーケティング・チームと連携して販促活動を行い市場の変化に対応する。
市場ニーズへ適合するには、マーケティング・チームと協力して、ターゲット市場にリーチするマーケティング計画を立て、市場の変化に応じて適宜計画を見直す必要があります。
どのように思考して正解を導き出せばよいのか？
ステークホルダーが求める成功要因を特定する
「市場ニーズへの適合」「競合への迅速な対応」「アジリティ」
これらに最も直結するのは「市場の変化への対応」。
市場の変化や競争環境に対応するための行動を選ぶ
A（マーケティングと連携して市場の変化に対応する）が最も適切。
B（予算確保）やC（進捗管理）は重要ではあるが、市場適応に直接つながるとは限らない。
マーケティングとの連携が競争優位性を高める
新製品の成功には、技術的な完成度だけでなく、市場への適応と認知拡大が不可欠。
マーケティングと協力することで、リアルタイムの市場ニーズに対応し、競争力を維持できる。
Difficult
プロジェクト・マネジャーは、複雑なシステム改善プロジェクトを担当しています。統合フェーズであるコンポーネントを更新したところ、全部署が在庫データの参照に使っているコンポーネントが使えなくなりました。
プロジェクト・マネジャーはまず何をすべきでしょうか？
A.運用計画を参照して問題の最善策を見極める。
B.コミュニケーション・マネジメント計画書に従って、ステークホルダーにこの問題を報告する。
C.課題ログを更新して問題の最終的な解決策を記録する。
D.リスク・マネジメント計画書の戦略を確認して問題に対処する。
正解：D リスク・マネジメント計画書の戦略を確認して問題に対処する。
リスク・マネジメント計画書には、潜在的なリスクとその対応を記載します。重要な機能が停止した場合の対応について、事前に決めた方法があればそれに従うべきです。
どのように思考して正解を導き出せばよいのか？
問題の性質を理解する
「統合フェーズでコンポーネントを更新したら在庫データの参照ができなくなった」
→ 変更が原因で問題が発生しており、影響範囲が広い（全部署が影響を受ける）。
→ つまり、リスク管理の観点からのアクションが必要。
まず何をすべきかを考える
現時点で最優先すべきは、問題の発生原因と影響を特定し、適切な対応策を講じること。
→ そのためには、事前に策定されたリスク対応計画を確認するのが最も合理的。
各選択肢の適切さを判断する
A（運用計画を参照） → 問題解決に直接役立つとは限らない。
B（ステークホルダー報告） → 報告は重要だが、問題解決の前にやるべきではない。
C（課題ログの更新） → 問題解決後の記録としては必要だが、最優先ではない。
D（リスク・マネジメント計画の確認） → 問題に対する事前の対策や対応手順が含まれている可能性が高いため、最も適切な対応。
Difficult
予測型プロジェクトの実行中に、機能部門マネジャーが製品に使われている材料の環境への影響に気づき、プロジェクト・マネジャーに材料の変更を求めました。プロジェクト・マネジャーは最初にどのような対応を取るべきでしょうか？
A.材料変更の実現可能性と影響を評価するための実証実験の計画をプロジェクト・スポンサーに示す。
B.材料の変更を認めて環境にやさしい材料への移行を開始する。
C.プロジェクト実行中に材料の変更は認められないと機能部門マネジャーに伝える。
D.所定の変更管理プロセスを通じて正式な変更要求を提出するよう機能部門マネジャーに伝える。
正解：A 材料変更の実現可能性と影響を評価するための実証実験の計画をプロジェクト・スポンサーに示す。
予測型プロジェクトでは、実証実験により意思決定に必要な情報を得る場合があります。実証実験とは、案の実現可能性をテストするための実験です。実験結果に基づき、プロジェクトの変更を調整します。
各選択肢の評価
A. 材料変更の実現可能性と影響を評価するための実証実験の計画をプロジェクト・スポンサーに示す。 ✅ （正解）
分析プロセス（Evaluate Feasibility） に基づき、材料変更の実現可能性を評価するのが適切。 予測型プロジェクトでは、変更の影響を 「事前評価」 することが重要。 変更が技術的・コスト的に受け入れられるか、実証実験を通じて確認することが合理的 。 変更を即座に受け入れるのではなく、事実に基づいた意思決定 をサポートするアプローチ。
B. 材料の変更を認めて環境にやさしい材料への移行を開始する。 ❌ （不正解）
予測型プロジェクトでは、計画変更は統合変更管理プロセスを経るべきであり、即座に実施するのは適切でない。 コスト・スケジュール・品質に与える影響を無視している ため、リスクが高い。 変更の妥当性が不明な段階で移行を始めると、将来的に問題が発生する可能性がある 。
C. プロジェクト実行中に材料の変更は認められないと機能部門マネジャーに伝える。 ❌ （不正解）
環境影響が重要な問題であれば、無視するのは適切でない。 変更は原則として厳格に管理されるが、環境コンプライアンスのリスクがある場合、適切な分析を行うべき 。 機能部門マネジャーの懸念を無視すると、ステークホルダー・マネジメントの観点からも問題を引き起こす 可能性がある。
D. 所定の変更管理プロセスを通じて正式な変更要求を提出するよう機能部門マネジャーに伝える。 ❌ （不正解）
変更要求（Change Request）は 変更管理プロセスの一環 ではあるが、変更の影響を評価せずに進めるのは適切でない。 まずは変更の実現可能性を評価し、それをもとに変更要求を提出するべき 。 影響分析なしに変更要求を進めると、承認プロセスで問題が発生する可能性がある 。 その他の選択肢は適切な対応ではありません。 影響を評価することなく材料の変更を認めれば、思わぬ別の問題を引き起こしかねません。 変更を拒否するのもまた環境問題を放置することになり現実的ではありません。 変更要求を提出するには、まず材料変更による影響を評価する必要があります。
Expert
プロジェクトに関与していた機能部門マネジャーがプロジェクトの開発期間中に退職してしまいました。
プロジェクト・マネジャーはまず何をすべきでしょうか？
A.変更ログを更新する。
B.リスク登録簿を更新する。
C.ステークホルダー登録簿を更新する。
D.前提条件ログを更新する。
正解：C ステークホルダー登録簿を更新する。
ステークホルダー登録簿を更新して、ステークホルダー全員に機能部門マネジャーの退職を周知し、必要に応じて後任の人員を配置して、連絡先、役割、責任を追加します。
問題文および選択肢のキーワード
機能部門マネジャーの退職：プロジェクトに関与する重要なステークホルダーがいなくなる状況。 プロジェクトの開発期間中：進行中のプロジェクトにおける影響を考慮する必要がある。 ステークホルダー登録簿：プロジェクトに関与する人物の情報を管理するドキュメント。 変更ログ：スコープやプロジェクト計画の変更履歴を記録するもの。 リスク登録簿：識別されたリスクを記録・分析するもの。 前提条件ログ：プロジェクトの基本的な仮定（前提条件）を記録するもの。
Moderate
プロジェクト・マネジャーは、プロジェクトへのエンゲージメントを高めてもらうために、ステークホルダーをデイリー・スタンドアップに招待しましたが、誰も出席してくれません。
プロジェクト・マネジャーはどうすべきでしょうか？
A.ステークホルダーと個別に会って欠席の理由を聞く。
B.従来通りデイリー・スタンドアップを続けてステークホルダーが参加するのを待つ。
C.デイリー・スタンドアップはやめて別のコミュニケーション手段を考える。
D.上層部に問題をエスカレーションして介入を求める。
正解：A ステークホルダーと個別に会って欠席の理由を聞く。
ステークホルダーと個別に会って話を聞き、出席の妨げとなっている懸念や障害を把握します。原因が分かれば、各ステークホルダー固有のニーズに合わせて解決策を考えることができます。
その他の選択肢は誤りです。
何も対応せずにただ来るのを待っていても問題は解決しません。
デイリー・スタンドアップをやめてしまうのは本末転倒です。
上層部へのエスカレーションは、原因を特定して何等かの対策を打ってからです。
Easy
プロジェクト・マネジャーは、新たなプロジェクトにアサインされました。このプロジェクトのきっかけは、顧客の取引先からの提案だったそうです。プロジェクト・マネジャーは、プロジェクト目標を明確に理解するために何をすべきでしょうか？
A.顧客の取引先にインタビューをして期待と目標を明らかにする。
B.顧客の取引先を含むステークホルダーから直接情報収集した上でプロジェクト目標を設定する。
C.今ある情報と前提条件に基づいてプロジェクトを立ち上げて全体プロジェクト計画を立てる。
D.顧客からプロジェクトの当初の提案について聞き、顧客のビジョンを明確化する。
正解：B 顧客の取引先を含むステークホルダーから直接情報収集した上でプロジェクト目標を設定する。
プロジェクトの提案者本人や関係者の意見を聞いて目標を設定すれば、顧客のビジョンを明確化し、関係者全員が共通認識を持てます。これによりプロジェクト成果にも良い影響が期待できます。
その他の選択肢は最善策とは言えません。
顧客の取引先へのインタビューは必要ですが、プロジェクト目標はステークホルダーを交えて設定すべきです。
今ある情報だけでプロジェクト計画を立てるのは早計です。明確なプロジェクト目標の設定が先です。
プロジェクトの当初提案も大事ですが、それだけでは不十分です。
Difficult
プロジェクト・マネジャーは、プロジェクト憲章にビジネス戦略目標との矛盾を見つけたのでなんらかの修正が必要です。
プロジェクト・マネジャーはどうすべきでしょうか？
A.プロジェクト憲章をプロジェクト・チームとレビューして修正する。
B.プロジェクト憲章をステークホルダーとレビューして修正する。
C.プロジェクト・スポンサーにエスカレーションして支援と承認を頼む。
D.プロジェクト憲章を変更するための正式な変更要求を提出する。
正解：C プロジェクト・スポンサーにエスカレーションして支援と承認を頼む。
プロジェクト・スポンサーは、プロジェクトと組織の戦略目標の整合性を取る責任があります。プロジェクト・マネジャーはスポンサーに状況を説明した上で対応策を提案すべきです。スポンサーは、不整合の原因特定、再調整の計画、必要な資源や権限の確保、再調整の必要性の説明などの支援を提供します。
問題文および選択肢のキーワード
プロジェクト憲章：プロジェクトの正式な立ち上げを示す文書で、ビジネス戦略目標との整合性が求められる。 矛盾：プロジェクト憲章が、組織のビジネス戦略と一致していない状態。 修正：矛盾を解決するために、適切な権限を持つ者の承認を得る必要がある。
選択肢の主要キーワード
A. プロジェクト憲章をプロジェクト・チームとレビューして修正する。 ❌ （不正解）
プロジェクト憲章は、プロジェクト・マネジャーが作成・変更する文書ではなく、スポンサーが承認するもの。
プロジェクト・チームに憲章を変更する権限はないため、適切でない。
B. プロジェクト憲章をステークホルダーとレビューして修正する。 ❌ （不正解）
ステークホルダーは広義にわたるため、誰に承認権限があるかが不明確。
プロジェクト憲章の修正にはスポンサーの承認が必要であるため、適切ではない。
C. プロジェクト・スポンサーにエスカレーションして支援と承認を頼む。 ✅ （正解）
プロジェクト憲章は、通常プロジェクト・スポンサーが作成または承認する文書である。
矛盾がある場合、スポンサーに報告し、修正の承認を得る必要がある。
スポンサーはプロジェクトの全体的な方向性を決定し、ビジネス戦略との整合性を確保する立場にあるため、適切な対応。
D. プロジェクト憲章を変更するための正式な変更要求を提出する。 ❌ （不正解）
プロジェクト憲章は正式な変更管理プロセスを経る対象ではなく、通常はスポンサーの判断で修正される。
変更要求（Change Request）は、スコープ、スケジュール、コスト、リスクなどに適用されるが、プロジェクト憲章には適用されない。
思考プロセス
1️⃣ プロジェクト憲章の性質を理解する
プロジェクト憲章は、スポンサーが承認する最上位の文書であり、プロジェクト・マネジャーが勝手に変更できるものではない。 プロジェクトの方向性を定める基本文書であり、ビジネス戦略との整合性が必須。
2️⃣ 適切な対応者を特定する
プロジェクト・チームや一般のステークホルダーにプロジェクト憲章の修正権限はない。 変更するには最終承認者であるプロジェクト・スポンサーにエスカレーションするのが適切。
3️⃣ プロジェクト憲章の変更プロセスを考慮する
プロジェクト憲章は正式な変更管理プロセスではなく、スポンサーの判断で修正されることが一般的。 変更要求プロセスを適用するのは適切でない。
Expert
プロジェクト・マネジャーは、家庭用新製品の実用最小限のプロダクト（MVP）の発売プロジェクトを担当しており、全6回のイテレーションの3回目まで順調に進んでいます。イテレーション計画会議で顧客がチームに対し、他社が類似製品を次の四半期に発売予定だと知らせました。プロジェクト・マネジャーは、この競争上の課題にどう対処すべきでしょうか？
A.課題ログに記録して、次回のプロジェクト報告書に詳しく記述する。
B.競合企業を出し抜くためにチームを増員して製品発表を前倒しする。
C.製品発表を前倒しするためにプロジェクト・バックログを削減できないか顧客と相談する。
D.競合企業を出し抜くためにプロジェクト・チームと協力してMVPを定義し直す。
正解：D 競合企業を出し抜くためにプロジェクト・チームと協力してMVPを定義し直す。
プロジェクト・チームと協力して、顧客が特に重視し必要とする基本的なフィーチャーを特定すべきです。そうすれば、品質を犠牲にすることなく、それらのフィーチャーを迅速かつ効率的に開発することに集中できるようになります。その結果としてチームは、競合企業よりも先に、または競合企業と同時期に製品を発売することで、市場における競争力を維持できます。
選択肢のキーワード
C.「製品発表を前倒しするためにプロジェクト・バックログを削減できないか顧客と相談する。」
→ プロジェクト・バックログを削減するのではなく、MVPの再定義をする方が適切。
D.「競合企業を出し抜くためにプロジェクト・チームと協力してMVPを定義し直す。」（✅ 正解）
→ MVPの定義を見直し、最小限の機能で市場投入することで競争優位を確保する。
適切なアクションは「MVPの再定義」
A（記録だけ） → 問題解決にならない。 B（チーム増員） → 短期間で効果が出るとは限らない。 C（バックログ削減） → 価値のある機能を削るリスクがある。 D（MVPの再定義） → 市場ニーズに合った最小限の製品を素早く投入できるため、適切な対応となる。
その他の選択肢が誤りなのは、競争上の課題への対処策として有効とも戦略的とも言えないからです。
この課題をログに登録した上で、その詳細を次回のプロジェクト状況報告書に包括的に記載するのは大事ですが、この課題に対する積極的な方策を講じることにはなりません。この課題をログに登録するだけでなく、競争上の課題に効果的に対処するための行動を起こす必要があります。
チームを増員することは、必ずしも可能とも最善とも言えない解決策です。チームを急拡大すれば、非効率や品質上の懸念が生じかねません。また、プロジェクトのスコープを戦略的に調整する必要性には対処しないことにもなります。
顧客に会い、プロジェクト・バックログを削減する可能性について話し合うのが誤りなのは、それだけでは競争の激しい市場に製品を適時に投入できない可能性があるからです。この選択肢は、MVPを再定義して基本的なフィーチャーに集中する必要があるという、この事例で重要な点に直接対処するものではありません。
Difficult
プロジェクト・マネジャーは、部署横断的なアジャイル・プロジェクトを担当していますが、当初出ていなかった要件追加を提案するメンバーがいます。
プロジェクト・マネジャーは、アジャイルでは期待されているこの行動に対してどう対応すべきでしょうか？
A.フレームワークを使ってスコープ管理ができるようにチームにコーチングを行う。
B.スポンサーにエスカレーションしてチーム・メンバーの入れ替えを求める。
C.チームとステークホルダーを集めてデイリー・スタンドアップを行う。
D.要件の変更には承認が必要だと説明する。
正解：A フレームワークを使ってスコープ管理ができるようにチームにコーチングを行う。
チームが標準的なアジャイル・フレームワークを使ってバックログの管理ができるようコーチングします。
問題文および選択肢のキーワード
「部署横断的なアジャイル・プロジェクト」
→ 部署をまたぐプロジェクトであり、関与するステークホルダーが多いため、スコープのコントロールが重要。
A.「フレームワークを使ってスコープ管理ができるようにチームにコーチングを行う。」（✅ 正解）
→ アジャイルでは、要件の変更はプロダクト・バックログを通じて管理されるため、チームが適切に対応できるようコーチングするのが適切。
C.「チームとステークホルダーを集めてデイリー・スタンドアップを行う。」
→ デイリー・スタンドアップは進捗共有の場であり、スコープ管理のためのものではないため、不適切。
Difficult
プロジェクト・マネジャーは、IT 部門の作業負荷軽減のために、業務部門がソリューション実装の一部を担えるようにしようとしています。 プロジェクト・マネジャーはこの移行をどのように促進すべきですか?
A.IT部門による厳格なITガバナンスによりIT活動の一貫性と管理を徹底する。
B.ITプロジェクトの開始前に提案書を提出してIT部門の承認を得ることを義務付ける。
C.簡単なITプロジェクトマネジメント・プラットフォームを使って業務部門が自身でプロジェクトの立ち上げと監視を行えるようにする。
D.IT部門と業務部門が協力してITプロジェクトを共同で計画、実行する。
正解：C 簡単なITプロジェクトマネジメント・プラットフォームを使って業務部門が自身でプロジェクトの立ち上げと監視を行えるようにする。
業務部門が自身でITプロジェクトを管理でき、透明性を確保しつつIT部門の負担を軽減できます。
問題文および選択肢のキーワード
「IT部門の作業負荷軽減」 → IT部門の負担を減らし、業務部門に作業を移管する必要がある。 「業務部門がソリューション実装の一部を担う」 → IT業務の一部を業務部門で実施できるようにする必要がある。 「移行を促進」 → スムーズに業務部門が自律的にIT関連作業を進められるようにするための施策が求められる。
C.「簡単なITプロジェクトマネジメント・プラットフォームを使って業務部門が自身でプロジェクトの立ち上げと監視を行えるようにする。」
→ 業務部門が自律的にプロジェクト管理できる仕組みを整えることで、IT部門の負担を減らせる。 ✅ （正解）
D.「IT部門と業務部門が協力してITプロジェクトを共同で計画、実行する。」
→ 「協力」は重要だが、業務部門の自律性を高める目的には直結しない。IT部門の負担軽減にはつながらないため不適切。❌
その他の選択肢は誤りです。
厳格なITガバナンスポリシーを作れば、業務部門の自律性や柔軟性が抑制され、IT部門の作業負荷が高まる可能性があります。
IT部門と業務部門のコラボレーションは、IT部門の作業負荷軽減につながるとは限りません。
IT部門への提案書提出は、管理の集中によりプロジェクト立ち上げのボトルネックになる可能性があります。IT部門の作業負荷が増えてプロセスを減速しかねません。
Difficult
開発プロジェクトの獲得価値（EV）は64万ドル、計画価値（PV)は80万ドルです。プロジェクト・マネジャーは、この差異をコントロールするために何をすべきでしょうか？
A.プロジェクトの最新状況を反映するためにEVを計算してベースラインを変更する。
B.遅れている作業に16万ドルを再配分する。
C.プロジェクト・パフォーマンス指標を使って是正処置を決定する。
D.プロジェクトを計画通りに完了するためにサプライヤーに16万ドルを払ってファスト・トラッキングを行う。
正解：C プロジェクト・パフォーマンス指標を使って是正処置を決定する。
EVがPVより小さいのでプロジェクトを軌道修正するための是正処置が必要です。
選択肢の評価
A.「プロジェクトの最新状況を反映するためにEVを計算してベースラインを変更する。」❌
→ EVは実績データなので変更できない。
→ ベースラインを変更するのは、スコープ変更があった場合であり、このケースには適さない。
C.「プロジェクト・パフォーマンス指標を使って是正処置を決定する。」✅（正解）
→ 遅れの原因を把握し、適切な対策を決定するのが先決。
→ SPI（スケジュール効率指数）などの指標を確認し、適切な是正処置を実施するのがPMBOKの考え方。
プロジェクト・マネジャーは、ソフトウェア開発のプロジェクト憲章を作成中です。このプロジェクトではユーザー・インターフェイス（UI）評価の33％を外注する予定でどの部分を外注するかを決める開発者が必要です。しかし、ソフトウェア開発部門のマネジャーは自部門のスタッフが減ることを嫌い協力を拒んでいます。
プロジェクト・マネジャーは最初に何をすべきでしょうか？
A.開発部門マネジャーと会って作業範囲記述書（SOW）をレビューする。
B.UI評価を行う理由をプロジェクト・スポンサーから開発部門マネジャーに説明してもらう。
C.UI評価の費用便益分析結果を開発部門マネジャーに示す。
D.UI評価の意図を開発部門マネジャーに説明する。
A 開発部門マネジャーと会って作業範囲記述書（SOW）をレビューする。
プロジェクト初期段階でプロジェクト憲章作成に当たって最初に行うのは、すべてのステークホルダーとともにSOWをレビューすることです。SOWはプロジェクト憲章よりも先に作成するのが一般的です。この事例では、プロジェクト・マネジャーは、機能部門マネジャーの要員ニーズに関する懸念に対処するために早期に話し合うべきです。
作業範囲記述書（SOW: Statement of Work）
プロジェクトや契約作業の範囲を明確に定義する文書。
正解の選択肢：A. 作業範囲記述書（SOW）をレビューする
✅ 思考プロセス
問題の本質を理解する
開発部門マネジャーは「自部門のスタッフが減ることを懸念」している。
つまり、「外注の範囲」と「内部スタッフの影響度」を明確にすれば、マネジャーの懸念を払拭できる可能性がある。
SOWを活用する
SOWには「どの部分を外注するのか」「どの作業を内部で行うのか」が具体的に記載される。
開発部門マネジャーと一緒にSOWをレビューすることで、外注の影響範囲を明確にできる。
マネジャーが納得しやすくなるし、合理的な議論の土台を作れる。
他の選択肢の評価
❌ B. プロジェクト・スポンサーから開発部門マネジャーに説明してもらう
いきなりスポンサーを巻き込むと、「エスカレーション」になり、関係が悪化する可能性がある。 まずはプロジェクト・マネジャー自身が直接話し合い、問題を解決するのが基本。
❌ C. UI評価の費用便益分析結果を開発部門マネジャーに示す
費用便益分析（コスト vs. メリット）は重要だが、開発部門マネジャーの懸念（自部門の人員減少）を直接解決するものではない。 まずはSOWをレビューして、「実際にどこまで影響があるのか」を確認するのが先。
❌ D. UI評価の意図を開発部門マネジャーに説明する
「なぜUI評価を行うのか」よりも、「どこまでの範囲を外注するのか」を明確にする方が、マネジャーの懸念を解消できる。 SOWを使わずに説明するだけでは、具体性がなく説得力に欠ける。
結論
📌 まずはSOWを開発部門マネジャーと一緒にレビューし、外注の影響を明確にする（Aが正解）。
📌 その後、必要であれば他のアプローチ（費用便益分析や意図説明）も補助的に活用するのが適切。
Difficult
ある企業が新たなベンチャー事業に乗り出そうとしていますが、その市場での経験がありません。プロジェクト・マネジャーはプロジェクト要件の可視化に手こずっています。
プロジェクト・マネジャーは次に何をすべきでしょうか？
A.プロジェクト憲章を参照する。
B.ベンチャー事業の目標を評価し直す。
C.潜在顧客の意見を求める。
D.フィジビリティスタディを行う。
正解：C 潜在顧客の意見を求める。
プロジェクト・マネジャーは要件の可視化ができずに困っています。要件を理解するには、開発するプロダクトやサービスのユーザーと向き合うのが一番です。潜在顧客は、自分たちのニーズやウォンツに関する貴重な情報を提供してくれるでしょう。そうした情報は、プロジェクト要件の可視化に役立ちます。
選択肢のキーワード潜在顧客の意見を求める（C）
市場での経験がない場合、最も有効な方法。実際のターゲット顧客のニーズを直接把握することで要件を明確にできる。
フィジビリティスタディ（D）
事業の実現可能性を検討する調査。市場調査の一環としては有効だが、具体的な要件の可視化には至らない可能性がある。
他の選択肢の評価
❌ A. プロジェクト憲章を参照する
プロジェクト憲章には、ビジネス目標やプロジェクトの大枠は記載されているが、「市場の詳細な要件」は書かれていないことが多い。 要件の可視化には、より市場に即した情報が必要。
❌ B. ベンチャー事業の目標を評価し直す
目標を再評価することは有益だが、根本的な問題は「市場要件の不明確さ」にある。 市場の声を聞かずに目標を再評価しても、的外れな結論になる可能性がある。
❌ D. フィジビリティスタディを行う
フィジビリティスタディ（実現可能性調査）は、市場調査やコスト分析を含むが、直接的に「顧客の意見を収集するプロセス」ではない。 具体的な顧客ニーズを把握するには、実際に顧客と接触することが最も効果的。
Difficult
あるテクノロジー・プロジェクトの成果物を導入するには、顧客のエンドユーザー・コンピューターのセキュリティソフトを更新してもらわなければなりません。しかし、まだ更新できていないユーザーもいて、プロジェクトの成功を脅かす要因になっています。
プロジェクト・マネジャーはどうすべきでしょうか？
A.しかるべきステークホルダーにこの問題をエスカレーションしてリスクに対処してもらう。
B.リスクの定性分析をして今回の遅延によるプロジェクトへの影響を評価する。
C.すべてのユーザーと面会して更新の重要性について説明する。
D.すべてのエンドユーザー・コンピューターが更新されるまでプロジェクト・スケジュールを延長するために変更要求を提出する。
正解：A しかるべきステークホルダーにこの問題をエスカレーションしてリスクに対処してもらう。
エスカレーション先としては、プロジェクト・スポンサー、顧客、エンドユーザーなどが考えられます。エスカレーション先のステークホルダーと協力してリスクに対処し、エンドユーザー全員が更新できるようにします。
選択肢のキーワード
A. ステークホルダーにエスカレーションしてリスクに対処してもらう
🔑 「エスカレーション」 → 問題の影響範囲が広く、自分の管理範囲外のため、意思決定権を持つステークホルダーに対応を求める。
🔑 「リスクに対処」 → すでに発生しているリスクに対応する行動。
✅ 正解。適切な管理者にエスカレーションすることで、プロジェクトに影響が出ないよう調整できる。
B. リスクの定性分析をしてプロジェクトへの影響を評価する
🔑 「定性分析」 → 影響度を評価するプロセス。
❌ 分析は重要だが、すでに発生しているリスクに対する即時的な対応としては遅い。
対策よりも評価を優先しているため、根本解決にはつながらない。
思考プロセス
問題の本質を理解する
プロジェクトの成功に必要なセキュリティソフト更新が完了していない
更新が進まないとプロジェクトにリスクが生じる
自分の権限の範囲では対処しきれない可能性が高い
どのような対応が適切か？
影響範囲が広いため、自分で対処するよりも適切な権限を持つステークホルダーに対応を求めるべき（エスカレーション）
プロジェクトマネジャーがすべてのエンドユーザーに個別対応するのは現実的ではない
スケジュール延長は最終手段であり、まずは解決策を講じるべき
適切なアクションを選択
正解はA（ステークホルダーにエスカレーションしてリスクに対処してもらう）。
エスカレーションはPMBOKでも「問題の解決が自分の権限外の場合に適切な判断を求める行為」として推奨される手法。
Difficult
チェックリスト、ブレインストーミング、SWOT分析、前提条件分析などのツールを利用するのは、次のうちどれでしょうか？
A.リスク共有
B.リスク特定
C.リスク分析
D.リスク強化
正解：B リスク特定
思考プロセス
問題文のツールの役割を確認する
チェックリスト、ブレインストーミング、SWOT分析、前提条件分析はリスクを発見・特定するための手法。
「リスクを評価する」「リスクを対応する」とは異なるプロセス。
リスクマネジメントのプロセスに当てはめる
「リスクを特定」するプロセスが最初のステップであり、これに該当する選択肢を探す。
**「特定」→「分析」→「対応」→「監視」**の流れを意識する。
選択肢の比較
A（リスク共有）・D（リスク強化） → どちらもリスク対応戦略なので不適切。
C（リスク分析） → 影響評価の段階なので、リスク特定に関連するツールとは異なる。
B（リスク特定） → 問題文のツールすべてが含まれる。
結論
📌 「リスクを特定する」ためのツールが問題文で挙げられているため、正解は B（リスク特定）。
📌 リスクマネジメントの流れを意識し、特定 → 分析 → 対応 の順で考えると正解を導きやすい。
その他の選択肢は誤りです。リスク共有は、リスク対応戦略の1つで、好機を享受できる第三者に情報を共有します。リスク分析は、発生可能性とプロジェクト目的への影響の度合いからリスクの大きさを決定します。リスク強化は、リスク対応戦略の1つで、好機の発生確率や影響を増加させる策を講じます。
Difficult
プロジェクト・マネジャーは、プロジェクトの実行フェーズで新たな人員追加が必要になりました。チームが協力してプロジェクト要件を期日通りに満たすために、プロジェクト・マネジャーは何をすべきでしょうか？
A.ライブラリー・サービスを利用できるようにする。
B.ブレインストーミングを実施する。
C.スキル向上活動を取り入れる。
D.プロジェクト・チームの結束状況を監視する。
正解：C スキル向上活動を取り入れる。
既存のプロジェクト・チームに新たな人員をアサインする必要があるときは、プロジェクト実行フェーズにスキル開発活動を組み込むことが大事です。そうすれば、メンバー全員が自身の任務を効果的に遂行するために必要なスキルや知識を身に付け、プロジェクト要求事項を期日通りに満たすことができるよう後押しすることができます。優れたスキルや能力を備えたチームは、高いパフォーマンスを発揮して、プロジェクト要求事項を期日通りに満たすことができる傾向にあります。スキル開発活動を実施すれば、各自の役割や責任にうまく対応できる力をメンバーに身に付けさせることができます。
選択肢のキーワード
A. ライブラリー・サービスを利用できるようにする。
🔑 「ライブラリー・サービス」 → 情報提供や知識管理のための仕組み。
❌ プロジェクト実行フェーズの人員追加には直接関係しないため不正解。
B. ブレインストーミングを実施する。
🔑 「ブレインストーミング」 → 創造的なアイデアを出すための手法。
❌ 新たな人員追加という課題に対する具体的な解決策にはなりにくい。
C. スキル向上活動を取り入れる。 ✅【正解】
🔑 「スキル向上」 → 追加人員や既存メンバーが効率的に作業を進められるようにする手段。
✅ 不足しているスキルを補完し、プロジェクトの成功につなげるため、最も適切な対応策。
D. プロジェクト・チームの結束状況を監視する。
🔑 「結束状況を監視」 → チームの関係性や協力体制を把握すること。
❌ 重要だが、新たな人員追加が必要な状況で最優先すべき対応ではない。
その他の選択肢は、プロジェクトの実行フェーズにおけるチームの有効性を確保するための最も直接的な方策とは言えないので誤りです。
ライブラリー・サービスを利用できるようにするのが誤りなのは、チームのスキルや能力に直接働きかけるわけでなく、実行フェーズにおける有効性を確保することにならないからです。
ブレインストーミングを実施するのが誤りなのは、スキルを開発したりチームの有効性を確保したりすることに直結しないからです。
チームの結束力を監視するのは、チームの力関係やコラボレーションを評価するためには大事ですが、チームが効果的に機能してプロジェクト要求事項を期日通りに満たすことができるようにするための積極的な方法とは言えません。プロジェクト・マネジャーは、新たな人員がチームに溶け込み、必要なスキルを開発できるよう支援することに集中すべきです。
Expert
プロジェクト・マネジャーは、新しいソフトウェア開発プロジェクトを率いています。製品発表の日が迫っていますが、作業がかなり遅れています。プロジェクト・マネジャーは、チームがやる気を出して遅れを取り戻せるよう支援しましたが、やる気も成果も上がってはいません。
プロジェクト・マネジャーはまず何をすべきでしょうか？
A.プロジェクト・スポンサーと相談してプロジェクト計画を見直す。
B.プロジェクト期日の延期を要求して、引き続きチームを鼓舞する。
C.期日に間に合わせるためにチームに残業を強制する。
D.問題を機能部門マネジャーにエスカレーションして増員を求める。
正解：A プロジェクト・スポンサーと相談してプロジェクト計画を見直す。
プロジェクト・マネジャーは、チームの進捗と課題をプロジェクト・スポンサーにありのまま伝えて、プロジェクト・スポンサーと協力して、現実的で実行可能な計画を立て直す必要があります。
どのように思考して正解を導き出せばよいか
状況を整理する
進捗が遅れている原因: スケジュールがタイトすぎるのか、リソース不足か、技術的課題か？
モチベーションでは解決できない: 精神論ではなく、根本的な計画見直しが必要
PMBOK（プロジェクトマネジメントの原則）に照らし合わせる
スケジュール管理: 遅れを分析し、現実的な対応策を検討する
統合変更管理: 計画を見直し、関係者と調整する
リスク管理: 期日が迫る中で、現実的な達成方法を考える
選択肢の評価
A.プロジェクト・スポンサーと相談してプロジェクト計画を見直す（✔正解）
→ 計画を調整することで現実的な対応策を探る。スコープの縮小、優先順位の変更、リソース配分の最適化などが可能。
B.期日の延期を要求する（❌不正解）
→ まずは計画を見直し、可能な対応策を検討するのが先。いきなり延期を要求するのは早計。
C.残業を強制する（❌不正解）
→ チームの疲労・士気低下を招く。短期的な対応にはなるが、持続可能ではない。
D.増員を求める（❌不正解）
→ まずは計画の見直しが先。増員にはコストと時間がかかるため、即時の解決策にはならない。
Difficult
複数拠点に分散する多数のステークホルダーが関わる複雑な製造プロジェクトが繁忙期を迎えており、プロジェクト・マネジャーは、ステークホルダー全員が最新情報を適時に受け取れるようにする必要があります。
プロジェクト・マネジャーはまず何をすべきでしょうか？
A.効果的なコミュニケーションに関するトレーニングをステークホルダー全員に受講してもらう。
B.ステークホルダー全員とコミュニケーションできる最適なテクノロジーを選定する。
C.ステークホルダー全員に送る定期的な状況報告のスケジュールを決める。
D.情報更新の頻度を上げるようコミュニケーション・マネジメント計画書を修正する。
正解：D 情報更新の頻度を上げるようコミュニケーション・マネジメント計画書を修正する。
プロジェクトが繁忙期に入ったので、プロジェクト・マネジャーは情報更新の頻度を上げるようコミュニケーション・マネジメント計画書を修正します。最新情報に基づき意思決定ができるようステークホルダー全員が適時に情報を受け取れるようにします。
PMBOKの観点から最適な対応を考える
コミュニケーション計画の調整が最優先
頻度や手段の最適化 → 最新の状況に応じて更新が必要
情報共有の遅れや不足を回避 → 計画の変更で情報伝達を迅速化
先に計画の見直しを行い、その後必要な手段（テクノロジー、スケジュール、トレーニングなど）を導入
選択肢に潜むキーワード
A.「効果的なコミュニケーションに関するトレーニング」 → 長期的には有効だが、即効性がない
B.「最適なテクノロジーを選定する」 → 手段は重要だが、先に計画の修正が必要
C.「定期的な状況報告のスケジュールを決める」 → 重要だが、まずは計画の見直しが優先
D.「コミュニケーション・マネジメント計画書を修正する」 → 全体的な情報共有の仕組みを調整する
その他の選択肢は有効とは言えません。トレーニングの実施、コミュニケーションツールの選定、定期報告の設定、いずれも繁忙期のタイミングで行うべきことではありません。
Expert
ステークホルダーが、プロジェクト状況報告の頻度と詳細度を高めてほしいと言っています。また、プロジェクトへの関与度も高めたいと考えているようです。
プロジェクト・マネジャーは、この状況にどう対処すべきでしょうか？
A.このステークホルダーにプロジェクトの最新の状況を報告した上で、詳細な状況報告書をなるべく早く送る。
B.ステークホルダー関与度評価マトリックスを修正して、このステークホルダーの関与度を支援型にする。
C.ステークホルダー・コミュニケーション計画書を更新して、新たな報告要件に関するチームの認識を統一する。
D.ステークホルダーとプロジェクトの関係を定義したステークホルダー・キューブを作成する。
正解：C ステークホルダー・コミュニケーション計画書を更新して、新たな報告要件に関するチームの認識を統一する。
ステークホルダー・コミュニケーション計画書を更新して、チームに新たな報告要件を周知して、ステークホルダーが求める頻度と詳細度で報告できるようにします。
選択肢に潜むキーワード
「プロジェクト状況報告の頻度と詳細度を高めてほしい」 → 情報共有の改善が求められている
「プロジェクトへの関与度も高めたい」 → ステークホルダーのエンゲージメント向上が必要
A.「最新状況を報告し、詳細な状況報告書を送る」 → 単発の対応であり、継続的な仕組みにはならない
B.「ステークホルダー関与度評価マトリックスを修正」 → 関与度の分類はできるが、具体的な行動には結びつかない
C.「ステークホルダー・コミュニケーション計画書を更新」 → 継続的な対応が可能になり、全チームでの認識を統一できる
D.「ステークホルダー・キューブを作成」 → ステークホルダーの特性分析には使えるが、直接の解決策にはならない
Moderate
サプライヤーと顧客は、販促品の提供プロジェクトの契約を進めており8割がた合意しています。予算と納期は決定していますが、顧客としては納品間際にできうる限りスコープを拡大してプロジェクトのビジネス価値を最大化したいと考えています。
プロジェクト・マネジャーはどうすべきでしょうか？
A.合意したスコープで契約書を作成し、必要に応じて補遺により変更する。
B.変更管理プロセスを契約書に記載する。
C.一定数のイテレーションを追加して動的スコープ契約を提案する。
D.要件を満たすために契約書の人員数を増やす。
正解：C 一定数のイテレーションを追加して動的スコープ契約を提案する。
これにより納品間際の追加努力を固定コストで実現できます。
どのように思考して正解を導き出せばよいのか？
問題の本質を理解する
顧客は納品間際にスコープを拡大したいと考えている。
しかし、予算と納期は既に決定済み。
固定スコープではなく、柔軟にスコープを調整できる仕組みが求められる。
各選択肢を評価する
Aは、スコープを固定する契約を前提としているため、顧客のニーズに合わない。
Bは変更管理プロセスを明示するが、動的なスコープ対応には不十分。
Cはアジャイル的なアプローチを採用し、一定数のイテレーションを追加してスコープの柔軟性を確保できるため適切。
Dは人員増加で対応しようとしているが、契約そのもののスコープ変更に対応できていない。
最も適切な解決策を選ぶ
顧客の意図を考慮し、スコープ変更が可能な仕組みを導入することが求められる。
C（動的スコープ契約の提案）は、イテレーションを追加して顧客の要求に対応する柔軟な契約形態となるため、最適な選択肢。
顧客が「柔軟にスコープを変更したい」なら C
「スコープは基本的に確定済みだが、一部の変更はあり得る」なら A
Difficult
