システム開発のWBSとは？工程別の項目例と失敗しない作り方を徹底解説

システム開発のWBSを任されたものの、工程をどこまで細かく分ければよいのか分からず、手が止まってしまうことは珍しくありません。

過去に使われたテンプレートがあっても、開発する機能や体制、契約範囲が異なれば、そのまま流用するだけでは必要な作業が抜けたり、不要な項目が残ったりします。

WBSは作業名を並べるだけの表ではなく、成果物を起点に必要な作業を分解し、担当者・工数・期限・依存関係・完了条件を整理するための土台です。

適切に作成すれば、見積もりの精度を高められるだけでなく、タスクの抜け漏れや認識のずれを防ぎ、遅延の兆候にも早く気づけます。

そこで今回は、システム開発のWBSに必要な項目と作成・運用の手順を、工程別の具体例でまとめました！

初めてプロジェクト全体を管理する場合でも実践できるよう、WBSの基本から失敗しやすいポイントまで順番に解説します。

▼システム開発の流れに関する記事はこちら▼

WBSの役割を理解して、管理しやすい計画の土台を作ろう！

WBSを正しく活用するには、最初に役割を理解しておく必要があります。

見た目が整った一覧表を作っても、必要な作業や成果物が網羅されていなければ、プロジェクト管理には役立ちません。

反対に、目的や作業範囲が整理されたWBSがあれば、スケジュール作成、工数見積もり、担当者の割り当て、進捗確認を一貫した情報で進められます。

この章では、WBSの基本的な考え方、作成するメリット、ガントチャートやスケジュール表との違いを整理します。

WBSとは、開発に必要な作業を漏れなく整理する設計図！

WBSは「Work Breakdown Structure」の略称で、プロジェクトの成果物や作業を、管理できる大きさまで階層的に分解したものです。

システム開発では、プロジェクト全体を起点として、要件定義、設計、開発、テスト、移行などの工程に分け、さらに成果物や具体的な作業へと細分化します。

たとえば「基本設計」という大きな工程を、画面設計、帳票設計、データベース設計、外部インターフェース設計などに分けます。

そのうえで、各設計書の作成、レビュー、修正、承認といった作業まで整理すると、実行可能な計画になります。

重要なのは、WBSが単なる日程表ではなく、プロジェクトを完了するために必要な作業範囲を明確にする設計図である点です。

作業を階層化することで、タスクの抜け漏れや重複を発見しやすくなり、関係者がプロジェクトの全体像を共通認識として持てます。

また、WBSにはプロジェクトで実施する作業全体を含める必要があります。

開発担当者が行う作業だけでなく、顧客確認、社内承認、環境準備、外部ベンダーへの依頼なども対象です。

WBSの完成そのものを目的にせず、計画や見積もり、進捗確認、変更管理に使える状態を目指すことが大切です。

WBSを作る5つのメリットを押さえよう！

WBSを作る第一のメリットは、必要な作業を事前に洗い出し、抜け漏れを防げることです。

プロジェクトの後半で未計画の作業が発覚すると、担当者の確保や日程の調整が難しくなり、納期遅延につながりやすくなります。

成果物と作業を工程ごとに確認しておけば、見落としを早い段階で発見できます。

第二のメリットは、見積もり精度を高められることです。

プロジェクト全体を一括して見積もるより、細分化したタスクごとに必要な工数を積み上げるほうが、根拠のある期間や費用を算出しやすくなります。

第三のメリットは、担当者と責任範囲を明確にできることです。

各タスクに責任者を設定すれば、「誰かが対応すると思っていた」「担当外だと思っていた」といった認識違いを防げます。

第四のメリットは、タスク間の依存関係や遅延の影響を把握しやすくなることです。

後続作業に影響するタスクを特定できれば、遅れが小さい段階で担当者の追加や優先順位の変更を検討できます。

第五のメリットは、作業範囲を関係者と共有し、スコープを管理できることです。

追加要望が発生した際にも、既存タスクへの影響や新たに必要となる工数を説明しやすくなります。

WBSとガントチャート・スケジュール表の違いを整理しよう！

WBSとガントチャートは一緒に使われることが多いものの、それぞれの役割は異なります。

WBSは、プロジェクトで何を行うのかを洗い出し、階層的に整理するものです。

一方、ガントチャートは、WBSで洗い出したタスクについて、開始日と終了日、実施期間、前後関係、進捗状況を時系列で可視化するものです。

基本的には、最初にWBSで必要な作業を整理し、その後に担当者や日程を設定してガントチャートへ展開します。

作業が十分に洗い出されていない状態でガントチャートを先に作ると、見た目は整っていても必要なタスクが抜けたスケジュールになりかねません。

スケジュール表は、会議や納品日なども含めた日程を管理するための資料です。

課題管理表は発生した問題と対応状況を管理し、進捗管理表は計画に対する実績や遅れを確認する目的で使います。

これらを別々に運用する場合も、同じ情報を何度も入力するのではなく、WBSのタスク番号や名称を基準に情報を関連付けることが大切です。

使用するツールの機能よりも、どの情報を誰がいつ更新するのかを決めておくことが、管理の形骸化を防ぎます。

要件定義からリリースまで！システム開発のWBS項目例を確認しよう

システム開発のWBSでは、要件定義や設計、開発といった主要工程だけを並べても、十分な計画にはなりません。

各工程で作成する成果物を明確にし、作成、確認、レビュー、修正、承認までを具体的なタスクとして登録する必要があります。

また、環境構築やデータ準備、社内申請、顧客確認など、成果物の作成以外に必要となる作業も忘れずに含めます。

ここでは、一般的なウォーターフォール型のシステム開発を想定し、工程別にWBSへ登録したい項目を紹介します。

実際に作成する際は、プロジェクトの規模や契約範囲、開発方式に合わせて項目を追加または削除します。

プロジェクト準備・要件定義で入れる項目！

プロジェクト準備では、プロジェクト計画書の作成、開発体制の構築、キックオフ、会議体の設定、連絡手段の整備などをWBSに含めます。

各メンバーの役割や意思決定者、報告経路を明確にし、課題や変更をどのように管理するかも決めておくことが重要です。

要件定義では、現行業務の調査、利用部門へのヒアリング、業務上の課題整理、システム化する範囲の確認を行います。

その後、業務要件、機能要件、非機能要件、データ要件、外部システムとの連携要件などを整理します。

非機能要件には、性能、可用性、セキュリティ、バックアップ、障害対応、運用監視などが含まれます。

機能要件だけに意識が向くと、テストやリリースの直前に非機能面の不足が判明するため、要件定義の段階からタスクとして明示しておきます。

要件定義書についても、「作成」という一つのタスクだけでは不十分です。

項目ごとの作成、内部レビュー、顧客レビュー、指摘修正、最終承認までを分けることで、進捗を客観的に判断できます。

発注側、開発側、外部ベンダーが担当する範囲を明確にし、判断待ちや確認待ちもWBS上で把握できるようにします。

基本設計・詳細設計で入れる項目！

基本設計では、要件定義で決めた内容を、利用者や発注者が確認できる形に具体化します。

代表的な項目は、画面設計、帳票設計、バッチ設計、データベース設計、外部インターフェース設計、権限設計などです。

システム構成やネットワーク、ログ、バックアップ、性能、セキュリティといった非機能面の設計も含めます。

詳細設計では、プログラムの処理内容、データ項目、クラスやモジュールの構成、エラー処理など、実装に必要な情報へ落とし込みます。

開発標準、命名規則、コーディング規約、共通部品の設計など、複数の機能に関係する作業も独立したタスクとして登録します。

設計対象は、単に「画面設計」とまとめるのではなく、画面群や機能群、サブシステムなど、担当者を割り当てられる単位へ分けることがポイントです。

各設計書には、作成、内部レビュー、顧客レビュー、修正、承認を設定します。

レビューの期間や修正に必要な時間を考慮せず、作成期間だけでスケジュールを組むと、後工程の開始が遅れやすくなります。

要件と設計項目の対応関係を確認するタスクも設け、要求が設計へ漏れなく反映されているかを確認します。

開発・単体テストで入れる項目！

開発工程では、プログラミングだけでなく、実装を始めるための準備作業もWBSに含めます。

開発環境の構築、リポジトリの設定、ブランチ運用の決定、開発ルールの共有、必要なアカウントや権限の発行などが代表例です。

実装作業は、画面、API、バッチ、帳票、データ移行処理など、成果物や機能単位で分解します。

「会員管理機能を開発する」のように複数の処理を含むタスクは、進捗が見えにくいため、登録、変更、削除、検索などに分ける方法があります。

ただし、処理の一行ごとに分けるほど細かくすると、更新負担が増えて管理が形骸化します。

担当者が作業内容を理解でき、完了を判断できる単位にとどめることが大切です。

実装後には、コードレビュー、指摘修正、再確認、マージなどの作業が発生します。

単体テストについても、仕様書作成、レビュー、テストデータ準備、テスト実施、不具合修正、再テストまでを登録します。

完了条件には、単に「実装完了」と書くのではなく、コードレビューが完了し、単体テストの合格基準を満たしている状態など、客観的な条件を設定します。

結合テスト・総合テスト・受入テストで入れる項目！

結合テスト以降は、テスト実施だけでなく、計画や環境の準備に多くの作業が必要です。

テスト計画書の作成、テスト仕様書の作成、テスト環境の構築、テストデータの準備、レビュー、実施、結果確認をそれぞれ登録します。

結合テストでは、機能間のデータ連携、画面からAPIへの処理、バッチ間のつながり、外部システムとの連携などを確認します。

総合テストでは、実際の業務を想定したシナリオを用いて、システム全体が要求どおりに動作するかを確認します。

正常な操作だけでなく、入力エラー、通信障害、処理中断、権限不足などの例外処理も対象です。

性能、負荷、セキュリティ、障害復旧、バックアップ、運用監視といった非機能テストも忘れずに含めます。

不具合が発生した場合は、不具合登録、原因調査、修正、影響範囲の確認、再テスト、完了判定までが必要です。

受入テストでは、顧客や利用部門が担当する作業、問い合わせへの回答、修正対応、承認条件を明確にします。

顧客側の作業期間もWBSへ登録しておくと、確認待ちによる遅延を把握しやすくなります。

移行・リリース・運用引き継ぎで入れる項目！

移行・リリース工程では、本番環境を用意してシステムを公開するまでの作業を細かく整理します。

本番環境の構築、設定値の確認、データ移行プログラムの準備、移行データの抽出と整形、移行リハーサル、結果確認などが主な項目です。

データ移行は、本番当日に初めて実施するのではなく、事前にリハーサルを行い、所要時間やエラーへの対応を確認します。

リリース作業では、リリース手順書、当日のタイムテーブル、担当者の役割、連絡体制、実施可否の判定条件を整備します。

問題が発生した場合に元の状態へ戻すため、切り戻しの条件と手順も準備します。

運用引き継ぎでは、操作マニュアル、運用手順書、監視手順書、障害対応手順書、問い合わせ対応の流れなどを作成します。

利用者向けの説明会や操作研修、運用担当者への引き継ぎもWBSへ含めます。

リリース後には、本番環境での動作確認、初期不具合への対応、問い合わせ対応、安定稼働の判定が必要です。

最後にプロジェクトの振り返りを行い、見積もりとの差や発生した課題を記録すると、次回のWBS作成に活用できます。

迷わず実践！抜け漏れのないWBSを作って運用する手順

実務で使えるWBSを作るには、いきなりExcelや管理ツールへタスクを入力するのではなく、目的や成果物を整理するところから始めます。

成果物が曖昧なまま作業を分解すると、必要なタスクを判断できず、粒度もそろいません。

成果物と作業範囲を決めた後にタスクを洗い出し、担当者、工数、期限、依存関係、完了条件を設定します。

さらに、作成者だけで確定せず、実際に作業を担当するメンバーとレビューすることが重要です。

完成後も進捗や変更を反映し、プロジェクトの現状を示す管理情報として更新し続けます。

ここからは、WBSの作成から運用までを七つの手順に分けて解説します。

手順1：目的・成果物・作業範囲を最初に決めよう！

WBSを作成する前に、プロジェクトの目的と最終的に完成させる成果物を明確にします。

目的が曖昧なままでは、どの作業が必要で、どこまで対応すれば完了なのかを判断できません。

システムの稼働開始を目指すのか、設計書やプログラムを納品するところまでなのかによって、WBSへ含める範囲は変わります。

契約書、提案書、プロジェクト計画書、要件定義書などを確認し、納品物と完了条件を整理します。

対象となる機能や業務だけでなく、対象外とする範囲も明文化することが重要です。

対象外の内容が曖昧だと、追加要望が発生した際に、当初の契約範囲か追加対応かを判断しにくくなります。

開発会社の作業だけでなく、顧客による確認やデータ提供、外部ベンダーによる環境準備、社内の申請や承認も含めて範囲を確認します。

未確定の要件がある場合は、推測で作業内容を固定しません。

要件調査、方式検討、関係者との協議、決定といったタスクとして登録し、確定後に関連するWBSを更新します。

最初に何を完成させるプロジェクトなのかを共有することが、抜け漏れの少ないWBSにつながります。

手順2：成果物と開発工程から必要な作業を洗い出そう！

目的と成果物が決まったら、プロジェクト全体を大きな開発工程に分けます。

一般的なシステム開発では、プロジェクト準備、要件定義、基本設計、詳細設計、開発、単体テスト、結合テスト、総合テスト、受入テスト、移行、リリースなどが上位階層になります。

次に、各工程で完成させる成果物を列挙します。

要件定義であれば要件定義書、基本設計であれば画面設計書やデータベース設計書、テスト工程であればテスト計画書や結果報告書などです。

成果物を列挙した後、それを完成させるために必要な作業へ分解します。

作成だけでなく、確認、レビュー、修正、承認まで含めることがポイントです。

さらに、会議、顧客への問い合わせ、環境準備、機器調達、アカウント発行、社内申請などの付帯作業を洗い出します。

こうした作業は成果物の一覧だけでは見落としやすいため、工程ごとに関係者へ確認します。

過去のWBSやテンプレートは、検討漏れを防ぐチェックリストとして役立ちます。

ただし、そのまま複製するのではなく、今回の機能、体制、契約、技術、開発手法に合わせて項目を追加・削除する必要があります。

手順3：進捗が判断できる粒度までタスクを分けよう！

タスクの粒度は、WBS作成で特に迷いやすいポイントです。

粗すぎるタスクは進捗が見えにくく、細かすぎるタスクは更新の負担を増やします。

適切な粒度はプロジェクトの規模や報告頻度によって変わるため、日数だけで一律に決める必要はありません。

判断基準の一つは、担当者が作業内容を理解し、着手から完了まで自分で管理できるかどうかです。

複数の担当者が別々に作業するタスクや、複数の成果物を含むタスクは、責任範囲が曖昧になりやすいため分割します。

また、定例会議のたびに「作業中」としか報告できないほど長いタスクは、成果物や確認ポイントごとに分けます。

たとえば「基本設計書作成」を、画面設計、帳票設計、データベース設計、外部連携設計などに分解します。

一方、ファイルを開く、入力する、保存するといった操作手順まで登録すると、管理のための作業が増えてしまいます。

最も重視したい基準は、完了したかどうかを客観的に判断できることです。

成果物やレビュー結果、テスト合格など、明確な完了条件を設定できる単位まで分解すると、進捗確認がしやすくなります。

手順4：担当者・工数・期限・完了条件を設定しよう！

必要なタスクを洗い出したら、各タスクに担当者、予定工数、開始日、終了日、優先度、完了条件を設定します。

担当者は、可能な限り一つのタスクにつき一人の責任者を決めます。

複数人で作業する場合でも、進捗を把握して完了を報告する責任者を明確にすると、対応漏れを防げます。

工数は、過去の実績や類似機能の記録、担当者の経験、作業の難易度を参考に見積もります。

プロジェクト全体をまとめて見積もるのではなく、小さなタスクごとに工数を検討し、積み上げていくことが重要です。

期限を設定する際は、単純に人数で工数を割るだけでは不十分です。

担当者がほかのプロジェクトや定例会議、問い合わせ対応を兼務している場合は、実際に確保できる稼働時間を考慮します。

完了条件には、「対応中」「ほぼ完成」といった主観的な表現を使わないようにします。

設計書がレビューで承認されている、コードがマージされている、テスト項目がすべて合格しているなど、第三者が確認できる状態を定めます。

担当者と完了条件を明確にすることで、進捗報告のばらつきを抑えられます。

手順5：依存関係とマイルストーンを整理しよう！

担当者や工数を設定した後は、タスク同士の依存関係を整理します。

システム開発では、前の作業が完了しないと次の作業を開始できないケースが多くあります。

要件が確定しなければ基本設計を完成できず、設計が承認されなければ実装を進められないといった関係です。

WBS上で先行タスクと後続タスクを関連付けると、一つの遅延がどこまで影響するかを確認しやすくなります。

特に、複数の工程やチームに影響するタスク、完了が遅れると全体の日程に直結するタスクは、重点的に管理します。

あわせて、要件確定、基本設計承認、開発完了、テスト完了、リリース判定など、プロジェクトの重要な節目となるマイルストーンを設定します。

マイルストーンには期間を持たせず、その時点で満たすべき条件を明確にします。

顧客レビュー、外部ベンダーからの納品、社内承認など、自社だけでは日程を決められない作業も依存関係へ含めます。

相手側の確認時間を考慮せずに日程を組むと、待ち時間によって後続作業が遅れます。

不確実性の高い箇所には必要な予備期間を設け、問題が発生した際に調整できる計画にします。

手順6：チームでレビューして、抜け漏れと無理な計画を直そう！

WBSは、プロジェクトマネージャーやリーダーだけで完成させないことが大切です。

一人で作成すると、専門領域の作業が抜けたり、担当者の実態に合わない工数を設定したりする可能性があります。

設計、開発、インフラ、テスト、運用など、各領域の担当者に確認してもらいます。

レビューでは、成果物や作業の不足、重複、担当者、工数、期限、前後関係、完了条件を確認します。

担当者が作業内容を理解できるか、想定した期間で実行できるかも重要な確認項目です。

経験の浅い担当者と経験豊富な担当者では、同じ作業でも必要な時間が異なるため、実際に担当するメンバーの意見を反映します。

顧客側の確認期間、経営層や管理部門の承認、アカウントの申請、機器やサービスの調達など、見落としやすい待ち時間も確認します。

レビューで指摘された内容を反映した後は、関係者間で作業範囲とスケジュールについて合意します。

合意したWBSを基準計画として保存しておくと、後から変更が発生した際に、当初計画との差を説明できます。

チームで作成に参加することは、WBSへの理解と当事者意識を高める効果もあります。

手順7：作って終わりにせず、進捗と変更を定期的に反映しよう！

WBSは、計画時に作成して提出するだけの資料ではありません。

プロジェクトの進捗や変更を反映し、現在の状況を判断するために使う管理情報です。

最初に、誰がどの頻度で更新するのかを決めます。

日次で更新するのか、週次の定例会議前に更新するのかを明確にし、古い情報が残らないようにします。

進捗確認では、担当者が入力した進捗率だけに頼らないことが重要です。

「九割完成」と報告されても、レビューを受けていなければ、大幅な修正が必要になる可能性があります。

成果物の完成状況や完了条件を基準に、タスクが本当に完了しているかを確認します。

予定開始日と実績開始日、予定終了日と実績終了日の差を記録すると、遅れの傾向を把握しやすくなります。

遅延が発生した場合は、原因だけでなく、後続タスクやマイルストーンへの影響を確認します。

仕様変更や追加要望が発生した際は、関連する作業、工数、担当者、期限を更新します。

変更前の基準計画を残しておけば、何が変わり、なぜ期間や費用が増えたのかを顧客や上司へ説明できます。

失敗しやすいWBSの特徴を知って、形だけの管理を防ごう！

失敗しやすいWBSの特徴として、最初に挙げられるのがタスクの粒度が粗すぎることです。

数週間から数か月続く作業を一つのタスクにすると、期限直前まで遅れを発見できません。

反対に、数十分で終わる操作まで細分化すると、更新項目が増え、実際の作業より管理負担が大きくなります。

担当者、期限、完了条件が設定されておらず、作業名だけが並んでいるWBSも機能しません。

誰が対応するのか分からないタスクは放置されやすく、どの状態になれば完了なのか分からなければ進捗も判断できません。

また、担当者の感覚だけで進捗率を入力する運用にも注意が必要です。

同じ「八割完了」でも、担当者によって判断基準が異なり、客観的な状況を把握できません。

最初に作ったWBSを更新せず、実際の作業内容や日程とずれたまま放置するケースもあります。

現状と合わないWBSは、確認されなくなり、提出用の資料として形骸化します。

色や罫線、グラフなどの見栄えを整えることより、判断に必要な情報が正しく更新されていることを優先します。

管理ツールを導入するだけでは解決しないため、入力項目、更新頻度、責任者、進捗確認の基準を決めておくことが重要です。

開発手法や体制に合わせてWBSを調整しよう！

WBSの構成は、開発手法やプロジェクトの規模、契約形態に合わせて調整する必要があります。

ウォーターフォール型では、要件定義から設計、開発、テスト、リリースまでの工程と、成果物の承認を中心に階層化します。

工程間の依存関係が強いため、レビューや承認の完了条件を明確にすることが重要です。

アジャイル型では、リリース、イテレーション、機能、ユーザーストーリーなどを軸に整理できます。

詳細な長期計画を最初から固定するのではなく、直近の作業を具体化しながら、優先順位や要件の変化に応じて更新します。

ただし、アジャイル型でも、環境構築、データ移行、外部システム連携、セキュリティ、性能、運用設計などの横断的な作業は必要です。

機能開発だけに集中し、非機能要件やリリース準備を漏らさないようにします。

外部委託を含む場合は、発注準備、作業依頼、成果物の受領、レビュー、修正依頼、受入判定などを明確にします。

小規模案件では管理項目を絞り、大規模案件ではシステムやチーム、サブプロジェクト単位にWBSを分割します。

Excel、スプレッドシート、プロジェクト管理ツールのどれを使う場合でも、人数、更新頻度、共有範囲に合わせて選び、運用ルールを先に決めることが大切です。

まとめ

WBSは、システム開発の作業名を並べるだけの表ではありません。

成果物と作業範囲を明確にし、見積もりや担当者設定、進捗確認、変更管理を行うための土台です。

要件定義からリリースまでの工程を並べた後、各工程で必要な成果物を洗い出し、作成、レビュー、修正、承認といった具体的な作業へ分解します。

さらに、担当者、予定工数、開始日、終了日、依存関係、完了条件を設定することで、実行可能な計画になります。

タスクの適切な粒度に、すべてのプロジェクトで共通する絶対的な正解はありません。

担当者が内容を理解でき、定期的に進捗を確認でき、完了したかどうかを客観的に判断できる単位を基準にします。

また、WBSはプロジェクトマネージャーだけで作成せず、実際に作業するメンバーとレビューすることが重要です。

作成後も進捗や仕様変更を定期的に反映し、現状と計画の差を確認できる状態を保ちます。

最初から完璧なWBSを作ろうとする必要はありません。

まずは現在のWBSに、成果物・担当者・完了条件・依存関係がそろっているかを確認し、不足している項目から改善していきましょう。

QA業務効率化ならPractiTest

テスト管理の効率化についてお悩みではありませんか？そんなときはテスト資産の一元管理をすることで工数を20%削減できる総合テスト管理ツール「PractiTest」がおすすめです！

この記事の監修

Dr.T。テストエンジニア。
PractiTestエバンジェリスト。
大学卒業後、外車純正Navi開発のテストエンジニアとしてキャリアをスタート。DTVチューナ開発会社、第三者検証会社等、数々のプロダクトの検証業務に従事。
2017年株式会社モンテカンポへ入社し、マネージメント業務の傍ら、自らもテストエンジニアとしテストコンサルやPractiTestの導入サポートなどを担当している。

記事制作：川上サトシ（マーケター、合同会社ぎあはーと代表）