→そのコンポーネントが設計および性能の仕様を満たしているか確認する。
要求仕様と受入基準は、作業開始前に取り決めておくべきです。要件に関する不満が生じた場合、まずは受入基準との照合が必要です。プロダクトの仕様が受入基準とマッチしていなければ、ステークホルダーと合議の上、プロジェクト・マネジャーが変更リクエストを挙げます。。
理由
① PMPの原則：感情ではなく事実に基づく判断（Evidence-Based Decision Making）
ステークホルダーが「使いづらい」と感じるのは主観的な意見です。
PMPの観点では、まずその主張が仕様・要件の観点で妥当かどうかを確認することが優先されます。
- 「使いづらい」とは、必ずしも「要件を満たしていない」という意味ではない。
- まずプロダクトが設計・性能の仕様（要件ベースライン）に適合しているかを確認する必要があります。
これは、PMBOKでいう「品質マネジメント（品質保証と品質管理）」の最初のステップにあたります。
② 事実確認 → 受入基準・変更対応はその後のステップ
もし確認の結果、コンポーネントが設計・性能仕様を満たしていれば、
次のステップとして「ユーザー体験上の課題」としてステークホルダーと話し合い、
受入基準の見直しや改善リクエストを検討します。
逆に、もし要件や設計仕様を満たしていない場合は、
**不適合（Non-conformance）として是正措置（Corrective Action）**を取ることになります。
つまり、PMの行動順はこうです：
① 仕様適合の確認 → ② 受入基準・期待値の再定義 → ③ 必要に応じて変更手続き
③ すぐ変更リクエストを出すのは誤り
「ステークホルダーが不満を言ったからすぐ変更リクエストを出す」というのは、
**統制を欠いた行動（Scope Creep）**になります。
PMPでは、変更管理プロセス（Integrated Change Control）は事実に基づいた根拠のある要求でなければ進めてはいけません。
感情や印象に反応するのではなく、検証→評価→承認の順を踏むのが正しい流れです。
❌ 他の選択肢の誤り
「ステークホルダーと一緒にプロダクトの受入基準を明確化する。」
→ これは開発初期または計画フェーズで行うべき活動です。
今はすでにコンポーネントが完成している段階なので、まずは現状が仕様に合っているか確認するのが先です。
「ユーザー・エクスペリエンス（UX）の専門家に設計理由を説明してもらう。」
→ 理由の説明よりも、まず「仕様に準拠しているか」をPM自身が確認するのが先。
UXの説明は、確認の後でステークホルダーの納得を得るための補足対応として行うものです。
「ステークホルダーの要求に応じて変更リクエストを挙げる。」
→ 最もありがちな誤答です。
仕様未確認のまま変更を進める＝統制プロセス違反です。
変更は常に「妥当な根拠がある場合のみ」正式手続きを経て実施されるべきです。
💡 ワンポイントアドバイス
PMP試験では、次の3ステップを常に意識すると正解しやすくなります：
- まず事実を確認する（Check the baseline）
- 次に関係者と期待値を再調整する（Clarify expectations）
- 最後に正式な変更プロセスを経て対応する（Control changes）
特に品質や要件の問題では、感情ではなくエビデンスに基づいて対応することがポイントです。
✅ まとめ
- 正解：そのコンポーネントが設計および性能の仕様を満たしているか確認する。
- 理由：主観的な不満に反応する前に、まず要件や設計仕様に適合しているかを検証する必要がある。
- 誤答理由：他の選択肢はいずれも事実確認を飛ばして行動しており、統制プロセス上の誤り。
- アドバイス：PMPでは「感情より事実、反応より検証」。最初の一歩は常に“確認”から。
フルレングス試験2 (日本語) 26
コメント