ITパスポート 令和5年度 問54：project_managementに関する問題

答えは d（c, d） です。

スコープとは「やる作業の範囲」のこと。スコープの失敗＝「やることの範囲をちゃんと決められなかった失敗」です。

• a お金（人件費）の見積りミス→お金の失敗（コスト）。
• b 期間を短く設定→時間の失敗（スケジュール）。
• c 作る機能の範囲を決めずに開始→範囲の失敗。スコープ！
• d やるべき作業が計画から抜けていた→やることが抜けた。スコープ！

👉 覚え方：「スコープ＝作業の範囲。範囲の決め忘れ・抜け落ちがスコープの失敗」。

範囲の失敗はcとd。よって d が正解です。

なぜこれが正解か

正解は d（c, d）。スコープのマネジメントとは、プロジェクトで「実施すべき作業・成果物の範囲」を定義し管理すること。スコープの失敗とは“範囲を適切に定義・網羅できなかった”ことを指す。

• c 作成する機能の範囲を決めずに開始 → スコープの失敗：範囲未定義そのもの。
• d 実施すべき作業が計画から欠落 → スコープの失敗：必要な作業（範囲）の漏れ。

各記述の解説

• a 人件費を過少見積り→予算超過＝コストマネジメントの失敗。
• b 作業期間を短く設定→予定超過＝スケジュールマネジメントの失敗。
• c 機能範囲未定義＝スコープの失敗。
• d 作業の欠落＝スコープの失敗。

覚え方・ひっかけ注意

各マネジメント領域を対象で切り分ける：スコープ＝作業/成果物の範囲、コスト＝お金、スケジュール＝時間、品質＝できばえ。「範囲を決めていない」「作業が抜けた」はスコープ、「お金」はコスト、「期間」はスケジュールと即判定する。abの罠（コスト・時間）に引っ張られないこと。

理論的背景

スコープマネジメント（Scope Management）はPMBOK（Project Management Body of Knowledge）の知識エリアの一つであり、「プロジェクトに含まれる成果物と作業範囲を定義・コントロールし、必要なものだけを確実に含め、不要なものを排除するプロセス」を扱う。PMBOKでは「プロダクトスコープ（製品・サービスの特徴と機能）」と「プロジェクトスコープ（プロジェクトが完了するために実施すべき作業量）」の2種類のスコープを区別して管理する。

スコープマネジメントの失敗は主に以下のパターンで発生する。

パターン1：スコープ未定義（本問の記述c）：「作成する機能の範囲をあらかじめ決めずにプロジェクトを開始した」という状況。スコープが曖昧なままプロジェクトを開始すると、ステークホルダーの期待値が一致せず、後から「これも作るべき」「あれも必要」という追加要求が際限なく発生する「スコープクリープ（Scope Creep）」が生じる。結果として開発期間が際限なく延伸する。

パターン2：WBS（Work Breakdown Structure）の不完全な展開（本問の記述d）：「プロジェクトで実施すべき作業が幾つか計画から欠落していた」という状況。WBSはプロジェクトのスコープを成果物・作業に階層的に分解する計画ツールであり、WBSの作成漏れは「見えないスコープ」を生み出す。後になって欠落した作業が発覚すると、スケジュール・コスト・品質すべてに影響する。

実務での使われ方

スコープマネジメントの中核ツールであるWBS（Work Breakdown Structure）は、プロジェクトの最終成果物を「ワークパッケージ（Work Package）」という管理可能な最小単位に分解するまで展開する。WBS辞書（各ワークパッケージの説明・責任者・成果物・受入基準）と組み合わせることで、プロジェクトのスコープを厳密に定義する。WBSに含まれない作業はプロジェクトのスコープ外であるというWBSの「排他的完全性（100%ルール）」が重要な原則であり、この原則が守られていれば本問の記述dのような作業の欠落は防止できる。

スコープクリープ対策として、「変更管理プロセス（Change Control Process）」の整備が標準的な実務である。ステークホルダーから新たな要求が発生した場合、それを変更要求（Change Request）として形式的に評価し（スコープ・スケジュール・コストへの影響分析）、プロジェクトオーナー・スポンサーの承認を経てから受け入れる・却下するかを判断する。アジャイル開発では変更をバックログとして積み上げ、各スプリント計画で優先順位を付け直す形で変更を「制御しながら受け入れる」アプローチが取られる。

試験での位置づけ

ITパスポートのプロジェクトマネジメント分野では、PMBOKの知識エリア（スコープ・スケジュール・コスト・品質・リスク・コミュニケーション・調達・人的資源・ステークホルダー統合管理）の中からスコープ・スケジュール・コストの3領域が特に頻出である。本問のような「失敗事例をどの知識エリアに分類するか」という問いは、各エリアの定義と典型的な失敗パターンの対応関係を理解しているかを問う高品質な問題である。

本問の誤答として想定される典型ミスは、記述aとbをスコープ失敗と誤認することである。記述a「人件費の過少見積もり→予算超過」はコストマネジメントの失敗（見積もりの精度問題）、記述b「作業期間の短く設定→予定期間で完了できない」はスケジュールマネジメントの失敗（スケジュール見積もりの精度問題）にそれぞれ分類される。「何を作るか」の範囲（スコープ）の問題ではなく、「いつまでに」「いくらで」の見積もりの問題である点が区別のポイントである。

選択肢の発展補足

記述a（人件費の過少見積もり→予算超過）＝コストマネジメントの失敗：コスト見積もりの手法（類推見積もり・パラメトリック見積もり・ボトムアップ見積もり）の適切な選択と、見積もり精度のコントロールが課題。プロジェクトが大きいほどコスト見積もり誤差が全体に与える影響が大きくなるため、EVM（Earned Value Management）によるコスト実績とのトラッキングが重要となる。

記述b（期間の短く設定→予定期間で完了できない）＝スケジュールマネジメントの失敗：スケジュール見積もりではクリティカルパス分析・資源の制約・リスクバッファ（プロジェクト予備・活動予備）の考慮が必要。人月見積もりの「過度の圧縮（見せかけの効率）」はブルックスの法則（投入した人員が多いほど生産性が下がる現象）を引き起こすリスクがある。

記述c・dはいずれもスコープ定義の不備（スコープ未定義・WBSの漏れ）が根本原因であり、結果として開発期間超過・システム未完成という影響が表れたが、その根本的な失敗の分類はスコープマネジメントである。失敗の「表れ方（期間超過・未完成）」と「根本原因の分類（スコープ管理の失敗）」を区別することが本問を正しく解く鍵である。