システム開発の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の作成とスケジュールの作成を分けて考えることが重要です。

WBSは、プロジェクトで作成する成果物や実施すべき作業の全体像を階層的に整理し、管理可能な単位まで分解したものです。一方、スケジュールは、WBSで明らかになった作業をもとに、担当者、工数、開始日、終了日、依存関係などを設定し、実行する順序と時期を具体化したものです。

そのため、いきなりExcelやプロジェクト管理ツールへ開始日や終了日を入力するのではなく、最初にプロジェクトの目的、成果物、作業範囲を整理し、必要な作業を漏れなく分解します。その後、完成したWBSをもとにスケジュール表やガントチャートを作成します。

本章では、計画の作成から運用までを次の七つの手順に分けて解説します。

手順1〜3では、成果物と必要な作業を洗い出し、管理可能な単位まで分解してWBSを完成させます。手順4〜5では、WBSで整理した作業に担当者、工数、日程、依存関係などを設定し、スケジュールへ展開します。手順6では、WBSとスケジュールの両方を関係者でレビューし、手順7では、実行状況や変更を継続的に反映します。

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

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

目的が曖昧なままでは、どの作業が必要で、どこまで対応すればプロジェクトが完了するのかを判断できません。たとえば、システムの稼働開始を目指すのか、設計書やプログラムを納品するところまでを対象とするのかによって、WBSに含める成果物や作業範囲は変わります。

契約書、提案書、プロジェクト計画書、要件定義書などを確認し、納品物とプロジェクトの完了条件を整理しましょう。対象となる機能や業務だけでなく、対象外とする範囲も明文化することが重要です。

対象外の内容が曖昧だと、追加要望が発生した際に、当初の契約範囲に含まれる作業なのか、追加対応として扱うべきなのかを判断しにくくなります。

また、開発会社が行う作業だけでなく、顧客による確認やデータ提供、外部ベンダーによる環境準備、社内で必要となる申請や承認なども確認します。プロジェクトの完了に必要な活動であれば、自社の直接的な作業でなくても、計画上考慮しなければなりません。

未確定の要件がある場合は、推測によって作業内容を固定しないようにします。「要件調査」「方式検討」「関係者との協議」「方針決定」など、要件を確定させるための作業としてWBSに含め、決定後に関連する部分を更新します。

最初に「何を完成させるプロジェクトなのか」「どこまでを対象とするのか」を関係者で共有することが、抜け漏れの少ないWBSを作るための出発点です。

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

目的、成果物、作業範囲が決まったら、プロジェクト全体を大きな単位に分けます。

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

ただし、WBSは単なる工程表ではありません。工程名を並べるだけで終わらせず、それぞれの工程で完成させる成果物を明らかにすることが重要です。

たとえば、要件定義工程であれば要件定義書、基本設計工程であれば画面設計書やデータベース設計書、テスト工程であればテスト計画書、テスト仕様書、テスト結果報告書などが成果物として考えられます。

成果物を列挙した後は、それぞれを完成させるために必要な作業へ分解します。「作成」だけでなく、「確認」「レビュー」「修正」「承認」まで含めて洗い出すことがポイントです。

たとえば、設計書を成果物とする場合、設計書を作成する作業だけでは十分ではありません。レビューの準備、レビューの実施、指摘事項の修正、再確認、承認といった作業も必要です。

さらに、会議、顧客への問い合わせ、環境準備、機器調達、アカウント発行、データ提供の依頼、社内申請などの付帯作業も洗い出します。こうした作業は成果物の一覧だけを見ていると漏れやすいため、工程ごとに関係者へ確認しましょう。

過去のWBSや社内テンプレートは、検討漏れを防ぐためのチェックリストとして役立ちます。ただし、過去の内容をそのまま複製してはいけません。今回の対象機能、プロジェクト体制、契約条件、採用技術、開発手法に合わせて、不要な項目を削除し、不足する項目を追加する必要があります。

この段階では、作業をいつ実施するかを決めるのではなく、「プロジェクトを完了するために何が必要か」を漏れなく明らかにすることに集中します。

手順3：管理可能な粒度まで作業を分解し、WBSを完成させよう！

必要な成果物と作業を洗い出したら、それぞれを管理可能な単位まで分解します。

作業の粒度は、WBS作成で特に迷いやすいポイントです。粗すぎる作業は実施状況を把握しにくく、細かすぎる作業は管理や更新の負担を増やします。

適切な粒度は、プロジェクトの規模、作業内容、管理方法、報告頻度などによって変わります。そのため、「すべての作業を一日以内にする」といった日数だけの基準で一律に決める必要はありません。

判断基準の一つは、作業内容と成果を明確に説明できる単位になっているかどうかです。複数の担当領域や複数の成果物を含む項目は、責任範囲や完了状態が曖昧になりやすいため、さらに分解します。

また、定例会議のたびに「作業中」としか報告できないほど大きな作業は、成果物や確認ポイントごとに分ける必要があります。

たとえば、「基本設計書作成」という項目は、画面設計、帳票設計、データベース設計、外部連携設計などに分解できます。必要に応じて、それぞれをさらに「設計書作成」「レビュー」「指摘修正」「承認」といった単位へ分けます。

一方で、「ファイルを開く」「文字を入力する」「保存する」といった操作手順までWBSに登録すると、実際の作業よりも管理の負担が大きくなります。WBSは作業マニュアルではないため、個々の操作まで細分化する必要はありません。

特に重視したいのは、何が完成すればその作業単位を完了とみなせるのかを説明できることです。成果物の作成、レビューの完了、承認の取得、テストの合格など、客観的に完了を確認できる単位まで分解します。

必要な作業を漏れなく洗い出し、管理可能な単位まで階層的に分解できた段階で、WBSはいったん完成です。

ここまでの手順では、開始日や終了日、作業の実施順序はまだ確定していません。次の手順から、完成したWBSをもとに、実行可能なスケジュールを作成します。

手順4：WBSをもとに担当者・工数・日程を設定しよう！

WBSが完成したら、各作業をスケジュール表やガントチャートへ展開します。

この段階では、WBSで整理した作業単位をもとに、担当者、予定工数、開始日、終了日、優先度、完了を確認するための基準などを設定します。

担当者は、可能な限り一つの作業につき一人の責任者を決めます。複数人で作業する場合でも、実施状況を把握し、完了を報告する責任者を明確にしておくと、対応漏れや責任の曖昧化を防げます。

予定工数は、過去の実績、類似機能の記録、担当者の経験、作業の難易度などを参考に見積もります。プロジェクト全体をまとめて見積もるのではなく、WBSで分解した小さな作業単位ごとに見積もり、それを積み上げることが重要です。

ただし、工数と作業期間は同じではありません。たとえば、二人日と見積もった作業が、必ず二日間で完了するとは限りません。

担当者がほかのプロジェクト、定例会議、問い合わせ対応などを兼務している場合は、その作業だけにすべての時間を使えるわけではありません。開始日と終了日を設定する際は、担当者が実際に確保できる稼働時間、休日、休暇、会議、ほかの担当作業などを考慮します。

また、完了を判断するための基準には、「対応中」「ほぼ完成」といった主観的な表現を使わないようにします。「設計書がレビューで承認されている」「コードが指定のブランチへマージされている」「予定したテスト項目がすべて合格している」など、第三者が確認できる状態を設定します。

担当者、工数、日程、完了を確認する基準をスケジュール上で具体化することで、WBSで整理した作業を実行可能な計画へ変換できます。

手順5：スケジュール上で依存関係とマイルストーンを設定しよう！

各作業の担当者、工数、開始日、終了日を設定したら、スケジュール表やガントチャート上で作業同士の依存関係を整理します。

システム開発では、ある作業が完了しなければ、次の作業を開始できないケースが多くあります。たとえば、要件が確定しなければ基本設計を完了できず、設計が承認されなければ実装に着手できないといった関係です。

スケジュール表やガントチャート上で先行作業と後続作業を関連付けると、一つの作業の遅延が、どの工程や作業へ影響するのかを確認しやすくなります。

依存関係を設定する際は、すべての作業を機械的につなげるのではなく、実際に制約となる関係を確認します。前の作業が完全に終わるまで次の作業を始められないのか、一部が完成すれば並行して進められるのかによって、設定すべき関係は異なります。

特に、複数の工程やチームに影響する作業や、遅延するとプロジェクト全体の完了日に直結する作業は、重点的に管理します。

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

マイルストーンは、通常の作業のような期間を持たせるのではなく、重要な成果や判断が成立する時点として設定します。その時点で何が満たされている必要があるのかも明確にしましょう。

顧客レビュー、外部ベンダーからの納品、社内承認など、自社だけでは実施時期を決められない作業も、スケジュール上の依存関係に含めます。相手側の確認時間や回答までの期間を考慮せずに日程を組むと、待ち時間によって後続作業が遅れる可能性があります。

不確実性の高い作業については、リスクの大きさに応じて予備期間を検討します。ただし、すべての作業へ一律に余裕を加えるのではなく、技術的な不確実性、外部への依存、レビューや承認に必要な時間などを踏まえて設定することが重要です。

依存関係とマイルストーンを設定することで、単に日付が並んだ表ではなく、作業の順序や遅延の影響を確認できるスケジュールになります。

手順6：WBSとスケジュールをチームでレビューしよう！

WBSとスケジュールは、プロジェクトマネージャーやリーダーだけで確定させないことが大切です。

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

設計、開発、インフラ、テスト、セキュリティ、運用など、各領域の担当者に参加してもらい、WBSとスケジュールをそれぞれの観点から確認します。

WBSのレビューでは、主に次の内容を確認します。

• 必要な成果物がすべて含まれているか
• 成果物を完成させるための作業に漏れがないか
• 作業の重複がないか
• 作業範囲が適切に分解されているか
• 各作業の完了状態を説明できるか
• 対象外の作業が誤って含まれていないか

スケジュールのレビューでは、主に次の内容を確認します。

• 担当者と責任範囲が明確になっているか
• 工数と作業期間に無理がないか
• 担当者の稼働状況が考慮されているか
• 作業の前後関係が正しいか
• 外部のレビューや承認に必要な期間が含まれているか
• マイルストーンの時期と達成条件が適切か
• 遅延の影響が大きい作業を把握できているか

経験の浅い担当者と経験豊富な担当者では、同じ作業でも必要となる工数や期間が異なります。実際に作業するメンバーの意見を反映し、実行可能性を確認しましょう。

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

レビューで指摘された内容を反映した後は、関係者間で作業範囲とスケジュールについて合意します。合意したWBSとスケジュールを基準計画として保存しておくと、後から変更が発生した際に、当初の計画との差を説明できます。

チームで計画作成に参加することは、抜け漏れや無理な日程を防ぐだけでなく、プロジェクトへの理解と当事者意識を高める効果もあります。

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

WBSとスケジュールは、計画時に作成して提出するだけの資料ではありません。

WBSは、プロジェクトで必要となる成果物と作業範囲を管理するための基礎情報です。スケジュールは、作業の実施状況や日程への影響を把握するための管理情報です。両者を目的に応じて更新し、現在の状況を正しく示す必要があります。

最初に、誰が、何を、どの頻度で更新するのかを決めます。日次で更新するのか、週次の定例会議前に更新するのかを明確にし、古い情報が残らないようにします。

進捗確認では、担当者が入力した進捗率だけに頼らないことが重要です。「九割完成」と報告されていても、レビューを受けていなければ、大幅な修正が必要になる可能性があります。

成果物の完成状況や、事前に設定した完了の判断基準に照らして、作業が本当に完了しているかを確認します。

スケジュール上では、予定開始日と実績開始日、予定終了日と実績終了日の差を記録すると、遅れの傾向を把握しやすくなります。遅延が発生した場合は、原因だけでなく、依存関係をたどって後続作業やマイルストーンへの影響を確認します。

仕様変更や追加要望が発生した場合は、まずWBSを確認し、追加または変更となる成果物と作業を明らかにします。そのうえで、必要な工数、担当者、開始日、終了日、依存関係をスケジュールへ反映します。

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

ただし、実績に合わせて基準計画そのものを安易に書き換えてはいけません。当初計画と現在の見通しを区別して管理することで、計画との差異や変更の影響を正確に把握できます。

まとめ

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

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

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

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

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

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

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

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

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

まずは現在のWBSで成果物や作業が漏れなく洗い出されているかを確認し、そのうえでスケジュール表（ガントチャート）に担当者や完了条件、依存関係が正しく設定されているかを確認していきましょう。

QA業務効率化ならPractiTest

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

この記事の監修

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

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