PMI Study Hall 175_02_02 Flashcards
プロジェクト・チームは、全14回のスプリントの13回目を実施中です。バックログには最終リリースに入る予定の画期的なフィーチャーが含まれています。プロダクト・オーナーは、競合企業がこのフィーチャーと同様の機能を持つ新製品を発売するという情報を得て、このフィーチャーを直近のリリースに組み込むことを要求しました。
プロジェクト・マネジャーはどうすべきでしょうか？
A.開発チームとのレビュー会議を設定して必要な作業量を把握する。
B.この変更についてプロダクト・オーナーやステークホルダーと話し合って今後の計画を立てる。
C.必要な評価を行った上で変更管理委員会（CCB）に変更要求を提起する。
D.このフィーチャーは最終リリースで追加する予定だとプロダクト・オーナーに伝える。
正解：B この変更についてプロダクト・オーナーやステークホルダーと話し合って今後の計画を立てる。
プロダクト・オーナーはプロジェクト後期に、スコープ、スケジュール、資源に影響を及ぼす可能性のある大きな変更を要求しています。プロジェクト・マネジャーは、プロダクト・オーナーやステークホルダーと話し合って影響を分析した上で今後の計画を立てるべきです。プロジェクトの戦略的ゴールや優先順位に関わる意思決定には主要ステークホルダーの意見を聞く必要があります。こうした協働的なアプローチは、アジャイル方法論の要です。
その他の選択肢は誤りです。
開発チームとのレビューは、今すぐ行うことではありません。まずはプロジェクトの主要な意思決定者を巻き込んで、この変更の実現可能性と影響について話し合うべきです。
アジャイル・プロジェクトにはCCBは存在せず、意思決定はプロダクト・オーナーとチームとステークホルダーが協働で行います。
変更による影響を分析せずに否定するのは正しいアプローチとは言えません。アジャイルでは、プロジェクトの末期でも変更を受け入れて顧客価値を最大化します。最終リリースまで変更を先送りするかどうかは、変更の影響を分析した上で関係者全員で判断すべきです。
Expert
プロジェクトのスコープにある装置を追加すると販売上のメリットがありそうです。ただし、この装置は未だ開発中でプロジェクトの期日までに用意できません。ステアリング・コミィティのメンバーの1人はこの装置の追加を希望しています。
プロジェクト・マネジャーはどうすべきでしょうか？
A.装置の追加は販売チームのためになるのでスコープ変更要求を作成する。
B.プロジェクト期限への影響とビジネス・ケースに基づいて追加しない理由を示す。
C.ステアリング・コミィティでアンケートを行い各メンバーの要求を評価して合意に基づく意思決定を行う。
D.ステアリング・コミィティのメンバーにこの問題を伝えて納得してもらうようプロジェクト・スポンサーに依頼する。
正解：C ステアリング・コミィティでアンケートを行い各メンバーの要求を評価して合意に基づく意思決定を行う。
関係者全員の意見を聞いてプロジェクトを進めるべきです。ステアリング・コミィティは、方向性を示してチームを支援し、チームの権限外の意思決定を行います。プロジェクトはステアリング・コミィティの監督下にあるので、ステアリング・コミィティが合意しないと先に進めません。ステアリング・コミィティでアンケートを取ることで、装置の追加による影響や対立を見つけて不安を解消できます。
その他の選択肢は誤りです。合意なしにスコープの変更要求を出したり、追加しない理由を示したり、スポンサーにエスカレーションするのは時期尚早です。
Difficult
直近のスプリント・レビュー会議で顧客が、プロジェクトで提供すべき5つのモジュールのうち2つを数週間後までに実装する必要があると発表しました。
プロジェクト・マネジャーはどうすべきでしょうか？
A.ブレインストーミング会議を行う。
B.ノミナル・グループ技法を使う。
C.リリース計画会議を行う。
D.プロトタイプを作って設計を詳細化する。
正解：C リリース計画会議を行う。
リリース計画会議は、成果物のインクリメントやリリースのおおまかな予定を立てる会議です。この場合、2つのモジュールを先にリリースするために必要な作業の優先順位を決めてデリバリー計画を策定します。
ブレインストーミング、ノミナル・グループ技法、プロトタイプの活用は、状況によっては有効ですが、今は顧客の要求である特定モジュールの優先的デリバリーに必要な計画を立てることが大事です。
Difficult
プロジェクトの目的に疑問を抱いているステークホルダーが、最終成果物に影響を及ぼす可能性のある新しいプロセスを評価するためにプロジェクトの途中で一時中断したいと言い出しました。
プロジェクト・マネジャーが真っ先に取るべき行動の1つはどれでしょうか？
A.権力と関心度のグリッドを使ってこのステークホルダーのプロジェクトへの影響力を明らかにする。
B.プロジェクト・スポンサーと相談して今後の方策と新しいプロセス候補を決める。
C.現在のプロジェクトの成果物を完成させるためにプロジェクトへの変更をすべて凍結する。
D.このステークホルダーと受入基準を確認して品質レベルが適切かチェックする。
正解：A 権力と関心度のグリッドを使ってこのステークホルダーのプロジェクトへの影響力を明らかにする。
権力と関心度のグリッドは、「プロジェクトへの影響力」と「プロジェクトから受ける影響量」に応じてステークホルダーを分類するツールです。「権力」には、プロジェクトの成果をはじめ計画や変更の決定権限などが含まれます。「関心度」が高いステークホルダーは、プロジェクト・オーナーはもちろんですが、プロジェクトの成果物のユーザーや、そのプロジェクトと資源を取り合っている別のプロジェクトや部署の人が含まれます。プロジェクト・マネジャーは、当該ステークホルダーの権力と関心度に応じて、相手の懸念に対応できます。
その他の選択肢は誤りです。いずれも、ステークホルダーの権力と関心度を評価した上で行うことです。
Difficult
プロジェクト・マネジャーは、大規模なビジネス・トランスフォーメーション・プロジェクトに取り組んでいます。このプロジェクトには変革マネジメントが必要なため、プロジェクト・マネジャーはコッター・モデルを採用することにしました。まずは危機意識を高め、変革を推進するチームを結成しました。
プロジェクト・マネジャーは他に何をすべきでしょうか？（3つ選んでください）
A.ビジョンと戦略を策定する。
B.短い間隔で頻繁にデリバリーする。
C.ビジョンを周知する。
D.ビジネス担当者と開発者を連携させる。
E.短期的な成果を上げる。
正解：A、C、E ビジョンと戦略を策定する。ビジョンを絶えずコミュニケートする。短期的な成果を上げる。
コッター・モデルは以下の8つのステップからなります。
危機意識を高める
変革推進チームを作る
変革ビジョンを策定する
ビジョンを周知する
自発を促す
短期的な成果を出す
変革を強化する
変革を定着させる
その他の選択肢は誤りです。頻繁なデリバリーやビジネス担当者と開発者の連携は、アジャイルのプラクティスです。コッター・モデルは、上記8つのステップで変革を実現するものです。
Expert
プロジェクトの実行中に主要なステークホルダーの1人が、承認権限を持つ新たなチーム・メンバーと入れ替わりました。この新メンバーは、プロジェクトの成果物が設計に沿っていないので承認できないと主張しました。ところが数週間後、この新メンバーが実行フェーズでの変更を知らされていなかったことが判明しました。
このミスコミュニケーションを防ぐために、プロジェクト・マネジャーは何をすべきだったでしょうか？
A.実行フェーズの開始前にスポンサーとミーティングを行う。
B.ステークホルダー登録簿を更新して新メンバーの情報を追加する。
C.前任のステークホルダーに離脱前に新メンバーとミーティングを行うよう求める。
D.実行フェーズでプロジェクト憲章を更新してすべての変更を反映させる。
正解：B ステークホルダー登録簿を更新して新メンバーの情報を追加する。
ステークホルダー登録簿を更新して新メンバーの情報を追加すべきでした。そうすればプロジェクト・マネジャーは、プロジェクトに関係するすべてのステークホルダーを把握し、新メンバーと定期的にコミュニケーションを取ることができたはずです。
その他の選択肢は、有効性に欠けるか的外れです。実行フェーズの開始前にスポンサーとミーティングを行うのはグッドプラクティスですが、この事例で生じたミスコミュニケーションの防止策としては十分ではありません。
離脱前に新メンバーとミーティングを行うよう前任のステークホルダーに求めるのもグッドプラクティスですが、それができない場合もあります。例えば、前任のステークホルダーが突然退職した場合には、ミーティングを行う時間はなかったかもしれません。実行フェーズでプロジェクト憲章を更新してすべての変更を反映させるのが誤りなのは、プロジェクト憲章はプロジェクトを認可してプロジェクトのスコープ、ゴール、目標、成功基準を定義する文書だからです。実行フェーズでは通常、プロジェクト憲章を更新することはありません。
Difficult
ある企業では、予測型からアジャイル型のプロジェクトマネジメント・アプローチへの移行を進めています。プロジェクト・マネジャーはチームが生産性向上案を持っていることに気づきました。
このアイデアを活用するにはどうすればいいでしょうか？
A.レトロスペクティブを議論と学習の場として利用する。
B.イテレーション計画会議で議論して新しい働き方を採用する。
C.チームのトレーニングとメンタリングに関するガイドラインを作成して共有する。
D.プロダクト・オーナーにアジャイルへの移行を促進してもらう。
正解：A レトロスペクティブを議論と学習の場として利用する。
レトロスペクティブが 「スプリントの後に実施する」 ことは一般的ですが、必ずしもスプリント終了後のみで行う必要はありません。
レトロスペクティブはスプリント終了後に限定されない理由
カンバンやハイブリッド環境では、スプリントの概念がないこともある
スクラムではスプリントごとにレトロスペクティブを実施するのが基本ですが、カンバンやハイブリッド型のプロジェクトでは、一定の期間ごとや、特定のイベントごとに実施することもある。
問題文ではスプリントについての言及がないため、カンバンやハイブリッド環境でのアプローチが想定されている可能性もある。
アジャイルの「継続的な改善」の考え方に合致
アジャイルでは、「常に改善を続ける」ことが求められる。
そのため、レトロスペクティブを スプリント単位に限定せず、適切なタイミングで行う ことは許容される。
レトロスペクティブは「振り返り」のための手法であり、スプリントに限定されるものではない
アジャイル環境では、チームの成長のためにレトロスペクティブを柔軟に活用することが推奨されている。
たとえば、新しい働き方を試す前後でミニ・レトロスペクティブを実施することも可能。
今回の問題文の解釈
「スプリント」についての言及がないが、「生産性向上案を活用するにはどうすればいいか」が問われている。 アジャイルでは、改善のためにレトロスペクティブを活用するのが一般的。 「改善のためにチームで話し合う場」 という観点では、レトロスペクティブが適切。
もしスプリントがない環境であれば？
例えば、カンバン では「継続的な改善」が重視され、定期的な振り返りの場を設けることが一般的。 「レトロスペクティブ」＝「スプリント終了後のもの」と固定的に考える必要はなく、適切なタイミングで実施する柔軟性を持つべき。
レトロスペクティブ会議は、アジャイル・プロジェクトマネジメントの継続的改善ツールです。チームが直近のスプリントを振り返り、改善点を見つけて次のスプリントでの取り組み案を計画します。レトロスペクティブで、新たなアジャイル環境におけるチームの生産性向上案を収集し、その実施計画を立て、実施できます。
その他の選択肢は妥当ではありません。イテレーション計画会議は、次のイテレーションで実施する作業計画を行う場であり、新しい働き方に関する議論の場としては適切とは言えません。チームのトレーニングとメンタリングに関するガイドラインの作成をしてもチームのアイデアを活用できません。プロダクト・オーナーの責任は、プロダクト・バックログを優先順位付けして、チームが重要な要求から取り組めるようにすることです。アジャイルへの移行促進はプロダクト・オーナーの仕事ではありません。また、移行を促進しても、チームが新たなアジャイル環境にあった働き方ができるようになるとは限りません。
Expert
プロダクトのデモンストレーションでステークホルダーが期待はずれだと主張しています。プロジェクト・マネジャーはこのステークホルダーの意見を評価するためにどの作成物（アーティファクト）を使用すべきでしょうか？
A.最小実行可能プロダクト（MVP）の記述
B.Doneの定義（DoD）
C.Readyの定義（DoR）
D.ユーザー・ストーリーの受入基準
正解：D ユーザー・ストーリーの受入基準
プロジェクト・マネジャーは「ユーザー・ストーリーの受入基準」を使ってステークホルダーの意見を評価すべきです。これは、プロダクトが完成しステークホルダーに受け入れられる状態かを判定するための具体的な要件です。プロダクトが備えるべきフィーチャーや機能を簡潔に記述したもので、一般的にはユーザー・ストーリーの中で定義します。
どのように思考してDが正解と導き出せるか
「期待はずれ」＝ ステークホルダーの期待と実際の成果物にギャップがある
期待とは何か？ → 受入基準が定義している
何と比較すればいいか？ → 実装された機能の動作
選択肢のうち、期待値と実際の成果を比較できるのは何か？
MVP：製品の最小限の形を示すが、期待値と比較するものではない ❌
DoD：品質基準であり、ステークホルダーの期待を満たしているかどうかの評価には使えない ❌
DoR：開発前の基準であり、デモの評価には向かない ❌
受入基準（D）：機能の期待される動作を明確に定義しているため、比較対象として最適 ✅
Expert
プロジェクト・マネジャーはマトリックス組織で働いています。組織再編を受けて、数人のプロジェクト要員が別のプロジェクトに異動することになり、プロジェクトの成功に必要な人員を確保できなくなりました。
プロジェクト・マネジャーはどうすべきでしょうか？
A.人員の異動を拒否する。
B.コミュニケーション・マネジメント計画書をレビューする。
C.資源の配置活用計画をレビューする。
D.機能部門マネジャーと一緒に人員ニーズをレビューする。
正解：D 機能部門マネジャーと一緒に人員ニーズをレビューする。
マトリックス環境では、プロジェクト要員が複数のプロジェクトをかけもちするのが一般的です。プロジェクト要員は機能部門マネジャーの指揮下にあるので、プロジェクト・マネジャーは機能部門マネジャーと人員ニーズについて相談します。異動による影響について説明した上で、機能部門マネジャーと協力してその影響を最小限に抑えるようにします。
どのように思考してDが正解と導き出せるか
問題の本質を特定
プロジェクトに必要な人員が不足することが最大の問題。
マトリックス組織では、プロジェクト・マネジャーに人員の決定権がないため、機能部門マネジャーとの協力が不可欠。
選択肢の評価
A（拒否する） → 組織的な異動を拒否するのは非現実的で不適切 ❌
B（コミュニケーション計画を見る） → リソース問題の解決には直接役立たない ❌
C（資源活用計画をレビュー） → 重要だが、まずはリソースの確保が先決 ❌ 資源の配置活用計画（Resource Management Plan）は、どのリソースをどのように活用するかを定めるもの。 リソース不足が生じた際に、代替策（リソースの再割り当て、外部委託など）を検討する際に役立つ。 重要な手順ではあるが、異動自体をコントロールするのには不十分。
D（機能部門マネジャーと協議） → 人員確保のための現実的なアプローチで最適解 ✅
結論
マトリックス組織においては、プロジェクト・マネジャーが独自に人員をコントロールする権限は限られているため、機能部門マネジャーと協力して適切なリソースを確保することが最優先事項となる。 よって、「D. 機能部門マネジャーと一緒に人員ニーズをレビューする」 が正解。
Difficult
Question
プロジェクト・マネジャーは、プロジェクトの開始時、プロダクト・オーナーおよびビジネス・アナリストと一緒に要件収集プロセスに取り組み、要求事項、フィーチャー、プロダクト・バックログのリストを作成しました。アジャイル・プロジェクトの円滑なデリバリーのために、すべてのユーザー・ストーリーの適切なサイズ、適切な記述を保証するどの要素を考慮すべきでしょうか？（2つ選んでください）
A.独立、交渉可能、見積り可能
B.一意、適用可能、再現可能
C.分割可能、適切、重要
D.簡潔、詳細、実行可能
E.価値、小さい、テスト可能
正解：A、E 独立、交渉可能、見積り可能、価値、小さい、テスト可能
良いユーザー・ストーリーの条件は「INVEST」です。「INVEST」は、ユーザー・ストーリーに必要な以下の要素の頭文字です。
選択肢の分析
A.「独立、交渉可能、見積り可能」（✅正解）
INVEST原則（アジャイル開発のユーザー・ストーリーの品質基準）に基づいている。
Independent（独立）: ストーリーは他のストーリーと依存関係が少ないほど管理しやすい。
Negotiable（交渉可能）: ユーザー・ストーリーは固定された要件ではなく、柔軟に対応できる必要がある。
Estimable（見積り可能）: ストーリーが適切なサイズでなければ、開発の見積もりが難しくなる。
B.「一意、適用可能、再現可能」（❌不正解）
「一意」 → 一意性は重要だが、ユーザー・ストーリーの管理とは直接関連しない。
「適用可能」 → 曖昧な表現であり、ユーザー・ストーリーの品質基準ではない。
「再現可能」 → ユーザー・ストーリーの目的とは異なり、主にテストやバグ管理に関係する。
C.「分割可能、適切、重要」（❌不正解）
「分割可能」 は適切だが、INVEST原則の一部ではない。
「適切、重要」 → 抽象的すぎて、アジャイルのユーザー・ストーリー基準として明確ではない。
D.「簡潔、詳細、実行可能」（❌不正解）
「簡潔」 は有用だが、詳細と両立しない場合がある。
「詳細」 はアジャイルのユーザー・ストーリーにおいては不要（ストーリーはシンプルであるべき）。
「実行可能」 は要件として重要だが、ユーザー・ストーリーの品質基準とは異なる。
E.「価値、小さい、テスト可能」（✅正解）
「価値」（Valuable）: ユーザー・ストーリーは顧客やビジネスに価値を提供するものでなければならない。
「小さい」（Small）: 小さく分割することでスプリント内で完了できる。
「テスト可能」（Testable）: 受入基準が明確で、テスト可能である必要がある。
独立（Independent）：他のストーリーに依存しすぎない
交渉可能（Negotiable）：決まりきった契約ではなく対話によってより良い案を採択できる
価値（Valuable）：価値が明確に認められる
見積り可能（Estimatable）：見積りができる程度に具体的で適切に優先順位も付けられる
小さい（Small）：スプリント（たとえば、2週間のイテレーション）に入り切れるだけの小さい作業
テスト可能（Testable）：「Doneの定義」により完了を判定できる
Expert
プロジェクト・マネジャーは、設計フェーズで適応型ツールを使うと有効だと気づきました。この有効性は、組織内の過去プロジェクトで実証済みです。
プロジェクト・マネジャーはまず何をすべきでしょうか？
A.プロジェクトで採用する前に適応型ツールと作成物に関するチームの能力を確認する。
B.適応型プロジェクトに精通したメンバーの追加をプロジェクト・スポンサーに依頼する。
C.設計フェーズを中断し、追加コストをかけて反復型設計ができる外部要員を探す。
D.適応型ツールと作成物の情報をプロジェクト文書に追加し初回の反復型セッションの計画を立てる。
正解：A プロジェクトで採用する前に適応型ツールと作成物に関するチームの能力を確認する。
どのように思考してAが正解と導き出せるか
「プロジェクトで採用する前に」 というフレーズが示すように、まず準備が必要。 適応型ツールが有効であると証明されていても、チームのスキルセットが適応可能であるかを確認する必要がある。 「まず何をすべきか」 → チームの能力を確認し、適応可能であれば導入を進める。適応不可能なら追加の対策を検討する。 他の選択肢は、いきなり外部リソースを投入したり、プロジェクトを中断するなど、非現実的またはリスクの高い対応を示している。
その他の選択肢は誤りです。まずはチームが適応型ツールに対応できるかどうか確認しなければ、プロジェクト・マネジャーはムダな犠牲を払うことになります。チームがプロジェクトでの責任を果たすために必要なトレーニングを受けられるようにするのもプロジェクト・マネジャーの仕事です。
Moderate
製品開発プロジェクトで、設計上の問題が生じたのをきっかけに、チームは設計フェーズのアプローチを予測型から反復型へ切り替えました。
アプローチの移行を円滑化するために、プロジェクト・マネジャーは何をすべきでしょうか？
A.今後の複数イテレーションの計画を立てるためにチームとのワークショップを企画する。
B.チームと協力してチームの作業場所と製品の作成物（アーティファクト）を決める。
C.プロダクト・マネジャーと面談して今後のユーザー・ストーリーを分析する。
D.プロダクト・マネジャーと協力してイテレーションの回数を決める。
正解：A 今後の複数イテレーションの計画を立てるためにチームとのワークショップを企画する。
予測型から反復型のアプローチに移行する意義をチームが理解することが大事です。今後の進め方についてチームと一緒に議論することで移行を円滑化できるでしょう。
どのように思考してAが正解と導き出せるか
アプローチの移行を円滑化することが目的 → まず、チーム全体で新しい作業プロセスに適応するための準備が必要。 予測型から反復型への移行 → これまでの計画通りに進めるのではなく、適応型のアプローチに切り替え、短期間で試行錯誤できる体制を整える。 ワークショップの開催が最優先 → チームが新しいワークフローを理解し、適応できるようにするための最善の手段。 他の選択肢は、移行後の詳細な作業を想定しており、移行プロセスの支援には直接つながらない。
Difficult
プロジェクト・マネジャーは、自社でもプロジェクト・マネジャーを擁する顧客の複雑なプロジェクトを担当しています。顧客のプロジェクト・マネジャーはこのプロジェクトの意思決定者ですが財務権限はなく、予算に関する決定は都度上司の承認を得る必要があります。そのせいで、プロジェクトの資源マネジメント、コスト、所要期間に多大な影響が及んでいます。
プロジェクト・マネジャーは、この問題をどうすれば解決できるでしょうか？
A.プロジェクトの四半期ごとの状況報告でこの問題を提起する。
B.この問題を教訓報告書に盛り込む。
C.この問題をプロジェクト・ステアリング・コミィティにエスカレーションする。
D.この問題について顧客のプロジェクト・マネジャーと話し合う。
正解：C この問題をプロジェクト・ステアリング・コミィティにエスカレーションする。
ステアリング・コミィティは、上位ステークホルダーや専門家から構成される諮問機関です。予算、新たな取り組み、社内ポリシー、マーケティング戦略、プロジェクトマネジメントに関する懸念や問題といった、企業やプロジェクトの多様な課題について提言を行います。意思決定権限に関する問題に対応できるのはステアリング・コミィティだけです。この問題は、プロジェクト・チームが自力で解決できないので、エスカレーションするのが妥当でしょう。
どのように思考してCが正解と導き出せるか
問題の本質を理解する
個別の対処（話し合い）では解決できない、組織的な問題である。
財務権限がないことによる遅延が、プロジェクト全体に影響を及ぼしている。
問題の影響範囲を考慮する
「多大な影響がある」と明記されているため、解決策は即時性と影響力が求められる。
四半期報告や教訓報告では、解決が遅れる可能性が高い。
適切な意思決定レベルでの対応が必要
顧客のプロジェクト・マネジャーには財務権限がない → 話し合いだけでは根本解決にならない。
ステアリング・コミィティは、財務を含めた組織的な意思決定を行う機関であり、適切なレベルでの対応が可能。
Expert
プロジェクト・マネジャーがITプロジェクトにアサインされました。現在、立ち上げフェーズで、ベンダーと組織の間で使用する技術インフラに互換性がないことが判明しました。
この問題を解決するためにプロジェクト・マネジャーが踏むべき最初のステップはどれでしょうか？
A.代替案がないか調べる。
B.この課題を技術インフラ・チームにエスカレーションする。
C.教訓データベースをチェックする。
D.この課題についてプロジェクト・スポンサーに相談する。
正解：C 教訓データベースをチェックする。
教訓登録簿を使って過去プロジェクトの教訓で立ち上げ時に役立つものがないか検索します。同じような互換性の問題が組織内の別プロジェクトで以前にも発生していないかチェックします。
その他の選択肢は誤りです。
代替案を考えるのは、教訓を検索した次のステップです。教訓データベースには、以前に検討したり実施した代替案に関する情報が含まれている可能性があります。それらの情報を利用すれば効果のない代替案を避け時間を節約できるかもしれません。
プロジェクト・マネジャーは、技術インフラ・チームにエスカレーションする前にまず自身でその課題を評価する必要があります。
技術的な課題についてプロジェクト・スポンサーに相談することは最初の選択肢にはなりません。これは、プロジェクト・スポンサーが技術的な専門知識を持っている場合にも当てはまります。
Expert
ビジネス・マネジャーとプロダクト・オーナーは、リリース期間を短縮して競合他社に対抗するためにプロダクト・バックログへの変更をもっと柔軟に取り込んでほしいと言っています。
プロジェクト・マネジャーはどうすべきでしょうか？
A.プロダクト・オーナーがビジネス・ゴールに沿ってバックログ項目の優先順位を変更できるようコーチングする。
B.前提条件ログとプロジェクトマネジメント計画書を見て変更の可能性を見つける。
C.包括的な変更管理プロセスを作成して変更管理委員会（CCB）を準備する。
D.製品出荷を早めるために主要なステークホルダー全員に修正権限を与える。
正解：A プロダクト・オーナーがビジネス・ゴールに沿ってバックログ項目の優先順位を変更できるようコーチングする。
バックログ項目の優先順位付けはプロダクト・オーナーの役目です。競合他社が新製品を頻繁にリリースしている場合、プロダクト・オーナーが優先順位を見直してフィーチャーのリリース順を変更する場合があります。
どのように思考してAが正解と導き出せるか
問題の本質を理解する
ビジネスの要請に応じて、プロダクト・バックログの優先順位を柔軟に変更することが求められている。
アジャイル開発では、プロダクト・オーナーがバックログを管理し、ビジネス価値の最大化を図る役割を担う。
アジャイルの原則に沿って対応する
アジャイルでは、バックログの優先順位を継続的に調整し、価値を最大化するのが基本。
POがこの役割を適切に果たせるようにコーチングすることが、最も自然な解決策となる。
不要なプロセスの導入は避ける
変更管理委員会（CCB）などの厳格な管理手法はアジャイルには適さない。
前提条件ログや計画書の確認も、アジャイルの俊敏性を損なう可能性がある。
関係者の役割を明確にする
バックログの変更権限を全員に与えると管理が混乱するため、POの適切なバックログ管理を促進するのが最善策。
Difficult
プロジェクト・マネジャーは、遅延と予算超過が生じているプロジェクトにアサインされました。このプロジェクトでは、スコープの重要部分に関してアジャイル・イテレーションと予測型の統合アプローチを採用しています。プロジェクト・マネジャーは、プロジェクトの評価時に、チームが失敗を恐れて十分な責任を果たせていないのに個人の成果を主張していることに気づきました。
プロジェクト・マネジャーは、どのようにして生産性を改善すべきでしょうか？
A.各メンバーのパフォーマンス・マネジメント計画を立てて実績をチームと共有する。
B.チームで共通のゴールを設定して成果を祝い、チームに報酬を与えることでコラボレーションを可能にする。
C.次のマイルストーンを伝えて個人のパフォーマンスと実績を詳しく追跡する。
D.チームがゴール達成の重要性を理解するために数人のメンバー交代の承認を求める。
正解：B チームで共通のゴールを設定して成果を祝い、チームに報酬を与えることでコラボレーションを可能にする。
プロジェクト・マネジャーは、チームで共通のゴールや報酬を与えることでコラボレーション環境を生み出し、個人レベルのサイロ化を解消する必要があります。
選択肢の分析
A.「各メンバーのパフォーマンス・マネジメント計画を立てて実績をチームと共有する。」（❌ 不正解）
個人単位の管理を強化すると、チームワークの問題は解決しない可能性が高い。
すでに個人の成果を主張している状況で、さらに個人の実績を強調するのは逆効果。
B.「チームで共通のゴールを設定して成果を祝い、チームに報酬を与えることでコラボレーションを可能にする。」（✅ 正解）
「共通のゴール」→ チーム全体で成果を共有し、責任を果たす文化を作る。
「成果を祝い、チームに報酬を与える」→ チームのモチベーションを高め、協力意識を促進する。
心理的安全性を高めることで、失敗を恐れずに積極的に行動できる環境を作る。
C.「次のマイルストーンを伝えて個人のパフォーマンスと実績を詳しく追跡する。」（❌ 不正解）
個人のパフォーマンスを強調するのは、すでに問題になっている個人主義を助長する可能性がある。
チームの一体感を高めるよりも、個人の競争を促してしまう。
D.「チームがゴール達成の重要性を理解するために数人のメンバー交代の承認を求める。」（❌ 不正解）
メンバー交代は最終手段であり、問題の本質を解決する方法ではない。
まずはチームの意識改革や協力促進を試すべき。
Expert
プロジェクト実施中にソフトウェア開発チームは、品質要件を満たしていないフィーチャーがあることに気づきました。この問題解決を任されたメンバーは、要件の曖昧さが原因だと不満をもらしました。また、ずさんなテストのせいだと主張するメンバーもおり、テスターはコーディングの質の低さを非難しています。
プロジェクト・マネジャーはどうすべきでしょうか？
A.チームがレトロスペクティブで品質問題の根本原因を特定できるようサポートする。
B.混乱がチームのモチベーションに影響を及ぼしているので、最も不満を抱えているメンバーをチームから外す。
C.開発ライフサイクルの各段階で品質レビューを実施して、品質上の問題を特定する。
D.この問題について経営陣と話し合い、品質改善に向けた解決策の候補を特定する。
正解：A チームがレトロスペクティブで品質問題の根本原因を特定できるようサポートする。
コンフリクトを解決する責任を一番に担うのはプロジェクト・チームですが、プロジェクト・マネジャーはそのためのファシリテーションを必要に応じて行うことができます。レトロスペクティブ・ミーティングは、チームが自分たちの作業方法をレビューして、プロセスや効率の改善につながる変更を提案する場です。パフォーマンスやチームの結束に対する脅威を特定して改善を図るために利用されることもあります。ファシリテーションは、チームが解決策に関する合意形成やコンフリクトの解消、意思決定を行うための助けになります。
その他の選択肢は、正しい選択肢よりもチーム内のコラボレーションや問題解決を促す効果に劣るので、根底にある問題への対処法としては必ずしも効果的とは言えません。
A.「チームがレトロスペクティブで品質問題の根本原因を特定できるようサポートする。」（✅ 正解）
「レトロスペクティブ」 → アジャイルでは、スプリントごとに振り返りを行い、問題の根本原因を特定し、次のスプリントに活かす。 「根本原因を特定できるようサポート」 → チーム自身が問題を解決する能力を向上させることが、アジャイルマネジメントの基本方針。 この選択肢は、チームの自己組織化と継続的改善の促進に適している。
C.「開発ライフサイクルの各段階で品質レビューを実施して、品質上の問題を特定する。」（❌ 不正解）
「開発ライフサイクルの各段階で品質レビューを実施」 → これはウォーターフォール型の手法に近い。 アジャイルでは、継続的なフィードバックと振り返りを通じて品質を改善していくのが基本。 品質レビューは重要だが、現時点で発生しているチーム内の対立を解決する手段にはならない。
Difficult
アジャイル・プロジェクトを担当するプロジェクト・マネジャーは、多くのステークホルダーがイテレーション計画会議とレビュー会議を欠席していることに気づきました。一部のステークホルダーは、これらの会議の意義が分からないのであえて欠席していると認めています。こうしたステークホルダーの関与不足のためにプロジェクトが遅れる可能性があります。
この問題に対処するために、プロジェクト・マネジャーはまず何をすべきでしょうか？
A.コミュニケーション・マネジメント計画書をレビューして更新する。
B.差異を特定してステークホルダーに反復型アプローチに関するメンタリングを行う。
C.イテレーション・レビューを録画してステークホルダーと共有する。
D.RACIマトリックスを作成してステークホルダー向けのトレーニング計画を立てる。
正解：B 差異を特定してステークホルダーに反復型アプローチに関するメンタリングを行う。
ステークホルダーは、イテレーション計画会議やレビュー会議の意義が分からないと認めています。反復型アプローチや会議の重要性を理解していない可能性があるので、プロジェクト・マネジャーは、その差異を特定した上で、メンタリングで対処すべきです。スケジュール遅延の恐れがあるので、先手を打ってステークホルダーの参加を促し状況を改善します。
どのように思考してBが正解と導き出せるか
問題の本質を理解する
ステークホルダーがイテレーション会議の重要性を理解していないため、欠席している。
このままではプロジェクトの遅延につながるリスクがある。
適切なアプローチを考える
ステークホルダーが「アジャイルの反復型アプローチの価値を理解する」ことが最優先。
直接的なコミュニケーションを通じて「なぜこの会議が重要なのか」を説明し、参加する意義を理解してもらう必要がある。
したがって、「ステークホルダーにメンタリングを行う」ことが最も有効。
他の選択肢を排除する
A: 計画書の更新だけでは、ステークホルダーの認識を変えることができない。
C: 録画を共有しても、リアルタイムの関与を促せない。
D: RACIマトリックスの作成は役割の明確化には有効だが、参加意欲を高める施策としては不十分。
Expert
コロケーションしているプロジェクト・チームがコミュニケーションとコラボレーションの問題に直面しています。チームには早番と遅番のメンバーがおり、週次のミーティングに参加できないメンバーがいます。
チームがすべてのミーティングに出席できるようにするために、プロジェクト・マネジャーはどうすべきでしょうか？
A.同じ時間帯に勤務するようメンバーに促す。
B.欠席者と別ミーティングを持つ。
C.全員が見える場所に情報ラジエーターを掲示する。
D.全員が出社しているコアタイムにチーム・ミーティングを設定する。
正解：D 全員が出社しているコアタイムにチーム・ミーティングを設定する。
これにより全員が出席して同じメッセージを受け取れるようにします。
C.「全員が見える場所に情報ラジエーターを掲示する。」（❌ 不正解）
情報ラジエーター（タスクボード、カンバンなど）は進捗を可視化するのに役立つが、リアルタイムの議論や意思決定の代替にはならない。 ミーティングへの参加を補完するツールではあるが、メンバーが直接コミュニケーションを取れるようにする方が重要。 根本的な問題（チーム全員が同じ時間に会議に出られない）を解決するものではない。
D.「全員が出社しているコアタイムにチーム・ミーティングを設定する。」（✅ 正解）
**「コアタイム」**は、早番・遅番のメンバーが共通して勤務している時間帯を指す。 この時間帯にミーティングを設定することで、全員が参加できる機会を確保できる。 チーム全体のコミュニケーションとコラボレーションを促進する、最も合理的な選択肢。 時間帯を調整することで、全員のスケジュールを調整し、効果的な意思決定を行うことができる。
Moderate
プロジェクト・マネジャーは新しいアジャイル・チームの形成段階において、チームがさまざまな問題を抱えていることに気づきました。チームはイテレーションのコミットメントを果たす能力を備えていない上に、メンバー間のコンフリクトを抱えています。
プロジェクト・マネジャーは次に何をすべきでしょうか？
A.経営陣を巻き込んでコンフリクトの解決を支援してもらう。
B.コミットメントを果たせない見込みだと経営陣に報告する。
C.レトロスペクティブで問題を提起して解決策を提案する。
D.チーム全体と各メンバーの両方にコーチングを行う。
正解：D チーム全体と各メンバーの両方にコーチングを行う。
チーム全体と各メンバーの両方にコーチングを行い、チームのパフォーマンスを徐々に改善します。
その他の選択肢は誤りです。経営陣を巻き込んでも現状の問題解決にはなりません。コミットメントを果たせないことを経営陣に報告することはプロジェクト・マネジャーの務めですが、アジャイル・チームでは報告よりコーチングを優先すべきです。レトロスペクティブまで待っていては手遅れになります。
Difficult
アジャイル・プロジェクト・チームは、現在のイテレーションのタスクをまだ完了していません。プロジェクト・スポンサーは、ミーティングでタスク完了の最終期日をチームに告げました。
プロジェクト・マネジャーは次に何をすべきでしょうか？
A.チーム・リーダーになってプロセスの遵守を徹底するよう機能部門マネジャーに頼む。
B.チーム・リーダーを任命してチームのイテレーション計画とその完了責任を負わせる。
C.イテレーション作業の管理責任はチーム自身にあることをプロジェクト・スポンサーに説明する。
D.プロジェクト・スポンサーから与えられた新しいスケジュールに従うようチームに助言する。
正解：C イテレーション作業の管理責任はチーム自身にあることをプロジェクト・スポンサーに説明する。
アジャイル・アプローチでは、チームが自らの作業とプロセスに責任を負います。
選択肢の分析
A.「チーム・リーダーになってプロセスの遵守を徹底するよう機能部門マネジャーに頼む。」（❌ 不正解）
アジャイルでは、機能部門マネジャーのような外部の指示による管理は適さない。
チームは自己組織化されているべきであり、外部の介入が増えるとアジャイルの原則に反する。
B.「チーム・リーダーを任命してチームのイテレーション計画とその完了責任を負わせる。」（❌ 不正解）
アジャイルでは、リーダーシップはチーム全体で分担される。
特定の個人に責任を集中させるのは、自己組織化を阻害し、チームの士気を下げる可能性がある。
C.「イテレーション作業の管理責任はチーム自身にあることをプロジェクト・スポンサーに説明する。」（✅ 正解）
アジャイルでは、イテレーション（スプリント）の管理はチームが行う。
スポンサーが期日を決めるのではなく、チームが状況を判断し、適切な調整を行うべきである。
プロジェクト・マネジャーは、アジャイルの原則をスポンサーに説明し、適切な関与を促す役割を果たすべき。
D.「プロジェクト・スポンサーから与えられた新しいスケジュールに従うようチームに助言する。」（❌ 不正解）
アジャイルでは、スケジュールの決定はチーム主導で行うべき。
スポンサーの一方的なスケジュール変更に従うことは、チームの自己組織化を阻害する。
アジャイルでは、機能横断型チームが意思決定権を持ち、スクラム・マスターがファシリテーションをします。機能部門マネジャーがチーム・リーダーになることはありません。
アジャイルでは、一人のチーム・リーダーが責任を負うことはなく、スクラム・チーム全員がイテレーション計画の実施責任を負います。
アジャイル・チームは、優先順位付けされたバックログとストーリー・サイズの見積りに基づいて計画を立てます。チームのベロシティに基づいて実施するストーリーを決めるので、スポンサーから与えられたスケジュールに従うことはありません。
Expert
プロジェクト・マネジャーは、3年前の自社プロジェクトに類似した数百万ドル規模のプロジェクトにアサインされました。確かなコスト見積りを作成するために、プロジェクト・マネジャーは何をすべきでしょうか？
A.重要なパラメーターを見つけ、その値に基づいて見積りをする。
B.当初の見積りに今年の自社標準係数を掛けた値を使う。
C.前回のプロジェクトの実コストを参考に各タスクの推定コストを算出して集計する。
D.材料費や人件費の取引価格の変動を考慮して新たな見積りを算出する。
正解：C 前回のプロジェクトの実コストを参考に各タスクの推定コストを算出して集計する。
前回のプロジェクトの実コストを参考にするのがボトムアップ見積り法として最善の選択であり、最も信頼できます。ボトムアップ見積りは、各ワーク・アクティビティのあらゆる具体的な構成要素の詳細なコストを起点とし、そこからプロジェクト全体の予算の見積りに用いられるすべてのコストを積み上げて累計するので、精度が比較的高いのが一般的です。ボトムアップ見積りは、プロジェクトの成果物を最小の構成要素すなわちワーク・アクティビティに分解して、各ワーク・アクティビティの要件に関する詳細な情報を収集した後に行うのが合理的です。また、この事例では過去のデータを利用できるので、信頼性はさらに高まります。
問題文の重要なキーワード
「3年前の自社プロジェクトに類似した」
過去のプロジェクトのデータを活用できることを示唆している。
類似プロジェクトの実績データを基に見積りを行う手法（アナログ見積り）が適用できる可能性が高い。
「数百万ドル規模のプロジェクト」
大規模なプロジェクトであり、精度の高いコスト見積りが求められる。
「確かなコスト見積り」
できる限り正確な見積り手法を選択する必要がある。
経験データに基づいた実証的な方法が有効である。
その他の選択肢が誤りなのは、ボトムアップ見積りよりも精度が劣るからです。
パラメーターの変動幅に基づいて見積りを作成したり、コスト変動幅の計算に商品取引価格を用いたりするのは、パラメトリック見積り法です。類推見積りよりは精度は高まるかもしれませんが、信頼できる見積りを作成することはできません。
当初の見積りに対し、自社の例年の標準によって決定される係数を乗じるという方法を取ると、類似プロジェクトが新規プロジェクトと完全には同等でない場合や、類似プロジェクトのコストが時間とともに大幅に変化した場合には、不正確な見積りが出ることになります。
Difficult
プロジェクトの実施中に問題が発生してコンティンジェンシー計画を発動すべきですが、それにより遅延が見込まれます。プロジェクト・マネジャーはどうすべきでしょうか？
A.リスク監査を開始する。
B.変更要求を発行する。
C.コストへの影響を評価する。
D.コンティンジェンシー計画を更新する。
正解：B 変更要求を発行する。
変更要求の発行は、進行中プロジェクトの公式な計画変更プロセスです。プロジェクトのスケジュールや予算に大幅な影響を及ぼす問題が発生した場合、変更要求を発行して公式にプロジェクト計画を変更できます。変更を計画文書に反映することで、ステークホルダー全員に変更を周知し、新しい計画に沿って進捗を管理できます。
その他の選択肢は誤りです。リスク監査、コストへの影響の評価、コンティンジェンシー計画の更新なども後から行うことはありえますが、プロジェクトの枠内で効果的に変更をマネジメントするために最初に行うべきことは変更要求の発行です。
リスク監査を開始するのが誤りなのは、リスク監査はすでに発生した問題に対応するために即座に行うことではないからです。リスク監査は、すでに生じた問題に対応するためではなく、プロジェクトのリスクを事前に評価するために行うべきことです。
コストへの影響を評価するのが誤りなのは、変更要求を提出して問題の影響を評価した後に行うべきことだからです。
コンティンジェンシー計画を更新するのが誤りなのは、変更要求が承認されてプロジェクトに対する変更が実施された後に行うべきことだからです。
Expert
製品開発中に2つの機能部門が人員不足のため期日までに納品できないと言ってきました。
プロジェクト・マネジャーは、この問題に対処するために何をすべきでしょうか？
A.この問題をスポンサーにエスカレーションしてプロジェクト・スコープの確認を求める。
B.要件を満たすために追加の人員を採用するよう機能部門マネジャーに依頼する。
C.商業上のニーズを満たすために残業するようチーム・メンバーに頼む。
D.実用最小限のプロダクト（MVP）をデリバリーするためのクリティカル・パスを分析する。
正解：D 実用最小限のプロダクト（MVP）をデリバリーするためのクリティカル・パスを分析する。
プロジェクトに制約がある場合に利用できる概念の1つが、実用最小限のプロダクト（MVP）というスコープ・マネジメントの枠組みです。時間や予算の制約に対してスコープが広すぎる場合、許容できる成果をデリバリーするためにMVPを特定します。
どのように思考してDが正解と導き出せるか
問題の本質を特定する
人員不足 → スケジュール遅延のリスク → 優先度の高い作業に集中する必要がある。
解決策としては「スコープの最適化」または「リソースの最適化」が求められる。
すぐに解決できる手段を優先する
追加人員（B）は時間がかかる。
残業（C）は短期的には可能だが、持続不可能で、チームのモチベーション低下につながる。
スポンサーへのエスカレーション（A）は最後の手段であり、プロジェクト・マネジャーの管理範囲内で解決することが望ましい。
最も効果的なアクションを選択する
クリティカル・パスを分析し、MVPを納品することで、最も重要な機能に集中できる。
リソース不足の影響を最小限にし、期日を守る現実的な解決策となる。
結論
Dの「実用最小限のプロダクト（MVP）をデリバリーするためのクリティカル・パスを分析する」が最も合理的な選択肢。 リソース不足を前提に、重要な機能を優先し、納期を守るための実践的なアプローチを取ることができる。 PMBOKの考え方にも適合し、プロジェクトの成功確率を高める判断である。
Difficult
プロジェクト・マネジャーは、あるチーム・メンバーの機能部門マネジャーとの間で問題を抱えています。この機能部門マネジャーは、プロジェクトの優先度は低いとして当該メンバーを別の仕事にアサインしてしまいました。
プロジェクト・マネジャーはどうすべきでしょうか？
A.この問題を経営陣にエスカレーションする。
B.このプロジェクトの重要性をチームに伝える。
C.機能部門マネジャーにプロジェクト憲章を読んでもらう。
D.担当プロジェクトの増員を要求する。
正解：A この問題を経営陣にエスカレーションする。
プロジェクトの重要性についての機能部門マネジャーの認識を変えるにはこの方法がもっとも効果的です。結果としてプロジェクトに当該メンバーを戻してもらえる可能性が高まります。
選択肢の分析
A.「この問題を経営陣にエスカレーションする。」（✅ 正解）
機能部門マネジャーとの調整が難しく、組織全体の方針に影響を及ぼす問題であるため、エスカレーションが適切。
経営陣は、プロジェクトの優先順位を再確認し、リソース配分について適切な決定を下す権限を持つ。
PMBOKでも、リソースの割り当てに関する重要な問題は適切なレベルへエスカレーションすることが推奨されている。 C.「機能部門マネジャーにプロジェクト憲章を読んでもらう。」（❌ 不正解）
プロジェクト憲章にはプロジェクトの目的や範囲が記載されているが、これを読んでもらうだけでは機能部門マネジャーの意向を変えるのは難しい。
既に「プロジェクトの優先度は低い」と判断しているため、プロジェクト憲章の共有だけでは対応不足。
結論
Aの「この問題を経営陣にエスカレーションする」が最適な選択。 機能部門マネジャーとの調整が困難な場合、経営陣の判断を仰ぐことがリソース確保のための適切な手段である。 PMBOKにおいても、プロジェクトのリソース確保が困難な場合は、上位の意思決定者へエスカレーションすることが推奨されている。
Expert
プロジェクト・マネジャーは、各国に分散するチーム・メンバーとグローバル・プロジェクトに取り組んでいます。コミュニケーション・マネジメントの一貫として毎月バーチャル会議と現場訪問を実施する予定です。
プロジェクト・マネジャーは、チームと協力して次に何をすべきでしょうか？
A.バーチャル会議の技術的支援を各国のITマネジャーに依頼する。
B.メンバーの履歴書を集めてチームの業務経験を理解する。
C.従うべき規則や原則を記したチーム憲章を起案して制定する。
D.チーム全員と直接会えるように毎週対面会議をする予算を要求する。
正解：C 従うべき規則や原則を記したチーム憲章を起案して制定する。
まずはチーム憲章を制定します。チーム憲章は、チームの価値観、合意、運営上のガイドラインを定めた文書です。プロジェクト・マネジャーはチーム内の問題の防止や解決にこの文書を利用できます。チーム内のコミュニケーション、問題解決、合意形成の促進のためにチーム憲章以外にも運営ガイドラインや行動規範をチームと協力して策定する場合があります。
選択肢の分析
A.「バーチャル会議の技術的支援を各国のITマネジャーに依頼する。」（❌ 不正解）
技術的支援は重要だが、これはITマネジャーが担当するタスクであり、プロジェクト・マネジャーが「次にすべきこと」として最優先ではない。
チームの協力を促進する直接的な対策とは言えない。
B.「メンバーの履歴書を集めてチームの業務経験を理解する。」（❌ 不正解）
メンバーのスキルや経験を把握することは有益だが、チームのコラボレーションやコミュニケーション戦略の確立には直結しない。
C.「従うべき規則や原則を記したチーム憲章を起案して制定する。」（✅ 正解）
グローバル・プロジェクトでは、共通のルールや期待値を明確にすることが不可欠。
**チーム憲章（Team Charter）**は、メンバー間の役割、責任、コミュニケーション手段、会議の頻度、期待される成果物、意思決定プロセスを定める。
バーチャル環境では、明確な合意がないと意思疎通が困難になり、プロジェクトの進行に影響を及ぼす。
D.「チーム全員と直接会えるように毎週対面会議をする予算を要求する。」（❌ 不正解）
予算の問題に加え、グローバルなチームで毎週対面会議を行うのは非現実的。
オンラインで効果的にコラボレーションできる仕組みを構築する方が重要。
Difficult
プロジェクト・チームは、プロダクトのアーキテクチャーがユーザーの増加に対応できないことに気づきました。
プロジェクト・マネジャーはどうすべきでしょうか？
A.パフォーマンス・テストを行いプロダクト・パフォーマンスが十分出ていることを確認するためメンバーをアサインする。
B.外部の専門家を雇ってプロダクト・アーキテクチャーを評価し解決策を提案してもらう。
C.プロダクト・オーナーと協力して新たな開発計画を立てプロダクト・バックログの優先順位付けを行う。
D.実行可能な解決策が見つかるまで開発速度を遅らせることをステークホルダーと交渉する。
正解：C プロダクト・オーナーと協力して新たな開発計画を立てプロダクト・バックログの優先順位付けを行う。
プロジェクト・マネジャーはまずプロダクト・オーナーと重要な情報を共有し、ビジネス・ステークホルダーを招いて意見を聞き、価値を検討してもらった上でプロダクト・バックログの優先順位を付け直します。これにより、企業、チーム、ビジネス・ステークホルダーの懸念に対応できます。
選択肢のキーワード
A.「パフォーマンス・テスト」「パフォーマンスが十分出ていることを確認」
問題の根本原因を特定するプロセスだが、解決策の策定にはつながらない。
B.「外部の専門家を雇う」「解決策を提案してもらう」
アーキテクチャの評価は有効だが、直接のプロジェクトマネジメントの行動とは言えない。
C.「プロダクト・オーナーと協力」「新たな開発計画を立てる」「プロダクト・バックログの優先順位付け」 ✅（正解）
アジャイル環境での適切な対応策を示している。
スケーラビリティ対応のための開発計画を整理し、バックログの優先順位を変更することが重要。
D.「開発速度を遅らせる」「ステークホルダーと交渉」
リスク回避にはなるが、根本的な解決にはならない。
どのように思考してCが正解か？
1. プロジェクトマネージャーの役割に適合
プロジェクトマネージャーは、プロダクトの開発方針を戦略的に調整する役割を担う。 技術的課題を解決するのはチームの責任だが、マネジメントとしての優先順位付けと計画調整はPMの仕事。 Cの選択肢は、PMがプロダクト・オーナーと協力して計画を調整する、という役割に合致する。
- アジャイル開発のアプローチに沿っているアジャイルプロジェクトでは、プロダクトバックログの見直しが一般的な解決策。
スケーラビリティ改善のために、新たな開発タスクをバックログに追加。
既存のタスクの優先順位を変更し、早期にスケーラビリティ問題へ対応する。
AやBは技術的アプローチの一部だが、最終的な解決には至らない。 - 解決策の実行可能性Cのアプローチでは、具体的な開発計画が立てられるため、短期的にも長期的にも解決に向かいやすい。
Dのように開発速度を遅らせるだけでは、問題の本質的な解決にはならず、ステークホルダーとの関係も悪化する可能性がある。
結論
問題の本質は、プロダクトのスケーラビリティ問題であり、単なるテストや評価ではなく、開発計画の見直しが必要。 プロジェクト・マネジャーの立場としては、技術の詳細な評価ではなく、開発戦略を調整することが求められる。 Cの「プロダクト・オーナーと協力してバックログの優先順位を変更し、新たな開発計画を立てる」が、アジャイルの観点から最も適切なアクション。
Difficult
プロジェクトではハイブリッド型アプローチを採用しており、チームは予測型の段階では優れたパフォーマンスを挙げていました。ところが漸進型の段階に入ると、チームの士気や意欲は下がり、対立や混乱が見え始めました。しかしあるメンバーだけは依然として自信を持ち優れたパフォーマンスを挙げています。
プロジェクト・マネジャーはまず何をすべきでしょうか？
A.優秀なメンバーを他のメンバーの模範として表彰する。
B.アジャイル・プロセスに関する追加トレーニングをチームに実施する。
C.プロジェクト・スポンサーと相談して予測型だけでプロジェクトを進める。
D.チーム・ミーティングで話し合って問題の対策を考える。
正解：D チーム・ミーティングで話し合って問題の対策を考える。
チームのパフォーマンス問題の原因を特定し、その対応策を考えます。
その他の選択肢は間違いです。優秀なメンバーを表彰してもパフォーマンス問題の原因には対処できません。追加トレーニングは有効かもしれませんが、これも問題の原因に対処することにはなりません。予測型アプローチだけでプロジェクトを進めることは難しいかもしれませんし、それによって問題が解消できるとは限りません。
Difficult
アジャイル・プロジェクト・チームのあるメンバーは、バックログの優先度を無視して簡単ですぐにできるユーザー・ストーリーばかり選んでいます。この状況にどう対処すべきでしょうか？
A.優先度の高いユーザー・ストーリーから先に実装するようチーム全体に再度周知する。
B.今後のイテレーションでは規模が大きく難易度の高いユーザー・ストーリーを選ぶよう当該メンバーに指示する。
C.簡単なストーリーばかり選ぶ理由を当該メンバーに直接聞き、必要に応じて作業負荷を調整する。
D.当該メンバーのスキルギャップを埋めるために製品開発に必要な主要技術に関する再教育を行う。
正解：C 簡単なストーリーばかり選ぶ理由を当該メンバーに直接聞き、必要に応じて作業負荷を調整する。
プロジェクト・マネジャーは、問題の根本原因を理解してから対処する必要があります。作業量、スキル、あるいはそれ以外の要因が原因である可能性もあるので、オープンなコミュニケーション、コラボレーション、チームのダイナミクスの理解を促進することが大事です。
その他の選択肢は問題を評価せずに対応してしまっているので誤りです。
Difficult
プロジェクト・マネジャーは、世界中に分散したチームと一緒にグローバル企業のプログラムを推進するよう任されました。チーム・メンバーは各国に分散し、状況報告の方法についてもその詳細度や頻度について様々な意見が出ています。
プロジェクト・マネジャーは、この問題をどう解決すべきでしょうか？
A.コミュニケーション・マネジメント計画書に従うようチームに求める。
B.この問題をプロジェクト・スポンサーにエスカレーションして助言を求める。
C.この問題を自力で解決するようチームに求める。
D.既存の状況報告テンプレートを適宜変更する。
正解：A コミュニケーション・マネジメント計画書に従うようチームに求める。
コミュニケーション・マネジメント計画書は、いつ、誰が、どのようにプロジェクトの情報を管理、発信するかを記述したものです。分散したチームで状況報告の一貫性を保つために、所定のコミュニケーション・マネジメント計画書に従うようにします。
正解を導き出す思考プロセス
問題の本質を特定
グローバルチームは、文化や国によって「報告の詳細度」「報告頻度」などの期待値が異なる。
すでにチーム内で意見が分かれているため、基準を明確にする必要がある。
どのアプローチが適切か？
「コミュニケーション・マネジメント計画書（A）」は、事前に策定したコミュニケーション方針であり、チーム全体が従うべき基準を提供する。
「スポンサーにエスカレーション（B）」は、優先度が高い問題ではないので不要。
「チームに自力解決を求める（C）」は、基準がない状態で各自がバラバラに対応する可能性があり、混乱を招く。
「既存のテンプレートを適宜変更（D）」は、計画書を無視する形になり、基準が曖昧なままとなる。
PMBOK的な観点
PMBOKでは、プロジェクトのコミュニケーションは計画的に管理すべきとされている。
「コミュニケーション・マネジメント計画書」は、報告の頻度・フォーマット・対象者を定める重要な文書であり、問題解決の最優先策となる。
その他の選択肢は誤りです。
問題のエスカレーションは、最後の手段とすべきです。
自力で解決するようチームに求めても、合意形成できる状態ではないので妥当ではありません。
既存テンプレートの変更は、チームが合意できなければ報告が一貫性を持たず混乱する恐れがあります。
Difficult
新しい規則が採択され、その規則に従ってプロジェクトを提供しなければならなくなりそうだという知らせがプロジェクト・マネジャーに入りました。このリスクはあらかじめ、発生確率が低く、影響度が中程度のリスク項目として文書化されていました。
プロジェクト・マネジャーは、この課題に対処するために何をすべきでしょうか？
A.リスク登録簿を見直し、評価と対応策を更新する。
B.課題ログを更新し、是正処置を講じる。
C.プロジェクトマネジメント計画書を修正する。
D.規則の更新に応じた変更要求を提起する。
正解：A リスク登録簿を見直し、評価と対応策を更新する。
問題文の重要なポイントは以下のとおりです。
「新しい規則が採択され、プロジェクトをそれに従って提供しなければならない」
新たな外部要因の変化 により、プロジェクトの進め方に影響が出る可能性がある。
「このリスクは、発生確率が低く、影響度が中程度のリスク項目として文書化されていた」
リスク登録簿 にすでに記載されていたため、新たな対応策を検討する必要がある。
選択肢のキーワード
A. 「リスク登録簿を見直し、評価と対応策を更新する。」 → ✅ 正解
事前に文書化されたリスクであるため、リスク管理プロセス の一環として適切に見直し、対応策を更新する。
B. 「課題ログを更新し、是正処置を講じる。」 → ❌ 不正解
まだ「課題」にはなっておらず、対応は「リスク管理」プロセスの範囲内。
C. 「プロジェクトマネジメント計画書を修正する。」 → ❌ 不正解
まだ具体的な影響を評価していない段階であり、すぐに計画書を修正するのは時期尚早。
D. 「規則の更新に応じた変更要求を提起する。」 → ❌ 不正解
変更要求をする前に、まず リスクの影響度を再評価し、対応策を考える べき。
思考プロセス（正解を導く考え方）
リスクの管理対象か、課題の管理対象か？
問題文では「このリスクは事前に文書化されていた」とあるため、現在はリスク管理の段階 であり、まだ「課題ログ」に記載するフェーズではない（Bは除外）。
リスクに対する対応は何を優先すべきか？
まず 「リスクの発生確率が変わったか？」「影響度が上がったか？」 を評価する必要がある。
リスク登録簿の見直しと対応策の更新が最初のステップ（Aが適切）。
計画修正や変更要求はすぐに必要か？
リスクの影響が確定した後、必要に応じて計画修正（C）や変更要求（D）を検討すべき。
そのため、Aが最も適切である。
リスクの影響度が変わるかもしれないのでリスク登録簿を更新しなければなりません。プロジェクトの環境に変化（新しい規則の採択など）が生じた場合、リスク登録簿を見直し、プロジェクトのリスクが十分にマネジメントされた状態を維持することが重要です。この事例では「新しい規則の採択」リスクは特定していたものの、その発生確率は低く、影響度は中程度だと見なしていました。規制が採択されたことを受けてリスクの可能性や影響度が増大する可能性があります。プロジェクト・マネジャーは、状況の変化に応じてリスク登録簿を見直し、評価と対応策を更新すべきです。それにより、コンプライアンス違反を避け、今後も順調にプロジェクトを進める公算が高まるでしょう。
Difficult
カンバン・プロジェクトを監督するアジャイル・プロジェクト・マネジャーは、次の重要なマイルストーンに向けて、タスク完了の妨げとなる障害を評価したいと考えています。プロジェクト・マネジャーはどうすべきでしょうか？
A.WIP制限を用いてパフォーマンス・メトリックスを設定する。
B.信頼できるチーム・メンバーからチームが直面している問題について話を聞く。
C.チームとスタンドアップ・ミーティングで滞っている作業項目を確認する。
D.タスク完了の障害について話し合うためのステークホルダー・ミーティングを開催する。
正解：C チームとスタンドアップ・ミーティングで滞っている作業項目を確認する。
カンバンには仕掛り作業（WIP）が見える化されており、ボトルネックやオーバーコミットメントを見つけて作業の流れを最適化しやすくなっています。プロジェクト・マネジャーは、チームと協力してスタンドアップ・ミーティングで進捗確認を行い、既存の障害や潜在的な障害を明らかにします。
「カンバン・プロジェクト」
カンバン（Kanban） は視覚的な管理手法であり、作業の進行状況を カンバンボード で可視化する。 WIP（Work In Progress）制限 により、同時に進行できる作業数を制限し、ボトルネックの発生を防ぐ。
「次の重要なマイルストーンに向けて、タスク完了の妨げとなる障害を評価したい」
プロジェクト・マネジャーの目的は、チームが直面している問題を特定し、それを解決すること である。
選択肢のキーワード
A. 「WIP制限を用いてパフォーマンス・メトリックスを設定する。」 → ❌ 不正解
WIP制限は ボトルネックを防ぐために有効 だが、すでに発生している障害を特定するための 直接的な手法ではない。
B. 「信頼できるチーム・メンバーからチームが直面している問題について話を聞く。」 → ❌ 不正解
チーム・メンバーと個別に話すのは有効だが、カンバンでは 全体の視覚的な状況を確認する ほうが適切。
C. 「チームとスタンドアップ・ミーティングで滞っている作業項目を確認する。」 → ✅ 正解
カンバンボードを使って進行状況を可視化し、停滞しているタスクを特定するのがカンバンの基本。
スタンドアップ・ミーティング は、カンバンでもスプリントでも 障害を特定し、解決策を考える場として重要。
D. 「タスク完了の障害について話し合うためのステークホルダー・ミーティングを開催する。」 → ❌ 不正解
ステークホルダーよりも まずはチームと直接問題を特定するほうが適切。
チーム内部で障害を特定・解決できない場合に、ステークホルダーと協議するのが適切な順序。
Difficult
プロジェクト・マネジャーは、正式なプロジェクトマネジメント・プロセスのない企業に入社したところ、ミーティングで決まったアクション・アイテムを担当することさえ拒むチーム・メンバーがいました。
プロジェクト・マネジャーはどうすべきでしょうか？
A.そのメンバーと個別にプロジェクトマネジメントのメリットについて話し合う。
B.プロジェクトマネジメントのメリットを文書にまとめて全メンバーに配布する。
C.プロジェクトマネジメントのメリットについて経営幹部と議論する。
D.チームと協力してプロジェクト・タスクの実施方法を決める。
正解：D チームと協力してプロジェクト・タスクの実施方法を決める。
経営幹部を介在せずにチーム・メンバー全員から意見を募り、タスク遂行へのチームのやる気を引き出します。
思考プロセス（正解を導く考え方）
問題の本質を特定
チームメンバーが プロジェクトマネジメントに消極的 である。
企業には プロジェクトマネジメントの仕組みがない。
解決のために取るべきアプローチ
トップダウン（経営幹部との議論）ではなく、チームと協力してタスクの実施方法を決めるのが有効。
プロジェクトマネジメントを強制するのではなく、チームと共に実施方法を策定することで、チームの協力を得やすくする。
正解の選択肢の確認
D.「チームと協力してプロジェクト・タスクの実施方法を決める。」 → チームを巻き込むことで、自然な形でプロジェクトマネジメントのメリットを理解しやすくなる。
Expert
進行中のプロジェクトのベネフィットを測るためにパフォーマンスを継続的に評価しています。プロジェクトの開始時にプロジェクト・マネジャーが取るべき2つの行動はどれでしょうか？（2つ選んでください）
A.パフォーマンス・パラメーターに対するステークホルダーの承認を得る。
B.ステークホルダーとの会議を定期的に開催する。
C.追跡する測定値に関する要件について合意する。
D.プロジェクトの管理状況を定期的にレビューする。
E.シミュレーションによりパフォーマンスを予測して主要ステークホルダーに伝える。
正解：A、C パフォーマンス・パラメーターに対するステークホルダーの承認を得る。追跡する測定値に関する要件について合意する。
プロジェクト・パフォーマンスの評価方法に対する認識を関係者全員で一致させて無用な対立を避けるべきです。
選択肢の分析
A.「パフォーマンス・パラメーターに対するステークホルダーの承認を得る。」 → ✅ 正解
理由:
測定する基準（KPI、パフォーマンス・パラメーター）を事前に決めておかないと、あとで「期待と違う」と言われる可能性がある。
ステークホルダーと合意することで、評価基準の透明性を確保できる。
B.「ステークホルダーとの会議を定期的に開催する。」 → ❌ 不正解
理由:
継続的なコミュニケーションは重要だが、「プロジェクト開始時に取るべき行動」ではない。
開始時には「評価基準の確立」が優先事項 であり、会議の頻度を決めることが最優先ではない。
C.「追跡する測定値に関する要件について合意する。」 → ✅ 正解
理由:
どの測定値を追跡するのかを決めることが重要（例：コスト、スケジュール、品質、リスクなど）。
測定基準が プロジェクト終了後のベネフィット評価 に影響を与えるため、事前に明確化し、関係者の合意を得ることが必要。
D.「プロジェクトの管理状況を定期的にレビューする。」 → ❌ 不正解
理由:
「進行中のレビュー」は重要だが、「プロジェクト開始時」に最も必要なことではない。
まず、測定基準を決めることが優先 であり、レビューの実施はその後。
E.「シミュレーションによりパフォーマンスを予測して主要ステークホルダーに伝える。」 → ❌ 不正解
理由:
シミュレーションは役立つが、プロジェクト開始時に最優先で行うものではない。
まずは評価基準（KPIや測定指標）を決めることが最も重要。
思考プロセス（正解を導く考え方）
問題の本質を理解する
「プロジェクト開始時」 という条件を考慮する。
目的は パフォーマンス測定の基準を明確にすること。
何が優先事項かを整理する
まず、「どの指標を測るか？」を決めることが最優先。
その指標について、ステークホルダーの合意を得ることが重要。
選択肢を比較する
A.「パフォーマンス・パラメーターの承認」 → 評価基準を決めるので重要 → ✅
C.「追跡する測定値の要件を合意」 → 測定項目を決めるので重要 → ✅
他の選択肢は、測定基準を決めた後の活動に近い ので不正解。
Difficult
アジャイル・プロジェクトでプロダクト・オーナーが定義した実用最小限のプロダクト（MVP）をスプリント・レビューでチームがデモしました。ステークホルダーの1人がデモ中に、リリース・ノートや製品の技術解説書がないことに不満を訴えました。
プロジェクト・マネジャーが取るべき2つの行動はどれでしょうか？（2つ選んでください）
A.アジャイル・プロセスでは技術解説書を作成しないことを説明する。
B.プロダクト・オーナーに要求を挙げるようステークホルダーに求める。
C.リリース・ノートと技術解説書に対するステークホルダーのニーズを明確化する。
D.文書不足に対するステークホルダーの懸念を認める。
E.リリース・ノートと技術解説書をなるべく早く提供する。
正解：D、E 文書不足に対するステークホルダーの懸念を認める。リリース・ノートと技術解説書をなるべく早く提供する。
MVPを活用して、懸念に対処することで、ステークホルダーが本当に必要なモノを提供できます。
その他の選択肢は誤りです。アジャイル・プロセスで技術解説書を提供しないということはありません。プロダクト・オーナーに要求してもらうのは責任転嫁です。ニーズの明確化も大事ですが、ステークホルダーが文書についての明確なニーズを出すのは難しいかもしれません。
問題文のキーワード
「アジャイル・プロジェクト」
アジャイル開発の原則に基づいている。
ドキュメントは 最低限 に留めることが多いが、ステークホルダーの要求には応える必要がある。
「MVP（実用最小限のプロダクト）」
MVPは、市場投入を最優先にし、最小限の機能を備えた製品。
ただし、最小限のドキュメントでも、リリース・ノートや技術解説書が求められることがある。
「ステークホルダーの不満」
ステークホルダーの関与が重要。
アジャイルでは、継続的なフィードバックと調整が求められる。
思考プロセス（正解を導く考え方）
問題の本質を理解する
アジャイルでは、ドキュメントは最小限で良いが、ステークホルダーの要求には柔軟に対応する必要がある。
「リリース・ノートや技術解説書がないこと」に対するステークホルダーの不満が問題。
アジャイルの原則に基づいて判断
ステークホルダーとの対話が最優先（Dが正解）。
リリース・ノートや技術解説書は価値を生む可能性があるため、提供を検討すべき（Eが正解）。
選択肢を比較
D. ステークホルダーの懸念を認める → アジャイルの原則に沿っている。
E. 必要なドキュメントを提供する → 柔軟な対応でアジャイルの考え方にも適している。
結論
✅ 正解: D.「文書不足に対するステークホルダーの懸念を認める。」
✅ 正解: E.「リリース・ノートと技術解説書をなるべく早く提供する。」
📌 ポイント:
アジャイル開発では、ステークホルダーとの対話が最優先。 ドキュメントを作らないのではなく、必要なものは提供するのが適切。 ステークホルダーの不満に共感し、対応策を取ることで信頼関係を構築することが重要。
Expert
プロジェクト・マネジャーは、進行中のプロジェクトの引き継ぎを任されました。チームは品質レビューで40％の成果物に欠陥を見つけ手直しが必要で、さらに悪化しそうです。
プロジェクト・マネジャーはまず何をすべきでしょうか？
A.手直しのコストを評価する。
B.品質マネジメント計画書をレビューする。
C.ユーザー・ストーリーをレビューする。
D.根本原因分析を実施する。
正解：D 根本原因分析を実施する。
特定した欠陥はさらに悪化する見込みなのでまずは根本原因分析をすべきです。根本原因分析は、差異や欠陥、リスクの根本原因を明らかにするために用います。成果物の欠陥の根本原因を特定できれば、同様の欠陥の再発防止策が打てます。
その他の選択肢は、根本原因分析が終わるまでは控えるべきです。まず問題の根本原因を十分に理解した上で是正策を講じます。
思考プロセス（正解を導く考え方）
現状を把握する
40%の成果物に欠陥があるという事実は深刻。
何が原因で欠陥が生じているのかを特定することが最優先。
問題解決の優先順位を決める
欠陥の原因を特定しなければ、適切な対応はできない。
計画書やコスト評価をする前に、まずは「なぜ欠陥が多発したのか」を突き止めることが最重要。
選択肢を比較
D. 根本原因分析を実施する → 問題の本質を理解するために最も重要。
A. コスト評価をする → まだ早い（原因が分かっていない状態での評価は意味がない）。
B. 品質マネジメント計画書をレビューする → 計画と現状のギャップを確認するのは有効だが、まず原因を特定すべき。
C. ユーザー・ストーリーをレビューする → 問題の根本原因に直接関与しないため、最優先ではない。
Difficult
デリバリー・チームとの定期チェックインでモラルと効率の低下が見られました。この問題に対処するために、プロジェクト・マネジャーは何をすべきでしょうか？
A.スキル評価を実施する。
B.チーム・ビルディング活動を実施する。
C.プロジェクトのあらゆる障害を解消する。
D.満足度評価を実施する。
正解：D 満足度評価を実施する。
解決策を実施する前に、まずは問題とその原因を評価すべきです。モラルと効率の低下の原因は何も分かっていません。コンフリクト、過剰な期待、モチベーション不足などの原因が考えられますが、こうした問題に対処するためにはさらに根本原因を特定しなければなりません。アンケート調査により満足度を評価することで原因特定の役に立ちます。
思考プロセス（正解を導く考え方）
現状を分析する
チームのモラルと効率が低下しているのは事実。
しかし、具体的な原因が明確でない。
問題解決のステップを考える
原因を特定することが最優先。
原因を特定しないまま対策を講じても、的外れな施策になりかねない。
各選択肢の適切性を評価する
A. スキル評価を実施する → スキルの問題かどうか不明なので適切でない。
B. チーム・ビルディングを実施する → 効果はあるかもしれないが、まずは原因特定が必要。
C. プロジェクトの障害を解消する → 何が問題か分からない段階での対策は非効率。
D. 満足度評価を実施する → 原因を特定するための調査として最適。
結論
✅ 正解: D.「満足度評価を実施する。」
📌 ポイント:
モラルや効率の低下の原因を特定することが最優先。 満足度評価を行うことで、問題の本質が明確になり、適切な対策を講じることができる。 原因が分かった後に、適切な改善策（チーム・ビルディング、障害解消など）を実施するのが効果的。
Expert
レトロスペクティブ中にチーム・メンバーが、直前のサイクルでプロダクト・オーナーとスクラム・マスターが行ったスコープ問題への対応に異議を唱えました。
プロジェクト・マネジャーはまず何をすべきでしょうか？
A.プロダクト・オーナーとバックログを確認してスコープが適切だったか検討する。
B.チームからあらゆる情報を集めてこの問題に対処する。
C.当該メンバーとのミーティングを設定してこの問題について話し合う。
D.プロダクト・オーナーやスクラム・マスターとチームの懸念について話し合う。
正解：B チームからあらゆる情報を集めてこの問題に対処する。
コンフリクトの発生は避けられないものの適切な手続きや技法を使えば解決できます。コンフリクトが発生した場合にはまず、チームからあらゆる情報を収集して問題を分析し、状況に応じたアプローチを使ってしかるべき環境や雰囲気を作り出します。
選択肢の分析
A.「プロダクト・オーナーとバックログを確認してスコープが適切だったか検討する。」 → ❌ 不正解
問題点:
スコープの適切性を検討することは重要だが、チームの懸念を理解する前に検討するのは順序が違う。
まず、チームの意見を把握し、問題の本質を理解する必要がある。
B.「チームからあらゆる情報を集めてこの問題に対処する。」 → ✅ 正解
理由:
チームが異議を唱えている以上、まずは詳細な情報を集めることが最優先。
問題の原因や背景を把握し、適切なアクションを決定するために必要。
スコープ問題の対応に関する事実関係や、チームの不満の根本原因を理解することが重要。
C.「当該メンバーとのミーティングを設定してこの問題について話し合う。」 → ❌ 不正解
問題点:
1人の意見だけを聞いても、全体像が分からない。
まずは、チーム全体から情報を収集することが必要。
個別に話すよりも、レトロスペクティブでの議論を活用し、オープンな対話を促進する方が効果的。
D.「プロダクト・オーナーやスクラム・マスターとチームの懸念について話し合う。」 → ❌ 不正解
問題点:
プロダクト・オーナーやスクラム・マスターと話す前に、まずチームの意見を整理する必要がある。
一方的な判断をせず、チームのフィードバックを正確に収集し、議論の材料を明確にすることが重要。
その他の選択肢は誤りです。プロジェクト・マネジャーは、コンフリクトの根本原因を理解して初めて解決案を策定できます。プロジェクト・マネジャーは、チーム全体を巻き込んで、関係者全員の意見を尊重し、チームが安心感を持ってオープンなコミュニケーションができる環境を提供すべきです。
Expert
プロジェクト・マネジャーは、銀行のITインフラの更新プロジェクトに取り組んでいます。最近プロジェクト・スポンサーが、このプロジェクトの変更マネジメント計画書を承認しました。そして現在、ある新技術をソリューションに組み込むようプロジェクト・マネジャーに求めています。
プロジェクト・マネジャーは次に何をすべきでしょうか？
A.当該の新技術をリスク登録簿に追加する。
B.変更管理委員会（CCB）に変更要求を提出する。
C.スケジュールとコストのベースラインを更新して新技術を組み込む。
D.プロジェクト・スポンサーに頼んで新技術を調達する。
正解：B 変更管理委員会（CCB）に変更要求を提出する。
新技術の実装のようなプロジェクト変更が生じたときは、変更管理プロセスに沿って変更の文書化、評価、承認または却下を行います。プロジェクト・マネジャーは、CCBに変更要求を提出し、CCBはプロジェクト目標への影響を考えて承認・却下を決定します。
その他の選択肢は誤りです。
問題文のキーワード
「銀行のITインフラの更新プロジェクト」
重要なシステムの変更を扱うプロジェクトであり、厳格な管理が求められる。
変更がシステム全体に影響を与える可能性がある。
「プロジェクト・スポンサーが変更マネジメント計画書を承認」
変更管理のプロセスが確立されている ことを意味する。
変更を受け入れるには正式なプロセスを踏む必要がある。
「新技術をソリューションに組み込むよう要求」
変更の要求が発生しているため、適切なプロセスを適用する必要がある。
選択肢の分析
A.「当該の新技術をリスク登録簿に追加する。」 → ❌ 不正解
問題点:
変更の承認プロセスを経る前にリスク登録簿に追加するのは時期尚早。
変更の影響を適切に評価するためには、まず変更管理委員会（CCB）で承認を得る必要がある。
B.「変更管理委員会（CCB）に変更要求を提出する。」 → ✅ 正解
理由:
プロジェクト・マネジャーは変更管理の正式なプロセスを適用する責任がある。
変更管理委員会（CCB）が変更の影響を評価し、承認または却下を判断する。
CCBで承認されることで、プロジェクトのスコープ・コスト・スケジュールへの影響を適切に管理できる。
Difficult
ベテラン・プロジェクト・マネジャーは、初めてプロジェクトを任された新人プロジェクト・マネジャーのメンタリングを担当しています。プロジェクトの準備を進めている新人プロジェクト・マネジャーは、チームが特定したステークホルダーの数に圧倒されているようです。
ベテラン・プロジェクト・マネジャーは、次に何をするよう新人プロジェクト・マネジャーに指導すべきでしょうか？
A.ステークホルダーを分析して相対的な重要度を明らかにする。
B.ワークブック登録簿を使って主要なステークホルダーを分類する。
C.ステークホルダーの好みを考慮してコミュニケーション・マネジメント計画書を作成する。
D.ワークブック登録簿に基づいてステークホルダーの優先順位付けをする。
ベテラン・プロジェクト・マネジャーは、初めてプロジェクトを任された新人プロジェクト・マネジャーのメンタリングを担当しています。プロジェクトの準備を進めている新人プロジェクト・マネジャーは、チームが特定したステークホルダーの数に圧倒されているようです。
ベテラン・プロジェクト・マネジャーは、次に何をするよう新人プロジェクト・マネジャーに指導すべきでしょうか？
A.ステークホルダーを分析して相対的な重要度を明らかにする。
B.ワークブック登録簿を使って主要なステークホルダーを分類する。
C.ステークホルダーの好みを考慮してコミュニケーション・マネジメント計画書を作成する。
D.ワークブック登録簿に基づいてステークホルダーの優先順位付けをする。
正解：A ステークホルダーを分析して相対的な重要度を明らかにする。
ステークホルダーの特定ができたら、プロジェクト・マネジャーとプロジェクト・チームはステークホルダーの理解と分析に努めます。新人プロジェクト・マネジャーは、各ステークホルダーの立場とプロジェクトの立場の両方を考慮しなければなりません。ステークホルダー分析では、定量・定性両方の情報を広く分析してプロジェクト全体を通じて誰の利害を考慮すべきかを判断します。
Moderate
ある組織が製品開発中に類似製品を買収しプロダクト・ポートフォリオに重複が生じる可能性があります。
プロジェクト・マネジャーは次に何をすべきでしょうか？
A.プロダクト・オーナーとプロジェクトの実現可能性や有効性を評価する。
B.組織のベネフィットのために製品開発を続ける。
C.買収の潜在的な影響についてチーム・メンバーと話し合う。
D.プロダクト・ロードマップが明確になるまでプロジェクトを中断する。
正解：A プロダクト・オーナーとプロジェクトの実現可能性や有効性を評価する。
プロダクト・オーナーと買収の影響を評価して今後の方策を決めるべきです。これにより期待を共有できます。
選択肢のキーワード
A.「プロダクト・オーナー」「実現可能性」「有効性」（✅正解）
買収した製品と開発中の製品の戦略的価値や技術的な重複を評価し、どちらを続行すべきか検討する。 C.「買収の潜在的な影響」「チーム・メンバー」（❌不正解）
チーム・メンバーと話し合うのは重要だが、まずは経営レベルでの戦略的な評価が優先される。
その他の選択肢は誤りです。組織の意向を決めずに製品開発の続行や作業の中断をすれば労力や時間のムダになる可能性があります。潜在的な影響について話し合うのは有効ですがプロダクト・オーナーと話し合うのが先です。その後の影響分析にはメンバーが参加することもあります。
Difficult
