WBSの作り方｜システム開発の実例表と分解を止める判断基準

WBS（Work Breakdown Structure：作業分解構成図）とは、プロジェクトで作るべき成果物と作業の「全体」を、階層的に分解して一覧にしたものです。 「何を作れば完了なのか」を漏れなく洗い出し、見積もり・担当割り当て・スケジュール・進捗管理の土台にします。

WBSの解説記事は、Webサイトのリニューアルや住宅建設を例にしたものが多く見られます。この記事では、システム開発案件（要件定義〜リリース）のWBSを、階層番号つきの表でそのまま示します。さらに「どこまで分解すればよいか」を決める判断基準チェックリスト、WBS辞書の記入例、ガントチャートとの違い（Mermaid図）、CSVで作ったWBSを機械的にチェックするPythonスクリプト（実行結果つき）まで、実務でそのまま使える形でまとめました。

WBSの作り方の早見表

WBSとは：3つの基本ルール

WBSは、プロジェクト全体を木の形に分けたものです。最上位が「プロジェクト全体」、その下に大きな単位、さらにその下に小さな単位……と続き、最下層の単位を「ワークパッケージ」と呼びます。ワークパッケージが、見積もり・担当・進捗管理の単位になります。

WBSを作るときに押さえたい基本ルールは、次の3つです。

100%ルールは、WBSでいちばん大切な考え方です。親「3.1 基本設計」の子を全部足したら、基本設計でやるべきことが過不足なく揃っている状態を目指します。

PMBOKでの位置づけ（版ごとの違い）

WBSはPMI（米国プロジェクトマネジメント協会）のPMBOK®ガイドで体系化されています。版によって説明の仕方が変わっているので、整理しておきます。

第7版以降は、アジャイルではWBSの代わりにプロダクトバックログなどで範囲を表すことも明記されるようになりました。要件をある程度先に固めるシステム開発案件では、今もWBSがよく使われます。

システム開発のWBS実例（要件定義〜リリース）

ここでは架空の「社内の備品貸出システム」（社員がPCやプロジェクターを借りて返す仕組み）を、約3か月で構築する案件を例にします。第1階層はフェーズ、第2階層以下は成果物で分けています。

flowchart TD
    P["0 備品貸出システム構築"]
    P --> A["1 プロジェクト管理"]
    P --> B["2 要件定義"]
    P --> C["3 設計"]
    P --> D["4 開発・単体テスト"]
    P --> E["5 テスト"]
    P --> F["6 移行・リリース"]
    C --> C1["3.1 基本設計"]
    C --> C2["3.2 詳細設計"]
    C1 --> C11["3.1.1 画面設計書"]
    C1 --> C12["3.1.2 ER図・テーブル定義"]
    C1 --> C13["3.1.3 API一覧"]

※WordPressでMermaidの図を表示するには、Mermaid対応のプラグインが必要です。

階層番号つきWBS表

この表は、あえて直すべき箇所を残した「初版」です。3.2（120h）と4.2（96h）は大きすぎ、4.3（4h）は小さすぎます。次の章の判断基準で、どう直すかを見ていきます。

第1階層は「フェーズ型」と「成果物型」のどちらにするか

迷ったら、第1階層はフェーズ型、第2階層以下は成果物型にすると、契約・報告の単位と作業の単位の両方が見やすくなります。

分解を止める判断基準チェックリスト

「どこまで細かくするか」は、WBS作りでいちばん迷うところです。よく知られた目安に8/80ルールがあります。1つのワークパッケージを8時間以上・80時間以下に収める、という経験則です。ただし時間だけで決めると、実務では判断がぶれます。次のチェックリストで、全部に「はい」と言えたら分解を止めます。

「進捗が測れるか」（4と5）がとくに重要です。 120時間の「詳細設計」は、3週間たっても「60%くらいです」という自己申告でしか進捗がわかりません。機能ごとに分ければ、「5本中3本がレビュー済み」と事実で報告できます。

初版を判断基準で直した結果

4.3のように極端に小さい数字は、分解の問題ではなく見積もり漏れのサインであることもあります。数字だけを見て統合せず、中身を確認しましょう。

Excel（CSV）で作ったWBSを機械的にチェックする

WBSをExcelで作る場合、列は「WBS番号」「名称」「成果物」「担当」「見積(h)」「開始」「終了」「完了条件」の8列程度にしておくと、そのままスケジュールや進捗管理に広げられます。WBS番号は文字列として入力します（「3.10」が数値の「3.1」に変わるのを防ぐため）。

作ったWBSをCSVで保存すれば、簡単なスクリプトで次の点を自動チェックできます。

• 親の番号が存在するか（番号の付け間違い）
• 最下層（ワークパッケージ）に工数が入っているか
• 8/80ルールから外れていないか
• 第1階層ごとの工数合計

import csv

rows = list(csv.DictReader(open("wbs.csv", encoding="utf-8")))
ids = {r["id"] for r in rows}

def is_leaf(i):
    return not any(x.startswith(i + ".") for x in ids)

for r in rows:
    i = r["id"]
    parent = i.rsplit(".", 1)[0] if "." in i else None
    if parent and parent not in ids:
        print(f"[親なし] {i}")
    if is_leaf(i):
        h = float(r["hours"] or 0)
        if h == 0:
            print(f"[工数未入力] {i} {r['name']}")
        elif h < 8:
            print(f"[小さすぎ {h:g}h] {i} {r['name']} → 親や隣と統合を検討")
        elif h > 80:
            print(f"[大きすぎ {h:g}h] {i} {r['name']} → さらに分解を検討")

def total(i):
    if is_leaf(i):
        return float(next(r for r in rows if r["id"] == i)["hours"] or 0)
    kids = [x for x in ids if x.startswith(i + ".") and x.count(".") == i.count(".") + 1]
    return sum(total(k) for k in kids)

for top in sorted(x for x in ids if "." not in x):
    print(f"{top}: {total(top):g}h")
print("合計:", sum(total(t) for t in ids if "." not in t), "h")

wbs.csv には、上の「初版」の表を id,name,hours の3列で保存しました（親の行は hours を空欄）。Python 3.11で実行した結果です。

[大きすぎ 120h] 3.2 詳細設計 → さらに分解を検討
[大きすぎ 96h] 4.2 貸出機能の実装・単体テスト → さらに分解を検討
[小さすぎ 4h] 4.3 備品管理機能の実装・単体テスト → 親や隣と統合を検討
1: 54h
2: 96h
3: 256h
4: 112h
5: 144h
6: 48h
合計: 710.0 h

時間の基準は機械で、担当・レビュー・測定の基準は人の目で確認する、という分担にすると、レビューが速くなります。

WBS辞書の書き方

WBS辞書とは、WBSの各要素（主にワークパッケージ）の中身を定義した補足資料です。 WBS表の1行だけでは「どこまでやれば完了か」が人によって変わるため、辞書で言葉をそろえます。

全ワークパッケージの辞書を最初から書くのが大変なら、「範囲外」と「完了条件」の2項目だけでも先に埋めると効果があります。

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

WBSとガントチャートはよく混同されますが、役割が違います。

WBSのワークパッケージに「順序（前後関係）」「期間」「担当」を足したものがガントチャートだと考えるとわかりやすいです。上のWBSの一部をMermaidのガントチャートにすると、次のようになります。

gantt
    title 備品貸出システム構築（抜粋）
    dateFormat YYYY-MM-DD
    axisFormat %m/%d
    excludes weekends
    section 2 要件定義
    2.2 要件定義書作成       :req, 2026-10-05, 8d
    2.3 要件定義レビュー     :rev, after req, 2d
    section 3 設計
    3.1.1 画面設計書         :ui, after rev, 6d
    3.1.2 ER図・テーブル定義 :er, after rev, 5d
    3.1.4 基本設計レビュー   :crit, brev, after ui er, 2d
    section マイルストーン
    基本設計 承認            :milestone, after brev, 0d

after ui er と書くと「3.1.1と3.1.2の両方が終わってから開始」という前後関係を表せます。タスク名にWBS番号を残しておくと、ガントチャートの棒からWBS辞書へたどれるので便利です。

WBSを見積もり・進捗管理につなげる

見積もりへのつなぎ

WBSはボトムアップ見積もりの土台です。ワークパッケージごとに工数を出して合計すると、全体の工数になります。見積もりの手法そのもの（類推、パラメトリック、三点見積もりなど）は別記事に譲り、ここではWBSを見積もりに使うときの注意だけ挙げます。

• 親の行に数字を直接書かない（子の合計で自動計算する）
• 見積もりの根拠（画面数、テーブル数、テストケース数など）をWBS辞書に残す
• リスクへの備え（予備）は、各行に上乗せせず別の行として見える形で持つ

進捗管理とEVMへのつなぎ

EVM（アーンドバリュー・マネジメント）とは、進捗とコストを「計画した作業の価値」という同じものさしで測る方法です。 ワークパッケージの粒度がそろっていれば、EVMの考え方を簡単に取り入れられます。

EVを数えるときは、「完了したワークパッケージだけ100%、それ以外は0%」（0/100ルール）にすると、自己申告の「だいたい70%」に左右されません。この方法が使えるのも、ワークパッケージが報告周期に収まる大きさに分解されているからです。

よくある失敗：作業漏れしやすい項目

WBSの失敗でいちばん多いのは、「作るもの」は書いたのに「作るために必要な作業」が漏れることです。システム開発で漏れやすい項目を一覧にしました。完成したWBSと突き合わせて点検してください。

ほかにも、次のような失敗がよくあります。

ツール別の作り方

どのツールでも、正本（マスター）を1つに決めることが大切です。Excelとタスク管理ツールの両方で更新すると、どちらが正しいかわからなくなります。

AIでWBSの下書きを作るコツ

生成AIは、WBSの「たたき台」を作るのが得意です。ただし、AIはプロジェクト固有の事情を知りません。前提を渡し、出力形式を指定し、最後は人が判断するのが基本です。

あなたはシステム開発のPMです。次の案件のWBSの下書きを作ってください。

# 案件
- 社内の備品貸出システムを新規構築（Webアプリ）
- 範囲：要件定義〜本番リリース。保守は範囲外
- 期間：約3か月、体制：PM1名、SE2名、PG2名
- 既存のExcel台帳からデータ移行あり

# 出力形式
- 表形式：WBS番号 / 名称（成果物の名詞） / 成果物 / 完了条件
- 第1階層はフェーズ、第2階層以下は成果物で分解
- 最下層は8〜80時間を目安

# 必ず含めること
- 各フェーズ末のレビューと修正、環境構築、データ移行、会議・報告

# 最後に
- 漏れていそうな作業と、確認が必要な前提を箇条書きで挙げてください

AIの出力は、次の観点で見直します。

• 範囲外の作業が混ざっていないか（例：頼んでいない保守作業）
• 100%ルールと重複なしが守られているか
• 工数は、AIに出させずに担当者が見積もる（AIは前提を知らないため）
• 「漏れていそうな作業」の指摘を、チェックリストとして活用する

よくある質問

Q. WBSは何階層まで作ればよいですか？ A. 決まった数はありません。「分解を止める判断基準チェックリスト」をすべて満たしたところが最下層です。数か月規模のシステム開発なら3〜4階層に収まることが多く、規模が大きくなるほど階層が増えます。

Q. WBSとタスク一覧（ToDoリスト）は何が違いますか？ A. WBSはプロジェクトの範囲全体を100%表す階層構造で、成果物を単位にします。タスク一覧は個人やチームの作業を並べたもので、範囲全体を表すことは求められません。ワークパッケージをさらに日々の作業に分けたものがタスク一覧、と考えると整理しやすいです。

Q. アジャイル開発でもWBSは使いますか？ A. 範囲の表し方としては、プロダクトバックログ（ユーザーストーリーの一覧）を使うのが一般的です。ただし、リリース全体の準備作業（環境構築、移行、リリース判定など）を洗い出すために、第1階層だけWBSで整理し、開発部分はバックログで管理する組み合わせもよく使われます。

Q. WBSはいつ作り直せばよいですか？ A. 範囲が変わったときです。仕様変更や追加要望を受け入れたら、WBSに行を追加・削除し、WBS辞書と見積もり、ガントチャートも合わせて更新します。日程の遅れだけならWBSは変えず、ガントチャートを直します。

まとめ

• WBSは「何を作るか」の全体を、成果物単位で階層的に分解した一覧です
• 100%ルール・重複なし・成果物志向の3つが基本ルールです
• システム開発では、第1階層をフェーズ、第2階層以下を成果物で分けると扱いやすくなります
• 分解を止める基準は8/80ルールに加えて、担当・レビュー・完了判定・報告周期で判断します
• WBS辞書には最低限「範囲外」と「完了条件」を書きます
• レビュー・手戻り・環境構築・移行・会議は漏れやすいので、独立した行で置きます
• WBSは範囲、ガントチャートは日程。WBS番号でつなぐと進捗管理やEVMに広げられます

株式会社RJCでは、WBSの分解や見積もりの考え方を、実際のプロジェクトの中で仲間と確かめ合っています。こうした知識を共有しながら、日々技術を磨いています。

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。