WBSとは？システム開発での作り方5ステップ・工程別の項目例と粒度の決め方を解説

「開発の終盤になって、想定していなかった作業が次々と出てきた」「進捗率は80%と報告されているのに、いつまでも終わらない」。システム開発のプロジェクトで起きるこうした事態の多くは、作業の洗い出しが不十分なまま走り出したことに原因があります。

WBSは、プロジェクト全体の作業を階層的に分解し、管理できる大きさのタスクまで落とし込んだ構成図です。何をどこまでやるのかが目に見える形になるため、抜け漏れの防止と工数見積もりの精度向上に直結します。

ただし、テンプレートを埋めるだけでは機能しません。粒度をどこまで細かくするか、どの単位で分解するか、作成後にどう更新していくかという判断が伴わないと、初回に作ったまま誰も見ないファイルになります。

この記事では、WBSの基本的な考え方から作成手順、システム開発の工程別に洗い出すべき項目例、粒度の決め方、そして形骸化を防ぐ運用のポイントまでを順に整理します。

確認したいポイント	結論	詳細
WBSとは何か？	作業を階層的に分解した構成図	プロジェクトの成果物と必要な作業を段階的に分解し、管理できる大きさのタスクまで落とし込んだものです。
ガントチャートとの違いは？	WBSは作業構造、ガントは時間軸	WBSで洗い出した作業に日程と担当を割り当てて可視化したものがガントチャートです。両者は併用が基本です。
階層はどこまで分ける？	3〜4層、数日で終わる粒度が目安	細かくしすぎると更新が追いつかず形骸化します。1タスクが数日で完了する大きさを下限の目安にします。
よくある失敗は？	作成後に更新されず形骸化する	管理作業や移行作業の抜け、担当者ごとの粒度のばらつきも典型例です。更新の担当と頻度を先に決めます。

この記事でわかること

• WBSの基本的な考え方と、ガントチャートとの違いおよび使い分け方
• ゴール設定から依存関係の整理まで、WBSを作成する5つのステップ
• 要件定義からリリース、運用引き継ぎまでの工程別に洗い出すべき項目例
• 階層の深さと最小タスクの大きさをどう決めるかという粒度の判断基準
• 作って終わりにせず、変更を反映しながら運用し続けるためのポイント

システム開発とAI活用の進め方をまとめた資料を無料で配布しています 要件整理の進め方、開発の依頼範囲の決め方、費用と期間の目安を1冊にまとめました。社内での検討材料としてご活用いただけます。 ▶ 資料請求はこちら ※オンライン完結／しつこい営業は一切いたしません

システム開発におけるWBSとは

WBSはWork Breakdown Structureの略で、日本語では作業分解構成図と呼ばれます。Work（作業）をBreakdown（分解）してStructure（構造化）するという語のとおり、プロジェクト全体を段階的に細かくしていく手法です。

システム開発は、要件定義から設計、実装、テスト、移行、リリースまで多くの工程を含みます。全体を一度に把握しようとしても無理があるため、扱える大きさまで分解して管理するという発想が必要になります。

IPA（情報処理推進機構）はソフトウェア開発分析データ集の中で、技術者の経験と勘に頼った方法ではなく、実際のプロジェクトデータにもとづく定量的なプロジェクト管理が必要だと述べています。WBSは、その定量管理を成り立たせるための土台にあたります。

WBSの構成と階層の考え方

WBSは木構造で表現されます。最上位にプロジェクト全体を置き、その下に工程、さらにその下に作業項目、最下層に実際に担当者が着手する単位のタスクを配置していく形です。

たとえば「基本設計」という工程の下に「画面設計」「帳票設計」「データベース設計」が並び、「画面設計」の下に「画面一覧作成」「画面遷移図作成」「画面項目定義書作成」が並ぶ、といった構造になります。

重要なのは、下位の項目をすべて足したものが上位の項目と一致するという関係が成り立っていることです。この関係が崩れていると、どこかに作業の抜けか重複があることになります。

ガントチャートとの違いと使い分け

混同されやすいのがガントチャートです。WBSは作業の構造を表すもの、ガントチャートは時間軸上の予定を表すものという点が根本的な違いです。

WBSには時間の概念が含まれません。何をやるのかを漏れなく並べることが目的です。そこに開始日、終了日、担当者を割り当てて横棒で可視化したものがガントチャートになります。

実務では両者を分けずに、Excelの1枚のシートで左側にWBS、右側にガントチャートを並べる形が広く使われています。ただし考え方としては別物であり、先にWBSを固めてから日程を入れるという順序を崩さないことが大切です。

誰がいつ作成するのか

一般的には、開発を担うベンダー側のプロジェクトマネージャーが作成します。作成のタイミングは、要件定義が固まりつつある段階から計画フェーズにかけてです。

ただし、プロジェクトマネージャーが全工程の作業を詳細まで把握しているとは限りません。設計、実装、テストそれぞれの担当リーダーを巻き込んで洗い出さないと、粒度がばらついたり、現実的でない工数が入ったりします。

発注側の企業も、完成したWBSを受け取るだけでなく作成過程に関与すべきです。自社側で必要な作業、たとえばデータの提供、業務ルールの確認、受け入れテストの実施などは、発注側にしか分からないためです。

システム開発でWBSが必要とされる理由

WBSを作る目的は、ドキュメントを整えることではありません。プロジェクトが失敗する典型的な要因を、計画段階で潰しておくことにあります。

ここでは、WBSがどのような問題を防ぐのかを4つの観点から整理します。

作業の抜け漏れを防ぐ

最も大きな効果です。システム開発では、データ移行、旧システムの停止、権限設定、マニュアル作成、利用者への説明会といった作業が見落とされがちです。

これらは開発そのものではないため、機能一覧からタスクを起こすと漏れます。工程を軸に分解していくWBSの構造は、こうした周辺作業を拾い上げる仕組みとして機能します。

終盤で発覚した作業は、そのままスケジュールの遅延に直結します。前工程で洗い出しておけば済んだ話が、後工程では手戻りを伴うという構造を理解しておく必要があります。

工数見積もりの根拠になる

「開発期間は6か月」という数字だけでは、その妥当性を誰も判断できません。WBSで最小単位まで分解し、各タスクに工数を積み上げれば、見積もりの内訳が説明できる状態になります。

積み上げた結果が想定と大きく食い違ったときも、どの工程が重いのかが特定できます。スコープを削る、リソースを追加する、リリースを分割するといった判断の材料になります。

発注側にとっても、見積書の金額が何に対する対価なのかを確認する手段になります。金額の妥当性を判断する材料として、WBSの提出を求める企業も増えています。

進捗のずれを早く検知できる

タスクが大きいままだと、進捗は担当者の感覚報告になります。「だいたい7割」という報告が続き、実際には終わっていなかったという事態が起こります。

数日で完了する大きさまで分解しておけば、進捗は完了か未完了かの2択で管理できます。感覚が入り込む余地がなくなるため、遅れが数字として早く表面化します。

遅れが早く分かれば、対策を打つ時間が残ります。プロジェクトが破綻するのは、遅れが発覚した時点で挽回の余地がなくなっているケースがほとんどです。

発注側と開発側の認識を揃える

「その作業はそちらでやるものだと思っていた」という認識の食い違いは、システム開発でよく起きるトラブルです。WBSに担当者の列を設ければ、役割分担が文書として残ります。

テストデータの用意、既存データのクレンジング、承認フローの確認、社内調整といった作業は、どちらが担うかが曖昧になりがちです。

契約や体制の整理についてはシステム開発の外注とは｜メリット・デメリット、費用相場、外注先の種類と選び方でも触れています。WBSは役割分担の合意書としての側面も持つと捉えると、作成時の議論の質が変わります。

WBSの作り方｜5つのステップ

ここからは実際の作成手順を追っていきます。上から順に大きく分けていき、最後に日程を入れるという流れを守ることが、作りやすさと精度の両立につながります。

いきなり細かいタスクを書き並べると、構造が崩れて後から整理し直すことになります。

ステップ1｜ゴールと成果物を明確にする

最初に決めるのは、このプロジェクトで何が完成すれば終わりなのかという定義です。「在庫管理システムの本番稼働」のように、達成したかどうかを判定できる形で言語化します。

あわせて、途中で作られる成果物も列挙します。要件定義書、基本設計書、テスト仕様書、操作マニュアル、移行手順書といったドキュメント類が該当します。

この段階で、やらないことも明記しておきます。スコープ外を書き残しておくと、後から追加要望が出たときに議論の起点になります。

ステップ2｜工程を大分類として並べる

次に、ゴールに至るまでの工程を時系列で並べます。ウォーターフォール型であれば、要件定義、基本設計、詳細設計、実装、単体テスト、結合テスト、総合テスト、移行、リリースという流れが基本形です。

ここでは細かいタスクには踏み込みません。大分類を時系列で並べることに集中します。順序が整理されていないと、後の依存関係の整理で混乱します。

あわせて、工程に紐づかない共通作業も1つの大分類として置いておきます。プロジェクト管理、課題管理、定例会議、品質レビューといった作業がここに入ります。

ステップ3｜成果物単位に分解していく

各工程を、その工程で作られる成果物ごとに分解します。動詞ではなく成果物を軸に分解するのがポイントです。「設計する」ではなく「画面設計書」「テーブル定義書」という形で切ります。

成果物で切ると、完了の判定基準が明確になります。ドキュメントが作成されレビューを通過したかどうかで、終わったかどうかが客観的に決まるためです。

分解を続けて、1つのタスクが数日で完了する大きさになったら止めます。それ以上細かくすると、更新の手間が管理の効果を上回ります。

ステップ4｜工数と担当者を割り当てる

最下層のタスクごとに、必要な工数と担当者を設定します。工数は人日または人時で入力し、上位の階層へ積み上げていきます。

担当者は1タスクにつき1人にします。複数名を割り当てると責任の所在が曖昧になり、どちらも着手しないまま期日を迎えるという事態が起こります。作業量が多い場合は、タスク自体を分割します。

この段階で、実際に作業する担当者本人に工数を確認します。管理者が机上で置いた数字は、実態と乖離することが少なくありません。

ステップ5｜依存関係を整理してスケジュール化する

最後に、タスク同士のつながりを整理します。前のタスクが終わらないと始められないもの、並行して進められるものを区別する作業です。

依存関係が整理できたら、開始日と終了日を割り当ててガントチャートに落とし込みます。ここで初めて、全体の期間が見えてきます。

想定より長くなった場合は、並行できる作業を増やす、スコープを分割してリリースを2段階にするといった調整を行います。単純に各タスクの日数を削るのは、後から必ず破綻します。

作業の洗い出しや工数の妥当性についてご相談いただけます 手順は分かっても、自社のプロジェクトで何が抜けているかの判断は簡単ではありません。計画段階からご一緒する30分の無料相談をご用意しています。 ▶ 相談予約はこちら ※オンライン完結／秘密厳守／助成金活用のご相談も歓迎

工程別のWBS項目例｜要件定義からリリースまで

実際にWBSを作る際、最も時間がかかるのが作業の洗い出しです。ここでは工程ごとに、システム開発で必要になる代表的な項目を挙げていきます。

自社のプロジェクトに当てはめながら、不要なものを削り、固有の作業を足していく使い方を想定しています。

要件定義工程

システムに求める機能と条件を決める工程です。ここでの決定が後続すべてに影響するため、関係者へのヒアリングと合意形成の作業まで含めて洗い出します。

• 現行業務の調査、業務フローの整理、課題の洗い出し
• 関係部門へのヒアリング、要望の一覧化と優先順位付け
• 機能要件の定義、非機能要件（性能、可用性、セキュリティ）の定義
• システム化範囲の確定、スコープ外の明示
• 要件定義書の作成、レビュー、承認取得

要件の書き方そのものに迷う場合は要件定義の例｜システム種類別の要件例と、機能要件・非機能要件の書き換え集も参考になります。承認取得までをタスクとして置くことを忘れないでください。

基本設計・詳細設計工程

要件をシステムの形に落とし込む工程です。成果物が多いため、ドキュメント単位で分解すると管理しやすくなります。

• 画面一覧、画面遷移図、画面項目定義書の作成
• 帳票一覧、帳票レイアウトの設計
• テーブル定義書、ER図、データ辞書の作成
• 外部システムとの連携仕様（インターフェース定義）の作成
• バッチ処理の一覧と処理仕様の定義、権限とロールの設計
• 各設計書のレビュー、指摘対応、承認取得

設計書の体裁で迷う場合は要件定義書のフォーマット｜表紙・改訂履歴・ID体系・表のレイアウトの決め方の考え方が応用できます。レビューと指摘対応を独立したタスクとして置くと、想定外の遅延を防げます。

実装・単体テスト工程

コードを書く工程です。機能単位で分解するのが一般的ですが、開発環境の準備や共通部品の作成を先に置く必要があります。

• 開発環境の構築、リポジトリとブランチ運用ルールの整備
• 共通部品、認証基盤、ログ出力などの基盤機能の実装
• 画面ごと、機能ごとの実装
• バッチ処理、外部連携処理の実装
• 単体テスト仕様書の作成、テスト実施、不具合の修正
• コードレビュー、静的解析の実施

機能単位に分けるときは、画面数や機能数をそのままタスク数にすると工数が積み上げやすくなります。難易度に差がある場合は、工数の数値で調整します。

結合テスト・総合テスト工程

個々の機能をつないだ状態、そして業務の流れ全体で確認する工程です。テストデータの準備が想像以上に時間を要するため、独立したタスクとして置きます。

• テスト計画書の作成、テスト環境の構築
• テストデータの作成、本番相当データの用意とマスキング
• 結合テスト仕様書の作成、実施、不具合管理
• 総合テスト（業務シナリオテスト）の設計と実施
• 性能テスト、負荷テスト、セキュリティ診断
• 発注側による受け入れテストの支援、指摘対応

不具合の修正工数は事前に読めません。過去の実績から一定の枠を確保しておくのが現実的な対処です。ゼロで見積もると、必ずスケジュールが崩れます。

移行・リリース・運用引き継ぎ工程

最も抜けやすい工程です。開発が終われば使えるようになると考えてしまい、その手前にある作業が計画から落ちることが頻発します。

• 移行計画書の作成、移行対象データの棚卸し
• データ移行ツールの作成、リハーサルの実施、結果の検証
• 本番環境の構築、権限とアカウントの設定
• 利用者向けマニュアルの作成、操作研修の実施
• リリース手順書と切り戻し手順の作成
• 旧システムの停止、並行稼働期間の運用
• 運用保守体制への引き継ぎ、問い合わせ窓口の整備

特にデータ移行のリハーサルは、最低でも2回は計画に入れます。1回目で必ず問題が見つかるため、1回しか組んでいないと本番当日に対応が間に合いません。

プロジェクト管理・共通作業

工程に紐づかないものの、確実に工数が発生する作業です。ここを計上しないと、管理者の稼働が見えないまま実績だけが膨らみます。

• 定例会議の実施、議事録の作成、報告資料の準備
• 課題管理、リスク管理、変更要求の受付と判定
• 進捗の集計とWBSの更新
• 品質指標の集計、工程完了判定の会議

プロジェクト管理の工数は、全体の1割前後を占めることも珍しくありません。最初から一定の割合を見込んでおくことで、後から辻褄合わせをする必要がなくなります。

粒度と階層の決め方

WBSの出来を左右するのが粒度です。細かすぎても粗すぎても管理できなくなるため、どこで分解を止めるかの基準を持っておく必要があります。

ここでは、判断に使える4つの目安を挙げます。

階層は3〜4層を目安にする

プロジェクト、工程、作業項目、タスクという3〜4層が扱いやすい範囲です。5層以上になると全体を俯瞰しづらくなり、更新の手間も一気に増えます。

階層を深くしたくなるのは、たいてい特定の工程だけです。その場合は、その部分だけ別紙で詳細WBSを作り、本体のWBSには集約した形で載せる方法があります。

全体を同じ深さに揃える必要はありませんが、同じ階層に並ぶ項目の粒度は揃えるようにします。ここがばらつくと、進捗率の集計が意味をなさなくなります。

最小タスクは数日で終わる大きさに

下限の目安は、1タスクが2日から5日程度で完了する大きさです。1日単位まで刻むと更新作業が負担になり、2週間を超えると進捗が見えなくなります。

この範囲であれば、週次の進捗会議で「終わった」「終わっていない」を確認するだけで管理が成立します。パーセンテージでの報告が不要になる点が大きな利点です。

長期のプロジェクトでは、先の工程まで同じ粒度で分解しきれないこともあります。その場合は無理に細かくせず、着手が近づいた時点で詳細化する進め方を取ります。

動詞ではなく成果物で分解する

「調査する」「検討する」といった動詞で切ると、いつ終わったのかが判定できません。完了の基準が客観的に定まる成果物の単位で分解します。

「現行業務を調査する」ではなく「現行業務フロー図を作成する」、「性能を検討する」ではなく「性能要件一覧を作成する」という書き方に変えるだけで、進捗管理の精度が変わります。

検討そのものが必要な場合も、検討結果を記した資料をアウトプットとして定義すれば、同じ形で管理できます。

段階的に詳細化する

プロジェクト開始時点で、すべての工程を同じ精度で分解することは現実的ではありません。先の工程ほど不確実性が高いためです。

初期段階では、直近の工程を詳細に、先の工程は大枠のまま置いておきます。工程が進むにつれて、次の工程を詳細化していく進め方が一般的です。

この方法を取る場合は、詳細化するタイミング自体をWBSに載せておきます。「テスト工程の詳細WBS作成」というタスクを設計工程の中に置く、といった形です。

工数見積もりとスケジュールへの落とし込み

WBSができたら、次は工数とスケジュールに変換します。ここを機械的に処理すると、実行できない計画が出来上がります。

見積もりの精度を上げるための3つの観点を整理します。

工数と期間を分けて考える

5人日の作業が5日で終わるとは限りません。1人が専任で当たれば5日ですが、他の作業と兼務していれば10日以上かかります。

工数は作業量、期間はカレンダー上の日数です。この2つを混同すると、担当者ごとの負荷が過大になっていることに気づけません。

担当者別に工数を集計し、稼働可能な日数と突き合わせる作業を必ず行います。特定の人に集中していないかという観点は、計画段階でしか調整できません。

バッファの置き方

各タスクに余裕を持たせると、その余裕は使い切られます。個別タスクは実力どおりの日数で置き、工程の末尾にまとめてバッファを設けるのが基本的な考え方です。

バッファは隠さず、明示的に1つのタスクとしてWBSに載せます。どれだけ余裕が残っているかが可視化され、消費のペースから危険信号を読み取れるようになります。

見積もりの妥当性を確認したい場合は、IPAが公開するソフトウェア開発分析データ集2022のような、実プロジェクトの定量データと比較する方法があります。

クリティカルパスを把握する

依存関係をたどったとき、最も所要日数が長くなる経路がクリティカルパスです。この経路上のタスクが1日遅れると、プロジェクト全体が1日遅れます。

逆に言えば、それ以外のタスクには多少の余裕があります。どこを優先的に守るべきかが分かるため、リソース配分の判断が明確になります。

クリティカルパスは進行中に変わります。遅延が発生するたびに再確認する運用にしておかないと、気づかないうちに別の経路が全体を律速していたという事態が起こります。

作成ツールの選び方｜Excelと専用ツール

WBSは専用ツールがなくても作れます。プロジェクトの規模と関係者の人数で選ぶのが現実的な判断基準です。

ExcelやGoogleスプレッドシートで作る場合

小規模なプロジェクトや、社内の一部だけで完結する開発であれば十分です。追加費用がかからず、誰でも編集できる点が最大の利点になります。

階層はインデントか階層番号の列で表現し、右側に工数、担当者、開始日、終了日、進捗の列を並べます。ガントチャート部分は条件付き書式で塗りつぶす方法が広く使われています。

難点は、同時編集と更新履歴の管理です。複数人が別々のファイルを持ち始めた時点で管理は崩れるため、保管場所とファイル名のルールを最初に決めておきます。

プロジェクト管理ツールを使う場合

関係者が10名を超える、複数のチームが並行して動く、進捗の更新頻度が高いといった条件では、専用ツールが向きます。担当者本人が自分のタスクを更新できるため、管理者に更新作業が集中しません。

依存関係の設定、遅延の自動検知、工数の集計といった機能も備わっています。手作業での再計算が不要になる点は、規模が大きいほど効果が出ます。

一方で、ツールを入れても入力されなければ意味がありません。更新のタイミングと責任者を運用ルールとして定めることが、ツール選定以上に重要です。

テンプレートを使うときの注意

公開されているテンプレートは、洗い出しの起点として有用です。自分では思いつかなかった作業に気づけるという効果があります。

ただし、そのまま埋めるだけでは自社のプロジェクトに合いません。テンプレートに載っていない固有の作業、たとえば既存システムとの連携や社内承認プロセスは、必ず追加が必要になります。

テンプレートは確認用のチェックリストとして使い、構造は自分で組むという使い方が適しています。

よくある失敗と運用のポイント

WBSがうまく機能しないケースには、いくつかの共通したパターンがあります。作り方の問題ではなく、運用の設計が抜けていることが原因である場合が大半です。

作って終わりになり形骸化する

最も多い失敗です。キックオフで配布されたあと誰も開かず、実態と乖離したまま放置されます。原因は、更新の担当者と頻度が決まっていないことにあります。

対策は単純で、週次の定例会議の前に更新するというルールを決め、更新自体をWBS上のタスクとして計上することです。工数として認められていない作業は続きません。

また、更新した内容が意思決定に使われていることが実感できれば、自然と維持されます。会議でWBSの画面を開いて進めるだけでも、位置づけは変わります。

担当者ごとに粒度がばらつく

複数のリーダーが分担して作成すると、ある工程は10タスク、別の工程は100タスクという状態になります。この状態では全体の進捗率が実態を表しません。

対策は、作成前に粒度の基準を共有しておくことです。「最小タスクは3日以内」「階層は4層まで」といった数値の目安を先に配ります。

作成後には、全体を見渡して粒度を揃える調整の時間を取ります。この調整をプロジェクトマネージャーの作業として計画に入れておくことが必要です。

変更が反映されない

要件の追加や仕様変更が起きたとき、WBSに反映されないまま進んでしまうケースです。実態とずれた計画で管理を続けても意味がありません。

変更要求の受付から影響範囲の確認、WBSへの反映までを1つの流れとして手順化します。変更のたびに工数とスケジュールへの影響を示せば、安易な追加要望への歯止めにもなります。

反映した履歴は残しておきます。当初計画からどれだけ増えたかが説明できると、遅延の原因についての議論が生産的になります。

発注側としてWBSをどう見るか

システム開発を外部に委託する立場であれば、受け取ったWBSを次の観点で確認します。自社が担う作業が明示されているかが最も重要な点です。

• 自社側のタスク（データ提供、業務確認、受け入れテスト、承認）が入っているか
• 移行、マニュアル作成、研修、運用引き継ぎが計画に含まれているか
• テストと不具合修正の期間が現実的な長さで確保されているか
• 最小タスクの粒度が細かすぎず粗すぎない範囲に収まっているか

これらが欠けている場合は、作成の段階で指摘します。着手後に判明した抜けは、追加費用と納期延長の交渉になるためです。

社内に開発の知見が少なく判断に自信が持てない場合は、要件整理の段階から支援を受ける方法もあります。進め方はシステム開発｜AIを活用した開発支援で紹介しています。

まとめ

WBSは、システム開発の作業を階層的に分解し、管理できる大きさまで落とし込むための構成図です。時間軸を持つガントチャートとは役割が異なり、先にWBSで構造を固めてから日程を割り当てるという順序が基本になります。

作成手順は、ゴールと成果物の定義、工程の並べ方、成果物単位の分解、工数と担当者の割り当て、依存関係の整理という5段階です。動詞ではなく成果物で分解し、1タスクが数日で終わる大きさを目安にします。

洗い出しで抜けやすいのは、データ移行、マニュアル作成、研修、運用引き継ぎ、そしてプロジェクト管理そのものの工数です。開発以外の作業を意識的に拾い上げることが、終盤の混乱を避ける鍵になります。

そして、WBSは作った時点では価値を生みません。更新の担当と頻度を決め、変更を反映し続けて初めて計画として機能します。まずは直近の工程だけでも、成果物単位で分解し直すところから始めてみてください。

システム開発の計画づくりから、無料で相談できます 受け取ったWBSの妥当性を判断したい、社内に開発の知見がなく進め方に不安があるといった段階のご相談も承っています。営業色は一切ありません。 ▶ 相談予約はこちら ※オンライン完結／秘密厳守／助成金活用のご相談も歓迎