WBSの本質
大きな仕事を、そのままでは管理できないので、成果物や作業のまとまりに分解して管理可能にします。
WBSとは何かを、PMBOKと試験と実務でつなげて理解する
WBSは、プロジェクトを管理しやすい単位まで分解するための土台です。基本情報技術者試験や応用情報技術者試験では用語として出ますが、現場では「設計書に何を書くか」「チケットをどこまで分けるか」「誰に何を任せるか」を決める実務道具として使います。このページでは、初学者が PMBOK の考え方と FE/AP の出題観点を、実際の開発作業に結び付けて理解できるように整理します。
PMBOK観点
成果物から作業を分解し、スコープを見える化する考え方を押さえます。
試験観点
100%ルール、ワークパッケージ、活動との違いを FE/AP 向けに整理します。
実務観点
設計書、レビュー、実装、テスト、チケット化まで自然につながる粒度を示します。
まず WBS とは何か
WBS は Work Breakdown Structure の略で、プロジェクト全体を上から下へ分解した構造です。目的は「作業を並べること」ではなく、「何を作るのか」「どこまでやれば終わりなのか」「抜け漏れがないか」を見える形にすることです。
現場で効く理由
担当者割当、工数見積、レビュー計画、進捗確認、チケット分割の基準が揃います。
初心者が混同しやすい点
WBSは単なる TODO リストではありません。親子関係と粒度の整合が重要です。
WBS
ワークパッケージ
100%ルール
成果物
活動定義
スコープ管理
PMBOK では WBS をどう考えるか
PMBOK では、WBS はスコープを具体化し、成果物や作業を管理可能な単位に要素分解するための重要な手段です。つまり WBS は「何となく一覧化した作業表」ではなく、スコープ管理と計画の基礎データです。
成果物から考える
最初に「何を作るのか」を定義し、その成果物を作るためのまとまりへ分解します。いきなり細かいタスクから書き始めると抜け漏れが増えます。
ワークパッケージまで落とす
分解の終点は、工数見積、担当割当、進捗管理ができる単位です。これがワークパッケージや最下位タスクに相当します。
WBS辞書とセットで考える
名前だけでは曖昧になりやすいため、完了条件、含む範囲、含まない範囲、前提条件も整理します。
基本情報・応用情報では何が問われるか
FE/AP では、WBS を暗記語句として覚えるだけでは足りません。実際には「WBS は何を分解したものか」「活動リストと何が違うか」「粒度が粗い作業名をどう見抜くか」が問われます。
基本情報で押さえる点
- WBS は作業を階層分解した構造であること
- プロジェクト計画やスコープ管理と関係すること
- 作業名や成果物の整理に使うこと
応用情報で押さえる点
- 100%ルールで抜け漏れや重複を防ぐこと
- 成果物、活動、ワークパッケージの違いを説明できること
- 粒度不一致や曖昧語を見抜けること
実務とのつながり
- 設計だけでは見積不能
- 単体テスト実施なら終わりが見える
- その差を判断する力が試験でも現場でも重要
WBSはこう分解する
下の例は、ECサイト構築を上から下へ分解したイメージです。上位は成果物や大きな機能群、下位は担当・工数・完了条件が決まる実行単位です。
ECサイト構築プロジェクト
最上位は案件全体や主要成果物のまとまりです。
会員機能
機能群や成果物単位で中分類します。ここではまだ広いです。
会員登録画面項目定義 / 会員登録API実装 / 単体テスト実施
一人が担当しやすく、終わった状態を説明できる粒度まで下ろします。
良い作業名と悪い作業名
初学者が最もつまずきやすいのは、最下位作業名の付け方です。良い作業名は、完了条件と成果物が想像できます。悪い作業名は、広すぎて見積もれません。
悪い例
- 設計
- 開発
- テスト
- 確認
- 対応
良い例
- 画面一覧作成
- API I/F一覧作成
- DB論理設計レビュー
- 単体テスト項目書作成
- 受入指摘対応
100%ルールとよくある失敗
100%ルールは、親要素に含まれる作業や成果物を漏れなく、重複なく分解する考え方です。試験でも実務でも、ここを外すとあとでタスク漏れや二重計上が発生します。
失敗1: 漏れ
「開発」はあるのに「レビュー」や「テスト」がない。後工程で想定外作業になります。
失敗2: 重複
親にも子にも同じ意味の作業があり、工数が二重になります。
失敗3: 粒度混在
`外部設計` と `API項目一覧作成` が同じ階層にあると、比較も見積もりも崩れます。
実務では WBS がどこにつながるか
WBS は学習用の概念で終わりません。要件定義、基本設計、詳細設計、チケット化、進捗管理へそのまま接続されます。ここを理解すると、試験知識が実務に変わります。
1
成果物を決める
まず、何を作るのかを決めます。例: 要件定義書、画面一覧、API一覧、テーブル定義書、テスト項目書。
2
成果物を作る作業へ分解する
画面一覧作成、API項目整理、レビュー実施のように、成果物へ結び付く作業へ分けます。
3
担当・工数・依存関係を付ける
ここまで来て初めて、誰がいつやるか、何時間かかるか、どの作業の後かが自然に決められます。
4
チケットへ落とし込む
最下位作業をそのまま開発チケットへ変換します。WBS が粗いとチケットも粗くなります。
初学者のおすすめ学習順
WBS がわからない場合は、先に用語を全部覚えるより、実例と一緒に追う方が早いです。FE/AP の学習でも、実務ベースで理解した方が問題文に強くなります。
1. 用語を整理する
WBS、WBS辞書、活動、成果物、ワークパッケージの違いを押さえます。
2. 良い分解例を見る
大分類、中分類、最下位作業のレベル差を見て、粒度感を掴みます。
3. 設計書に結び付ける
WBS を設計書の作成順やレビュー順に対応させると、実務で意味が出ます。
4. チケットへ分解する
最下位作業をチケット化してみると、曖昧な名前がすぐに見つかります。
次に触るページ
ここから先は、読むだけではなく実際に触って理解を固める段階です。WBSの考え方を、設計書整理とチケット起票に接続できます。
WBS専用アプリ
`planner` と分離した WBS 専用アプリで、プロジェクトとノードを独立管理します。
設計書作成補助
要件定義書、基本設計書、詳細設計書の観点から成果物を整理します。WBSの親ノード設計に向いています。
DevQA ダッシュボード
分解した作業を開発チケットや確認項目として管理する入口です。WBSを実行可能な単位へ変換する段階に使います。
開発チケット起票
最下位作業をそのままチケットへ落とし込み、実装・レビュー・テスト単位に変換します。