WBSとは？作り方や分解のコツ、ガントチャートとの違いを初心者向けに解説

はじめに

プロジェクト管理やシステム開発について学んでいると、WBSという言葉が登場します。

WBSは、プロジェクトの目標を達成するために必要な成果物や作業を、管理しやすい大きさまで階層的に分解したものです。

システム開発、Webサイト制作、イベント開催、製品開発など、複数の作業が関係するプロジェクトでは、最初から細かな作業をすべて把握するのは簡単ではありません。

必要な作業が漏れていれば、プロジェクトの途中で追加対応が発生し、納期や費用へ影響する可能性があります。

反対に、作業を細かく分けすぎると、WBSの作成や更新に時間がかかり、管理そのものが目的になってしまいます。

初めてWBSについて学ぶ方にとっては、

• WBSは単なるタスク一覧なのか
• WBSでは成果物と作業のどちらを分解するのか
• どの程度まで細かく分解すればよいのか
• ワークパッケージとは何か
• WBS番号にはどのような意味があるのか
• WBSを作れば日程や担当者まで決まるのか
• ガントチャートとは何が違うのか
• PERT図やマインドマップとは何が違うのか
• アジャイル開発でもWBSを使えるのか

といった点が分かりにくいのではないでしょうか。

WBSを一言で表すと、

「プロジェクトで必要な成果物や作業を、漏れなく管理できる大きさまで階層的に分解した構造」

です。

WBSの主な目的は、プロジェクトに必要な作業の範囲を明確にすることです。

WBSを作成した後に、作業の順番や依存関係を整理し、期間や担当者を設定してガントチャートなどへ展開します。

この記事では、WBSの意味、基本構成、作り方、分解の考え方、ワークパッケージ、ガントチャート・PERT図との違いについて、AさんとBさんの会話を中心に初心者向けにわかりやすく解説します。

WBSとは？

WBSは、プロジェクトで必要な成果物や作業を、大きな単位から小さな単位へ階層的に分けたものだよ。

やることを箇条書きにしたタスク一覧とは違うの？

似ているけれど、WBSでは作業同士の親子関係を整理するんだ。どの作業が、どの大きな成果物の一部なのかが分かるようにするよ。

WBSは、Work Breakdown Structureの略です。

日本語では、一般的に次のように訳されます。

• 作業分解構成図
• 作業分解構造
• 作業分解図

言葉を分けて考えると、意味を理解しやすくなります。

つまりWBSは、プロジェクトを構成する成果物や作業を分解し、階層構造として整理したものです。

WBSを旅行準備で例えてみよう

旅行の準備で考えてみよう。

旅行へ行くためには、さまざまな準備が必要です。

思いついた順番に、

• ホテルを予約する
• 荷物を詰める
• 電車を予約する
• 観光地を調べる
• 必要な物を買う

と並べるだけでもタスク一覧になります。

しかし、作業が増えると、どの準備に関係する作業なのか分かりにくくなります。

そこで、旅行準備を大きな単位から分解します。

旅行準備
├─ 交通手段
│  ├─ 行きの電車を予約する
│  └─ 帰りの電車を予約する
├─ 宿泊
│  ├─ ホテルを探す
│  └─ ホテルを予約する
├─ 観光
│  ├─ 観光地を調べる
│  └─ 観光ルートを作る
└─ 荷物
   ├─ 持ち物一覧を作る
   ├─ 不足品を購入する
   └─ 荷物を詰める

このように整理すると、旅行準備全体を構成する項目と、その内訳が分かります。

単にやることを並べるのではなく、交通、宿泊、観光のように分類して分解するんだね。

そう。大きなまとまりを少しずつ分けて、管理できる大きさへするのがWBSだよ。

WBSの主な目的

WBSを作る主な目的は、プロジェクトの作業範囲を明確にすることです。

具体的には、次の目的があります。

• 必要な成果物や作業を洗い出す
• 作業の漏れや重複を防ぐ
• プロジェクトの範囲を明確にする
• 作業量や費用を見積もりやすくする
• 担当者を決めやすくする
• 日程を作りやすくする
• 進捗を管理しやすくする
• 関係者の認識をそろえる

必要な作業を洗い出す

プロジェクトの目標だけを見ても、具体的に何を行えばよいかは分かりません。

例えば、「Webサイトを公開する」という目標には、次のような作業が含まれます。

• 要件を確認する
• 画面を設計する
• 文章を作成する
• プログラムを開発する
• テストする
• サーバーを準備する
• 本番環境へ公開する

WBSを使って分解すると、目標達成に必要な作業を具体化できます。

作業の漏れを防ぐ

作業は、プロジェクトを進めながら考えてもいいんじゃないの？

途中で分かる作業もあるけれど、最初にできるだけ整理しておけば、急な追加作業を減らせるよ。

例えば、Webサイトの画面作成だけを考えていて、次の作業を忘れていたとします。

• セキュリティテスト
• 利用規約の確認
• バックアップ設定
• 操作マニュアルの作成
• 利用者への案内

プロジェクト終盤で作業漏れに気づくと、公開日を延期しなければならない可能性があります。

WBSを関係者と確認することで、作業漏れへ早く気づきやすくなります。

プロジェクトの範囲を明確にする

プロジェクトで実施する作業を明確にすると、何が対象で、何が対象外なのかを判断しやすくなります。

これをスコープの明確化と呼びます。

例えば、社内システムを開発するプロジェクトで、WBSに次の作業が含まれているとします。

• パソコン向け画面の開発
• 社内ネットワーク内での利用
• 操作マニュアルの作成

スマートフォン対応や社外からのアクセス対応が含まれていなければ、それらは現在のプロジェクト範囲外と判断できます。

ただし、WBSに書かれていないから不要と決めつけるのではなく、関係者と合意して範囲を確定する必要があります。

見積りの基礎になる

「Webサイトを作る」という大きな単位では、必要な期間や費用を正確に見積もるのが難しくなります。

そこで、次のように分解します。

• トップページを作る
• 商品一覧ページを作る
• 商品詳細ページを作る
• 問い合わせフォームを作る
• テストする

小さな単位に分ければ、それぞれに必要な時間や担当者を見積もりやすくなります。

それらを合計することで、プロジェクト全体の見積りを作れます。

WBSの基本構成

WBSは、一般的に上位から下位へ階層的に分解します。

プロジェクト全体
    ↓
主要な成果物・大分類
    ↓
中分類
    ↓
小分類
    ↓
管理可能な作業単位

例えば、Webサイト制作では次のように整理できます。

Webサイト制作
├─ 1．企画
│  ├─ 1.1 目的整理
│  ├─ 1.2 対象読者の整理
│  └─ 1.3 掲載内容の決定
├─ 2．設計
│  ├─ 2.1 サイト構成設計
│  ├─ 2.2 画面設計
│  └─ 2.3 デザイン作成
├─ 3．開発
│  ├─ 3.1 トップページ作成
│  ├─ 3.2 下層ページ作成
│  └─ 3.3 問い合わせ機能作成
├─ 4．テスト
│  ├─ 4.1 表示確認
│  ├─ 4.2 動作確認
│  └─ 4.3 セキュリティ確認
└─ 5．公開
   ├─ 5.1 本番環境設定
   ├─ 5.2 データ移行
   └─ 5.3 公開確認

最上位にはプロジェクト全体を置き、その下に主要な成果物や作業を配置します。

さらに、その内容を管理できる大きさまで分解していきます。

成果物型WBSと作業型WBS

WBSの分け方には、主に次の考え方があります。

• 成果物を中心に分解する
• 作業や工程を中心に分解する

成果物を中心に分解する

成果物型WBSでは、完成させる物を中心に分解します。

例えば、Webサイトを次のように分けます。

Webサイト
├─ トップページ
├─ 商品一覧ページ
├─ 商品詳細ページ
├─ 問い合わせフォーム
└─ 操作マニュアル

成果物を中心にすると、何を完成させる必要があるかを確認しやすくなります。

作業や工程を中心に分解する

作業型WBSでは、実施する工程や活動を中心に分解します。

Webサイト制作
├─ 要件定義
├─ 設計
├─ 開発
├─ テスト
└─ 公開

作業の流れを理解しやすい反面、成果物ごとの漏れが見えにくくなる場合があります。

どちらを使えばよい？

成果物型と作業型では、どちらが正しいの？

一つだけが正しいわけではないよ。プロジェクトの内容や管理目的に合わせて選ぶんだ。

成果物を明確にする必要がある場合は、成果物型が向いています。

工程や部門ごとに管理したい場合は、作業型が分かりやすいことがあります。

実務では、上位階層を成果物で分け、その下を作業で分解するなど、両方を組み合わせることもあります。

ワークパッケージとは？

WBSを分解した最下位の管理単位を、ワークパッケージと呼びます。

ワークパッケージは、担当者、期間、費用、成果などを管理できる大きさにした作業や成果物です。

例えば、次のWBSを考えます。

問い合わせ機能
├─ 入力画面を作成する
├─ 入力内容を確認する画面を作成する
├─ メール送信機能を作成する
└─ 動作テストを行う

このうち、それぞれを担当者へ割り当て、完了を確認できるのであれば、ワークパッケージとして扱えます。

ワークパッケージに必要な情報

ワークパッケージには、次のような情報を持たせることがあります。

• 作業名
• 作業内容
• 成果物
• 完了条件
• 担当者
• 必要な工数
• 必要な費用
• 開始予定日
• 終了予定日
• 前提条件
• 依存する作業
• リスク

ワークパッケージとタスクの違い

ワークパッケージを、さらに実際の行動へ分けたものをタスクやアクティビティと呼ぶ場合があります。

例えば、ワークパッケージが「問い合わせ入力画面の作成」であれば、次のタスクへ分けられます。

• HTMLを作成する
• 入力欄を配置する
• 入力チェックを実装する
• レビューする
• 修正する

ただし、組織や管理ツールによって用語の使い方は異なります。

ワークパッケージとタスクをほぼ同じ意味で扱う場合もあります。

WBS番号とは？

WBS番号とは、各項目の階層や位置を識別するための番号です。

例えば、次のように付けます。

1       Webサイト制作
1.1     企画
1.1.1   目的整理
1.1.2   対象読者の整理
1.2     設計
1.2.1   サイト構成設計
1.2.2   画面設計
1.3     開発
1.3.1   トップページ作成

WBS番号を見ることで、その項目がどの上位項目に属しているか分かります。

WBS番号を付けるメリット

• 作業を識別しやすい
• 親子関係を確認しやすい
• 会議や資料で指定しやすい
• ガントチャートや課題管理表と連携しやすい
• 項目名が似ていても区別できる

WBS番号は作業の順番を表しているの？

必ずしも実施順ではないよ。基本的には階層上の位置を識別する番号なんだ。

1.2の作業が、必ず1.1の後に実施されるとは限りません。

作業の実施順や依存関係は、別途整理する必要があります。

WBSはどこまで細かく分解する？

WBS作成で難しいのが、分解する細かさです。

大きすぎると管理できず、細かすぎると更新の負担が大きくなります。

大きすぎる作業の例

次のような項目は、範囲が広すぎる可能性があります。

• システムを作る
• テストする
• 資料を作る
• デザインする

「テストする」だけでは、何をどこまで確認するのか分かりません。

例えば、次のように分けられます。

テスト
├─ 単体テスト
├─ 結合テスト
├─ システムテスト
├─ 性能テスト
└─ セキュリティテスト

細かすぎる作業の例

反対に、次のような単位までWBSへ載せると、管理が細かすぎる場合があります。

• パソコンを起動する
• ファイルを開く
• メールを書く
• 会議室へ移動する

これらは日常の行動であり、プロジェクトの成果物や進捗を管理する単位としては細かすぎる可能性があります。

分解を止める判断基準

次の情報を決められる程度まで分解できたら、一つの目安になります。

• 担当者を決められる
• 必要な期間を見積もれる
• 費用を見積もれる
• 完了したか判断できる
• 進捗を確認できる
• 成果物を説明できる

何日以内の作業にすればよい、という決まりはあるの？

すべてのプロジェクトに共通する絶対的な日数はないよ。管理目的に合わせて決めるんだ。

短いプロジェクトでは数時間から数日、長期プロジェクトでは数日から数週間を一つの単位にすることがあります。

8/80ルールとは？

WBSのワークパッケージを分解する目安として、8/80ルールが紹介されることがあります。

これは、一つのワークパッケージを、

• 8時間以上
• 80時間以下

程度にするという考え方です。

つまり、1日より短すぎず、約2週間より長すぎない作業単位を目安にします。

ただし、8/80ルールは絶対的な決まりではありません。

プロジェクトの期間、管理方法、作業内容によって適切な単位は変わります。

重要なのは、担当者が進捗と完了を管理できる大きさにすることです。

100％ルールとは？

WBSを作るときの重要な考え方として、100％ルールがあります。

100％ルールとは、上位項目を完成させるために必要な範囲を、その下位項目がすべて含んでいる状態にする考え方です。

例えば、上位項目が「Webサイト公開」であれば、その達成に必要な作業を下位項目へすべて含めます。

Webサイト公開
├─ 要件整理
├─ 設計
├─ コンテンツ作成
├─ 開発
├─ テスト
└─ 本番公開

必要な「テスト」が抜けていれば、上位項目の100％を表していません。

重複も避ける

100％ルールでは、漏れを防ぐだけでなく、下位項目同士の重複を避けることも大切です。

同じ作業を複数の項目へ含めると、工数や費用を二重に計算する可能性があります。

WBSの作り方

ここからは、WBSを作成する基本的な流れを解説します。

1．プロジェクトの目的を確認する

最初に、プロジェクトで何を達成するのかを明確にします。

例えば、

• 会社のWebサイトを公開する
• 新しい勤怠管理システムを導入する
• 展示会を開催する
• 新商品を発売する

といった目標です。

目標が曖昧なままでは、必要な作業も判断できません。

2．最終成果物を明確にする

プロジェクト終了時に、何が完成していれば成功なのかを整理します。

Webサイト制作であれば、次のような成果物があります。

• 公開されたWebサイト
• デザインデータ
• ソースコード
• テスト結果
• 操作マニュアル
• 運用手順書

3．大きな成果物や工程へ分ける

プロジェクト全体を、主要なまとまりへ分けます。

Webサイト制作
├─ 企画
├─ 設計
├─ 開発
├─ テスト
└─ 公開

この段階では、細かくしすぎず、プロジェクト全体を見渡せる分類にします。

4．下位の成果物や作業へ分解する

それぞれの項目を、さらに具体的な作業へ分解します。

開発
├─ トップページ作成
├─ 商品一覧ページ作成
├─ 商品詳細ページ作成
└─ 問い合わせフォーム作成

5．管理可能な大きさまで分解する

担当者、期間、費用、完了条件を決められる大きさまで分解します。

分解後の最下位単位がワークパッケージです。

6．漏れと重複を確認する

100％ルールを意識して、必要な作業がすべて含まれているか確認します。

同じ作業を複数の場所へ入れていないかも確認します。

7．関係者と確認する

WBSは、プロジェクトマネージャーが一人で作ればよいとは限りません。

実際に作業する担当者、利用者、顧客、専門家などと確認します。

担当者にしか分からない作業や前提条件があるためです。

8．WBS番号を付ける

階層関係を識別しやすいように、番号を付けます。

9．必要な情報を追加する

WBSを一覧表として管理する場合は、次のような項目を追加します。

• WBS番号
• 作業名
• 成果物
• 担当者
• 工数
• 費用
• 完了条件
• 備考

10．ガントチャートや日程表へ展開する

WBSで必要な作業を整理した後、次の情報を決めます。

• 作業の順番
• 依存関係
• 担当者
• 必要な期間
• 開始日
• 終了日

これらをガントチャートなどへ配置し、スケジュールを作成します。

WBSを表形式で作る例

WBSは、階層図だけでなく、表形式でも作成できます。

実務では、さらに担当者、期間、工数、進捗率などを追加する場合があります。

ただし、WBS本来の中心は作業範囲と階層構造です。

日程管理の情報を追加すると、ガントチャートや作業管理表に近い形式になります。

WBS辞書とは？

WBS辞書とは、WBSの各項目について、詳しい内容を説明する資料です。

WBS上の作業名だけでは、具体的な範囲や完了条件を十分に伝えられない場合があります。

例えば、「テスト」という項目だけでは、次の点が分かりません。

• 何をテストするのか
• どの環境で実施するのか
• 誰が担当するのか
• どの条件を満たせば完了なのか
• どの成果物を残すのか

そこで、WBS辞書に詳細を記載します。

WBSとタスク一覧の違い

タスク一覧は、実施する作業を並べた一覧です。

WBSは、作業を階層的に整理し、全体と部分の関係を明確にします。

タスク一覧を階層化すれば、WBSになるの？

近い形にはなるけれど、プロジェクト全体の範囲を100％表しているか、成果物との関係が整理されているかも重要だよ。

WBSとガントチャートの違い

WBSとガントチャートは、プロジェクト管理で一緒に使われることが多い道具です。

WBSは、プロジェクトで何を行うかを整理します。

ガントチャートは、整理した作業をいつ行うかという時間軸へ配置します。

WBSに開始日や終了日を書いたものがガントチャートなの？

WBSの作業を時間軸へ並べて横棒で表すと、ガントチャートに近い形になるよ。ただし、目的は区別して考えよう。

WBSとPERT図の違い

PERT図は、作業の順番や依存関係をネットワーク状に表す図です。

WBSでは作業の親子関係を表しますが、作業を実施する順番は基本的に表しません。

例えば、WBSでは次のような関係を表します。

Webサイト制作
├─ 設計
├─ 開発
└─ テスト

PERT図では次のような順番を表します。

設計 → 開発 → テスト

WBSの上下は親子関係で、PERTの矢印は作業順なんだね。

その違いは試験でも重要だよ。

WBSとガントチャート・PERT図の使い分け

三つの道具を使う流れは、次のように整理できます。

プロジェクトの目的を決める
        ↓
WBSで必要な作業を分解する
        ↓
作業の順番や依存関係を整理する
        ↓
必要に応じてPERT図で分析する
        ↓
ガントチャートへ日程を配置する
        ↓
予定と実績を管理する

WBSとOBSの違い

OBSは、Organization Breakdown Structureの略です。

組織や責任体制を階層的に整理した構造を表します。

WBSとOBSを対応させることで、各作業をどの部署が担当するか整理できます。

WBSとRACIチャートの違い

RACIチャートは、作業に対する関係者の役割を整理する表です。

RACIは、次の四つの役割を表します。

• Responsible：実行責任者
• Accountable：最終責任者
• Consulted：相談先
• Informed：報告先

WBSとバックログの違い

プロダクトバックログは、プロダクトを改善するために必要な項目を、優先順位付きで管理する一覧です。

WBSとバックログは似ていますが、目的と管理方法が異なります。

WBSはアジャイル開発でも使える？

WBSはウォーターフォール開発で使うものなの？

ウォーターフォール型のプロジェクトでよく使われるけれど、アジャイル開発でまったく使えないわけではないよ。

アジャイル開発では、将来の作業を最初から詳細に固定しすぎると、変更へ対応しにくくなります。

そのため、プロジェクト開始時にすべての作業を細かく分解するより、次のように使う方法があります。

• 大きな成果物やリリース単位だけをWBSで整理する
• 近い期間の作業だけを詳細化する
• 詳細な開発項目はプロダクトバックログで管理する
• 外部契約や環境準備などをWBSで管理する
• 複数チームにまたがる作業をWBSで整理する

WBSを作るメリット

作業の全体像を把握できる

プロジェクト全体と個々の作業の関係が見えるようになります。

作業の漏れを防ぎやすい

上位成果物を達成するために必要な作業がそろっているか確認できます。

見積りの精度を高めやすい

大きな作業を小さく分解することで、期間や費用を考えやすくなります。

担当者を決めやすい

作業単位が具体的になるため、誰へ割り当てるか判断しやすくなります。

進捗を確認しやすい

大きな作業だけを管理する場合より、どの部分が完了しているか確認しやすくなります。

関係者の認識をそろえやすい

プロジェクトで何を行うのかを一覧化することで、顧客、担当者、管理者の認識を合わせやすくなります。

変更の影響を確認しやすい

新しい作業が追加されたとき、どの成果物や作業へ影響するかを考えやすくなります。

WBSを作るデメリット・注意点

作成に時間がかかる

大規模プロジェクトでは、必要な作業を分解して確認するだけでも多くの時間が必要です。

細かく分けすぎると管理負担が増える

項目数が多すぎると、更新や進捗確認に時間がかかります。

最初からすべてを把握できるとは限らない

新しい技術を使うプロジェクトや、要件が変化しやすい案件では、開始時点ですべての作業を正確に洗い出せない場合があります。

WBS作成が目的になりやすい

見栄えのよいWBSを作ることへ時間を使いすぎると、本来のプロジェクト管理がおろそかになります。

更新しなければ実態と合わなくなる

プロジェクトの範囲や成果物が変更された場合は、WBSも見直す必要があります。

作業の順番や期間は分からない

WBSだけでは、いつ、どの順番で作業するかは分かりません。

ガントチャートやPERT図などと組み合わせます。

WBS作成でよくある失敗

作業の粒度がそろっていない

次のようなWBSでは、項目の大きさが大きく異なります。

システム開発
├─ 要件定義
├─ 基本設計
├─ ログインボタンを作る
└─ テスト

「基本設計」や「テスト」は大きな作業ですが、「ログインボタンを作る」は細かな作業です。

同じ階層では、できるだけ同程度の粒度にそろえると理解しやすくなります。

作業名が曖昧

次のような作業名は、何を完成させればよいか分かりにくくなります。

• 検討
• 対応
• 確認
• 調整
• 開発

例えば、「設計を確認する」ではなく、「画面設計書をレビューし、承認を得る」のように具体化します。

担当者ごとに分解してしまう

WBSは、基本的に成果物や作業を分解するものです。

最初から、

• 営業担当の作業
• 開発担当の作業
• テスト担当の作業

と担当部署だけで分けると、成果物の全体像が分かりにくくなる場合があります。

まず必要な成果物や作業を整理し、その後に担当者を割り当てます。

時系列で並べるだけになる

WBSは作業の実施順を表すものではありません。

単に、

1. 要件定義
2. 設計
3. 開発
4. テスト

と並べただけでは、各作業の内訳や階層が十分に分かりません。

管理作業を忘れる

成果物を作る作業だけでなく、次のような管理作業が必要になる場合があります。

• プロジェクト計画
• 進捗管理
• 品質管理
• リスク管理
• 会議
• 変更管理
• 顧客報告
• 契約や調達

ただし、定例会議を一回ずつ細かく分けるなど、管理過多にならないよう注意します。

テストや移行作業を忘れる

開発物だけに注目すると、次の作業が抜けることがあります。

• テスト
• データ移行
• 利用者教育
• マニュアル作成
• 本番環境設定
• 運用引継ぎ
• 旧システムの停止

プロジェクトを完了させるために必要な作業を、最後まで考えることが重要です。

WBSを一度作って放置する

プロジェクトの範囲が変更された場合は、WBSも見直します。

承認された変更を反映せずに放置すると、実際の作業と計画が一致しなくなります。

WBSをうまく作るポイント

成果物から考える

「何をするか」だけでなく、「何が完成すればよいか」を考えます。

成果物が明確になると、完了条件も決めやすくなります。

関係者と一緒に作る

実際の作業担当者を交えることで、作業漏れや現実的でない分解に気づきやすくなります。

同じ階層の粒度をそろえる

上位項目と細かなタスクを同じ階層へ混在させないようにします。

完了を判断できる表現にする

「検討する」だけではなく、何を作成・承認すれば完了なのかを示します。

必要以上に細かくしない

管理に必要な細かさを超えて分解すると、維持できなくなります。

漏れと重複を確認する

100％ルールを意識し、上位項目の範囲が下位項目に含まれているか確認します。

WBS辞書を併用する

作業名だけで範囲を説明できない場合は、WBS辞書へ詳細を記載します。

定期的に見直す

プロジェクトの変更に合わせてWBSを更新します。

ただし、承認なしに範囲を増やすのではなく、変更管理の手順に従います。

WBSが向いている場面

WBSは、次のような場面で特に役立ちます。

• 複数の成果物がある
• 多くの作業が関係する
• 複数の担当者や部署が参加する
• 見積りや予算管理が必要
• 作業漏れを防ぎたい
• 明確な完了条件が必要
• 顧客と作業範囲を共有したい

代表例は次のとおりです。

• システム開発
• Webサイト制作
• 建設工事
• 製品開発
• イベント開催
• 店舗開店
• オフィス移転
• 新サービスの開始
• 資格取得の学習計画

WBSが向いていない可能性がある場面

次のような場合は、詳細なWBSを作る効果が小さいことがあります。

• 一人で短時間に完了する
• 作業内容が単純で明確
• 毎日同じ作業を繰り返す
• 作業の優先順位が頻繁に変わる
• 事前に作業内容をほとんど予測できない
• WBSの更新費用が成果を上回る

このような場合は、単純なチェックリスト、タスク一覧、カンバンボードなどの方が管理しやすいことがあります。

ITパスポート・基本情報・応用情報の試験対策

WBSは、プロジェクトマネジメント分野の重要用語です。

情報処理技術者試験では、単語の正式名称だけでなく、ガントチャートやPERT図との違いを理解しておくことが重要です。

試験別に押さえたい内容

試験で覚えたい重要用語

試験問題で注目する表現

類似用語の試験対策比較

よくある誤解

WBSは単なるタスク一覧である

やることを箇条書きにすればWBSになるの？

タスクを並べるだけではなく、全体と部分の親子関係を整理することが重要だよ。

WBSでは、プロジェクト全体を階層的に分解し、どの作業がどの成果物に関係しているかを明確にします。

WBSは作業順を表す

WBS番号や上下の位置は、基本的に階層関係を表します。

作業を実施する順番は、PERT図やガントチャートなどで整理します。

WBSには開始日と終了日を必ず書く

WBSの中心は、成果物や作業の分解構造です。

開始日や終了日を追加することはありますが、時間軸はWBSの必須要素ではありません。

WBSを細かくするほど管理しやすい

細かくしすぎると、作成や更新の負担が増えます。

担当者、期間、費用、完了条件を管理できる大きさで分解を止めることが重要です。

WBSはプロジェクトマネージャーが一人で作る

プロジェクトマネージャーが中心になることはありますが、実際の担当者や専門家と確認する必要があります。

一人では気づけない作業やリスクがあるためです。

WBSを作れば作業漏れは完全になくなる

WBSは作業漏れを減らすために役立ちますが、未知の作業まで完全に予測できるわけではありません。

プロジェクトの進行や変更に応じて見直します。

WBSを作ればスケジュールも完成する

WBSでは、何を行うかを整理します。

作業の順番、期間、依存関係、担当者などを検討し、ガントチャートなどへ展開する必要があります。

同じ階層に異なる大きさの項目があっても問題ない

粒度が大きく異なると、全体構造や進捗が分かりにくくなります。

同じ階層では、可能な範囲で同程度の大きさへそろえます。

担当部署ごとに分ければWBSになる

担当部署で分けた構造はOBSに近くなる場合があります。

WBSでは、まず成果物や作業を分解し、その後に担当部署を割り当てるのが基本です。

WBSはウォーターフォール開発でしか使えない

WBSはウォーターフォール型のプロジェクトでよく使われますが、アジャイル開発でも大きな成果物、リリース準備、環境構築などの整理に利用できます。

ただし、将来の詳細作業を過度に固定しないよう注意します。

WBSは一度作れば変更してはいけない

承認されたプロジェクト範囲の変更があれば、WBSも更新します。

ただし、勝手に項目を増やすのではなく、変更による納期や費用への影響を確認します。

まとめ

WBSとは、プロジェクトで必要な成果物や作業を、漏れなく管理できる大きさまで階層的に分解した構造です。

WBSは、Work Breakdown Structureの略で、日本語では作業分解構成図や作業分解構造などと呼ばれます。

WBSを作ることで、プロジェクトの全体像を把握し、作業の漏れや重複を防ぎやすくなります。

また、作業を管理可能な大きさへ分けることで、必要な工数、費用、担当者、期間を見積もりやすくなります。

WBSの最下位にある管理単位を、ワークパッケージと呼びます。

ワークパッケージは、担当者、期間、費用、成果物、完了条件などを管理できる大きさにします。

WBSを作るときは、上位項目の範囲を下位項目がすべて含むようにする100％ルールを意識します。

ただし、細かく分解すればするほどよいわけではありません。

管理できる大きさになった時点で分解を止め、必要に応じてWBS辞書で詳細を補足します。

WBSと混同されやすいものに、ガントチャートとPERT図があります。

WBSは何を行うかを整理し、PERT図はどの順番で行うかを分析し、ガントチャートはいつ行うかを管理します。

最後に要点を整理します。

WBSは、プロジェクトでやることを階層的に分解したものなんだね。

そう。大きな成果物から小さな成果物や作業へ分けて、全体と部分の関係を明確にするんだ。

一番細かい管理単位が、ワークパッケージなんだね。

そう。担当者や期間、完了条件を決められる大きさにするよ。

WBS番号は作業順ではなく、階層上の位置を表しているんだね。

そう。実施順や依存関係はPERT図、日程はガントチャートで整理するよ。

WBSで何をするかを分け、PERTで順番を確認し、ガントチャートでいつ行うかを決めるんだね。

バッチリ。まず必要な作業を漏れなく整理することが、現実的な計画を作る第一歩なんだ。

クマノくらげ

X

難しいIT用語やビジネス用語を、できるだけ身近な例えで解説するブログです。 「専門用語を見ると眠くなる人」でも読めるように、画像や会話形式を多めにしています。 AWS12冠達成済み。