ITパスポート 令和4年度 問36：プロジェクトマネジメントに関する問題

答えは a です。

WBSは、大きな仕事を「やることの一覧」として細かく分けた表のことです。たとえば「カレーを作る」を「材料を買う→切る→煮る→盛り付ける」みたいに小さな作業にバラバラにするイメージ。

作業を細かく分けると、それぞれ「何時間かかるか」が見えてきますよね。だから工数（手間や時間）を見積もる土台に使えるんです。

👉 覚え方：WBS＝「やることを小分けにしたリスト」。

ほかの選択肢：b 関係ない作業（範囲外）まで入れるのはムダ／c どんな仕事でも同じ細かさにするのは無理／d 似た作業でも書かないと抜け落ちるのでダメ。

なぜこれが正解か

正解は a。WBS（Work Breakdown Structure＝作業分解構成図）は、プロジェクトの成果物と作業を階層的に分解した図。最小単位（ワークパッケージ）まで分けることで、各作業の工数・コスト・期間を見積もる根拠として使える。

各選択肢の解説

• b：WBSはスコープ（実施範囲）内の作業だけを対象とする。スコープ外を含めるのは誤り。
• c：分解の詳細度は作業の性質で変わる。全プロジェクト・全作業を同じ階層まで揃える必要はない。
• d：類似作業でもスコープ内なら漏れなく記載する（記載しないと工数・管理から抜ける）。

覚え方・ひっかけ注意

「WBS＝やるべき作業を漏れなくダブりなく（MECE）分解」と覚える。bの『スコープ外も含める』、dの『書かなくてよい』は典型的なひっかけ。

理論的背景

WBS（Work Breakdown Structure：作業分解構成図）はPMBOK（Project Management Body of Knowledge）第7版においても「スコープ・マネジメント知識エリア」の中核成果物として定義されており、プロジェクトの成果物と必要作業を「要素成果物指向（deliverable-oriented）」で階層的に分解する手法である。提唱の起源はNASAが1960年代に大型宇宙開発プロジェクトを管理するために体系化したとされ、その後MIL-STD-881として米国防総省が軍用規格に採用したことで汎用化された。

最下層の単位を「ワークパッケージ（Work Package）」と呼び、これが工数・コスト・スケジュール・品質の管理基準単位となる。重要な設計原則が「100%ルール」で、「親要素の作業量＝子要素の合計」が厳密に成立するよう分解しなければならない。この原則によりWBSの正答選択肢aが示す「工数見積もりの根拠として使用できる」が保証される。工数の積み上げ見積もり（ボトムアップ見積り）はWBSの各ワークパッケージに対して個別に見積もった工数を積み上げる手法であり、WBSの粒度が粗いほど見積誤差が拡大する。

実務での使われ方

実務では、WBSの各要素に担当者・期限・受入基準を追記した「WBS辞書（WBS Dictionary）」を併用する。また「責任分担マトリクス（RAM：Responsibility Assignment Matrix）」または「RACIチャート（Responsible/Accountable/Consulted/Informed）」を組み合わせることで、各ワークパッケージの実施責任と報告義務を明確化する。

Microsoft Projectでは、WBSコードを自動付番し、コスト・工数・進捗率のロールアップを親要素に自動集計できる。JIRAやAsanaでもエピック→ストーリー→タスクの階層がWBSの考え方と対応する。選択肢bの「スコープ外作業の記載」は「スコープクリープ（scope creep）」の原因となり、コスト超過・納期遅延の典型的要因であることから、変更管理プロセスを通じた正式なスコープ変更手続きを経ない限り厳に禁じられる。

試験での位置づけ

ITパスポートでは、WBSの目的（スコープ定義・工数見積もりの基礎）、100%ルール、スコープ内のみ記載するという点が繰り返し出題される。選択肢cの「全プロジェクトで同じ階層まで詳細化」は誤りで、分解の粒度はプロジェクト規模・リスク・コントロール必要度によって変える柔軟性が求められる点も要注意である。

基本情報技術者（FE）や応用情報技術者（AP）では、WBS辞書・コントロールアカウント・アーンドバリュー管理（EVM：Earned Value Management）との組み合わせで問われる。特にEVMでは、WBSの各コントロールアカウントに計画コスト（PV）・実績コスト（AC）・出来高（EV）を紐付けることでSPI（スケジュール効率指数）・CPI（コスト効率指数）を算出し、プロジェクト完成時コスト予測（EAC）に使う。この計算はITパスポートでは登場しないが、次資格への足がかりとして概念を把握しておく価値がある。

選択肢の発展補足

選択肢bの誤り「スコープ外の作業も含める」は、WBSの目的である境界明確化（何をやるか／やらないかの明示）の否定であり、プロジェクト全体の合意基準が崩れる。スコープ外の作業が必要になった場合は「変更要求（CR：Change Request）」を起票し、統合変更管理プロセスで承認を経て初めてWBSに追加される。

選択肢cの誤り「全プロジェクトで同じ階層まで」は現場では「ローリングウェーブ計画法」の観点からも成立しない。近い将来の作業は詳細に分解し、遠い将来の作業は粗く保留しておく段階的な詳細化が現実的であり、特にアジャイルとウォーターフォールを組み合わせたハイブリッド開発ではスプリントごとにWBSを更新する運用が主流である。

選択肢dの誤り「類似作業は記載しなくてよい」は工数漏れ・過小見積もりの典型的原因となる。「MECEの原則（Mutually Exclusive, Collectively Exhaustive：漏れなくダブりなく）」がWBS分解の基本指針であり、類似・繰り返し作業も漏れなく計上することが見積もり精度の前提となる。