WBSとはIT分野で何を指すのか、開発プロジェクトでの作り方の基本

WBS(Work Breakdown Structure)とは、プロジェクトで生み出す成果物と必要な作業を階層的に分解し、抜け漏れなく構造化した図表のことです。IT開発プロジェクトでは、要件定義からリリースまでの工程をワークパッケージという最小単位まで分解し、担当・工数・進捗を管理する土台として使われます。本記事では、IT案件特有の作業項目の切り方、100%ルール・8/80ルールといった粒度の基準、複数ベンダーが関わる場合の責任分界、ガントチャートやEVMとの連携、そして独立コンサルタントがPMO業務としてWBS作成を任される場面までを整理します。

WBS(Work Breakdown Structure)とは何か、IT分野での定義

WBSとは、プロジェクトで生み出す成果物と、それを実現するために必要な作業を、階層構造で分解して一覧化した図表のことです。IT分野では、システム開発という大きな成果物を要件定義・設計・実装・テストといった工程レベルまで分解し、さらに機能や画面といった単位まで細分化して使います。

一般的なプロジェクトマネジメントにおけるWBSの定義

プロジェクトマネジメント全般において、WBSはプロジェクト全体の作業を大きな単位から段階的に小さな単位へ分解し、ツリー構造にまとめたものと定義されます(Backlog、2026年5月時点)。国際的なプロジェクトマネジメントの標準であるPMBOK(Project Management Body of Knowledge)では、WBSはスコープマネジメントの一プロセスとして位置づけられており、プロジェクトのスコープ(範囲)を確定させたうえで作業に分解する、という順序が前提になっています(PM現場ラボ調べ)。

WBSの階層は、一般に「プロジェクト全体」「成果物・フェーズ」「ワークパッケージ(それ以上分解しない最小の作業単位)」という3段階前後で構成されます。ワークパッケージまで分解して初めて、担当者・工数・期限を割り当てられる状態になります。

IT開発プロジェクトでのWBSの位置づけの特徴

IT開発プロジェクトのWBSは、要件定義・基本設計・詳細設計・実装・テスト・リリースという、成果物が明確な工程単位で大枠を組み、そこに機能・画面・データといった単位のワークパッケージをぶら下げる構成が中心になる点が特徴です。

各工程では仕様書・設計書・プログラムモジュール・テスト結果報告書といった具体的な成果物が定義しやすいため、WBSの粒度を「成果物」を基準に切り分けやすいという事情もあります。工程全体の流れそのものについては、システム開発の流れを工程別に整理した記事で個別に解説していますので、あわせて確認しておくとWBSの大枠が組みやすくなります。

IT案件のWBSに含まれる典型的な作業項目

IT案件のWBSは、要件定義・基本設計・詳細設計・実装・テスト・リリースという工程の大項目の下に、機能や画面単位のワークパッケージを配置する構成が一般的です。

要件定義〜テストまでの粒度の切り方

要件定義からテストまでは、機能単位でワークパッケージをそろえて並べるのが典型的な切り方です。例えば「ユーザー登録機能」であれば、要件整理・画面設計・データベース設計・実装・単体テスト・結合テストという同じ機能軸のタスクを、工程をまたいで一列に並べます。

次の表は、架空の「顧客管理システム刷新プロジェクト」を題材にしたWBSの抜粋例です。実際の粒度感をイメージする参考として見てください。

このように機能単位で工程を横断してワークパッケージをそろえておくと、8時間から80時間程度という適正な粒度感にも合わせやすく、進捗管理の際にどの機能がどの工程で止まっているかを一目で把握できます。

インフラ構築・移行作業特有の項目

アプリケーション開発と並行して、インフラ構築・移行作業には独自のワークパッケージが必要です。業務システム刷新プロジェクトのWBSには、移行データのクレンジングや移行ツールの選定、サーバーへのデプロイや初期データ投入といった、移行作業に特有のタスクが組み込まれます(Incubation Base、2026年8月更新時点)。

本番切り替え直前には、移行リハーサルや切り戻し手順の確認といった、アプリケーション開発のWBSには出てこない項目も必要になります。インフラ・移行系のワークパッケージは、開発側のワークパッケージと依存関係が強いため、同じWBS上で並べて管理しておくと後工程での調整漏れを防ぎやすくなります。

WBSを作成する際の分解ルールと粒度の考え方

WBSの粒度を決める代表的な基準に「100%ルール」と「8/80ルール」があり、この2つを満たすワークパッケージを作ることが、実務で機能するWBSの土台になります。

100%ルール・8/80ルールなど代表的な基準

「100%ルール」とは、上位要素とその配下の下位要素の合計が過不足なく一致することを求める基準です(PM現場ラボ調べ)。子要素をすべて足し合わせたときに親要素の作業範囲を漏れなく重複なくカバーしている状態を指し、WBSの網羅性を検証する基本になります。

「8/80ルール」とは、1つのワークパッケージが8時間(1日)以上、80時間(2週間)以内に収まる粒度を目安とする基準です(note・五十嵐学氏、2026年3月時点)。IT開発では機能単位のタスクをこの範囲に収めることで、進捗報告の頻度と工数見積もりの精度のバランスを取りやすくなります。

粒度が細かすぎる/粗すぎる場合の弊害

8時間を下回るほど細かく分解すると、タスクの数そのものが増え、報告・更新にかかる管理コストが上がります(note・五十嵐学氏調べ)。逆に80時間を超える粗い粒度のままにすると、進捗の実態が見えにくくなり、遅れの発見が遅れます。

特に「進捗率を0%か100%かのどちらかでしか判定できない」ような粗いタスクは要注意です。会議の場で「順調です(進行中)」という曖昧な報告を許してしまい、深刻な遅延の発見を遅らせる原因になるとされています(note・五十嵐学氏調べ)。IT開発では、画面単位・機能単位まで分解して初めて、この曖昧な進捗報告を防げる粒度になります。

IT特有のWBSでつまずきやすいポイント

IT開発のWBSでは、要件定義段階での仕様変更に伴う手戻りと、複数ベンダーが関わる場合の責任分界の曖昧さが、特につまずきやすいポイントです。

手戻り・仕様変更を織り込んだ組み方

IT開発は要件定義や基本設計の段階で仕様変更が発生しやすく、後工程の作業に手戻りが生じることがあります。WBSを組む段階から、後工程で仕様変更が入ることを前提にレビューポイントをあらかじめ設定しておくと、手戻りが発生した際にどのワークパッケージへ影響が波及するかを追いやすくなります。

手戻りをゼロにすることは現実的ではないため、WBS上では「レビュー」「再確認」といった検証系のワークパッケージを各工程の節目に明示的に置き、仕様が固まっていない領域には多少の余裕を持たせた工数見積もりにしておくことが実務上の対処になります。

複数ベンダーが関わる場合の責任分界

複数のITベンダーが関わるIT開発では、発注サイドとシステム開発会社の役割分担が曖昧だと、後から「これもウチがやるの?」ともめる原因になります(システム幹事、2025年6月時点)。このため、経済産業省とIPAは、ユーザー企業とITベンダーいずれかにメリットが偏らない契約書作成を目指し、各開発段階で担うべき責務を整理した「情報システム・モデル取引・契約書」を公表しています(IPA、2020年12月公開・2025年4月更新確認)。

マルチベンダー案件では、複数のITベンダー全体を取りまとめるPMOが発注者側に置かれることが多く(システム幹事調べ)、請負側のPM・PMOは自社が請け負ったスコープのQCD(品質・コスト・納期)に責任を持つのに対し、発注側のPM・PMOはプロジェクト全体のQCDに責任を持ち、複数のシステム・チームが従う共通のプロセス・ルールを整備する立場になります(株式会社JQ、2025年8月時点)。WBS上でも、どのワークパッケージをどのベンダーが担当するかを列として明示し、ベンダー間の境界にあたる作業(連携テストやデータ引き継ぎなど)を独立したワークパッケージとして切り出しておくと、責任の所在があいまいになりにくくなります。

WBSとガントチャート・スケジュールの関係整理

WBSは「何を分解して管理するか」を示す道具、ガントチャートは「いつ誰が行うか」を示す道具であり、WBSで洗い出したワークパッケージをガントチャートに落とし込んで初めて、スケジュール管理として機能します。

WBSからガントチャートへの落とし込み方

WBSで洗い出したワークパッケージそれぞれに、開始日・終了日・担当者・先行するワークパッケージ(依存関係)を付与すると、ガントチャートの1行に変換できます。WBSの階層構造(何を分解したか)と、ガントチャートの時間軸(いつ行うか)は本来別の情報であるため、WBSだけを見て「進捗が遅れているかどうか」を判断するのは難しく、必ずガントチャートとセットで運用する必要があります。両者の役割の違いをより詳しく整理したい場合は、WBSとガントチャートの違いと使い分けを解説した記事も参考になります。

進捗管理指標(EVMなど)との連携

WBSのワークパッケージ単位で出来高(EV)をあらかじめ定義しておくと、EVM(アーンド・バリュー・マネジメント)の指標を機械的に算出できるようになります。代表的な指標であるSPI(スケジュール効率指数)はEV÷PVで算出し1未満であれば計画より遅れていることを示し、CPI(コスト効率指数)はEV÷ACで算出し1未満であれば予算を超過していることを示します(PM現場ラボ、2026年7月時点)。

WBSのワークパッケージが8/80ルールに沿って適切な粒度に分解されているほど、各ワークパッケージの「完了=100%、未着手=0%」という出来高判定がしやすくなり、結果としてEVMの指標も実態に近い数値になります。粒度の粗いWBSのままEVMを導入すると、指標だけが整っていて実態の進捗とはずれている、という状況に陥りやすい点には注意が必要です。

独立コンサルタントがWBS作成を任される場面と求められるスキル

独立コンサルタントがWBS作成を任されるのは、PMOの一員としてプロジェクト体制に参画し、進捗の可視化やレビューといった役割を求められる場面が中心です。

PMO業務としてのWBS設計支援

PMO業務としてWBS設計・レビューを担う場合の月額単価は役割によって幅があり、サポート中心の水準からマネジメント寄り、戦略・リード級まで案件規模に応じて変動するとされています(編集部独自調査データ)。単価の目線を持ったうえで案件に参画するには、実務経験の棚卸しに加えて、資格の取得を検討する独立コンサルタントも少なくありません。

フリーランスのPM・PMOが取得を検討する資格では、知名度とスキルシート上の説明コストの低さから、PMP(Project Management Professional)が第一候補とされています。もっとも、単価を決めるのは資格の有無より実務経験である点が重視される、という理解にとどめておくのが実務的です(ドメイン知識ベース・PM/PMO関連資格の推奨順)。

クライアントへのWBSレビュー・改善提案

クライアント企業が既に作成したWBSの粒度・網羅性をレビューし、抜け漏れや責任分界の曖昧な箇所を指摘して改善提案を行うことも、独立コンサルタントがPMO業務で求められる役割の1つです。100%ルールに沿って抜け漏れがないか、8/80ルールに沿って粒度がそろっているか、という本記事で解説した基準に沿って点検するだけでも、実務上は一定の価値提供になります。

このようなPMO案件を独立コンサルタントとして獲得する際は、大手企業・上場企業との直接契約よりもエージェント経由が実務上の基本ルートになります。エージェント2〜3社へ登録して案件の土台をつくり、前職・元同僚からのリファラルを並行しながら、直取引は実績と信用ができた段階で検討するのが現実的な進め方とされています(ドメイン知識ベース・案件獲得の基本ルート)。

出典・参考情報

1. Backlog（株式会社ヌーラボ）「WBSとは？ガントチャートとの違いとWBSの作り方を解説」（2026-09-11参照）
2. PM現場ラボ「WBSの作り方 完全ガイド｜階層分解の5ステップで作業の抜け漏れをなくす」（2026-09-11参照）
3. note（五十嵐学）「WBSの粒度はどう決める？8/80ルールと崩壊させないための5つの鉄則」（2026-09-11参照）
4. Incubation Base株式会社「WBSでシステム開発を成功させる全手順｜項目例・作り方・テンプレート付」（2026-09-11参照）
5. IPA（独立行政法人情報処理推進機構）「情報システム・モデル取引・契約書（第二版）」（2026-09-11参照）
6. システム幹事「システム開発の役割分担？発注者が知るべきプロジェクト体制作りのポイントを解説」（2026-09-11参照）
7. 株式会社JQ「発注側と請負側のPM、PMOの違いとは？実際の役割」（2026-09-11参照）
8. PM現場ラボ「EVM（アーンド・バリュー・マネジメント）の計算｜SV・CV・SPI・CPI を例題でマスター」（2026-09-11参照）

本記事のデータは2026年9月11日時点の情報に基づきます（最終更新日：2026年9月11日）。実務での運用は案件・体制によって異なるため、具体的な進め方は実際のプロジェクト体制や専門家の見解に照らして判断することをおすすめします。