システム開発におけるWBSとは？作り方・項目・進捗管理のポイントをわかりやすく解説

システム開発を進める際、「予定していた日までに開発が終わらない」「担当者によって進捗の認識が違う」「リリース直前になって必要な作業が漏れていることに気づいた」といった問題が発生することがあります。

こうした問題を防ぎ、プロジェクト全体の作業と進捗を管理するために利用されるのが「WBS」です。

WBSは単なるスケジュール表ではありません。システムを完成させるために必要な作業を洗い出し、誰が何を担当し、いつまでに完了させるのかを明確にする重要な管理手法です。

特にフルスクラッチのシステム開発では、企業ごとに業務内容や要件が異なるため、プロジェクトに合わせて必要な作業を整理することが重要になります。

本コラムでは、システム開発におけるWBSとは何か、WBSを作成する目的や基本的な項目、作り方、事業会社の担当者が確認しておきたいポイントまでわかりやすく解説します。

＞＞フルスクラッチ（オーダーメイド）のシステム開発について詳細はこちら

システム開発におけるWBSとは？役割と作成する目的をわかりやすく解説

WBS（Work Breakdown Structure）とは、システム開発で必要な作業を細かく分解し、「何を、いつまでに、誰が行うのか」を整理するためのものです。

たとえば、システム開発では「要件定義」「設計」「開発」「テスト」「リリース」といった工程があります。WBSでは、これらをさらに具体的な作業単位まで分け、担当者や開始日、完了予定日、進捗状況などを管理します。

WBSを作成することで、開発に必要な作業の抜け漏れを防ぎやすくなり、スケジュールの遅れや担当者への作業集中も早期に把握できます。また、「現在どこまで進んでいるのか」「次に何をするのか」を関係者間で共有しやすくなることもメリットです。

システム開発を計画通りに進めるために、WBSはプロジェクト全体の作業を見える化し、進捗を管理するための重要な役割を持っています。

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

WBSとは「Work Breakdown Structure」の略称で、システム開発に必要な作業を細かく分解して整理する方法です。

システム開発には、要件定義、設計、開発、テスト、リリースなど、さまざまな工程があります。しかし、「設計」「開発」といった大きな単位だけでプロジェクトを管理すると、その中で具体的に何を行うのかが見えにくくなります。

そこでWBSでは、それぞれの工程を実際に管理できる作業単位まで細かく分けていきます。

たとえば「テスト」という工程であれば、

・テスト計画の作成
・テストケースの作成
・単体テスト
・結合テスト
・総合テスト
・不具合修正
・再テスト
・受入テスト

といった形で必要な作業を整理します。

さらに、それぞれについて担当者、開始予定日、終了予定日、進捗状況などを設定することで、プロジェクトの状況を把握しやすくします。

つまりWBSは、「システムを完成させるためには、具体的にどのような作業が必要なのか」を見えるようにするものです。

WBSとスケジュール表・ガントチャートの違い

WBSをスケジュール表やガントチャートと同じものだと考えてしまうケースがありますが、それぞれ役割が異なります。

WBSの中心となる考え方は、プロジェクトに必要な作業を洗い出し、管理可能な単位まで分けることです。

一方、ガントチャートは、各作業を「いつからいつまで実施するのか」という時間軸で表現するために利用します。

実際のシステム開発では、WBSで整理した作業に開始日や終了日を設定し、それをガントチャートとして表示することも多いため、両者が一体となって使われることがあります。

重要なのは、日程だけを決めるのではなく、その前に「そもそも何をする必要があるのか」を十分に洗い出すことです。

作業が抜けたままスケジュールを作成しても、プロジェクトが進んだ段階で追加作業が発生し、予定が崩れる原因になります。

システム開発でWBSが重要な理由

必要な作業の抜け漏れを防ぎやすくなる

システム開発では、プログラムを作ること以外にも多くの作業が発生します。

たとえば既存データの移行、外部システムとの連携確認、操作マニュアルの作成、利用者への説明、リリース後の確認なども必要になる場合があります。

こうした作業を最初からWBSに落とし込んでおくことで、「開発は終わったのにデータ移行の準備ができていない」といった事態を防ぎやすくなります。

プロジェクトの進捗を把握しやすくなる

「開発は順調です」という報告だけでは、実際にどの程度進んでいるのかわかりません。

WBSで作業が細分化されていれば、「予定されていた作業のうち、どこまで完了しているのか」「どの作業が遅れているのか」「その遅れが後続の作業に影響するのか」といった状況を具体的に確認できます。

事業会社側にとっても、システム開発会社からの報告を受けるだけではなく、プロジェクトの状態を客観的に確認するための材料になります。

誰が担当するのかを明確にできる

システム開発では、すべての作業をシステム開発会社だけで進められるとは限りません。

業務ルールの確認、マスターデータの準備、受入テスト、社内承認など、事業会社側で対応しなければならない作業もあります。

担当者が明確になっていないと、「システム開発会社が対応すると思っていた」「事業会社側で準備するとは聞いていなかった」といった認識違いが起こります。

WBSに担当者を設定しておけば、双方が行うべき作業を明確にできます。

システム開発のWBSに入れる主な項目

WBSの内容はプロジェクトによって異なりますが、一般的には次のような項目を管理します。

・作業名
・作業内容
・担当者
・開始予定日
・終了予定日
・実際の開始日
・実際の終了日
・進捗状況
・前後の作業との関係
・課題や備考

特に重要なのが、「作業名」「担当者」「期限」です。

何をするのかだけでなく、「誰が」「いつまでに」を明確にすることで、WBSを実際のプロジェクト管理に利用できるようになります。

また、作業同士の関係も重要です。

たとえば、仕様が確定しなければ画面設計を完了できない、画面設計が終わらなければ開発を開始できない、といった関係があります。

一つの作業の遅れがどこに影響するのかまで把握できれば、問題が発生した際にも対応を判断しやすくなります。

システム開発におけるWBSのサンプル

WBSは、実際にはどのような形で作成するのでしょうか。

ここでは、業務システムをフルスクラッチで開発する場合を想定した、簡易的なWBSのサンプルを紹介します。

工程	作業	主な内容	担当	開始予定	終了予定	進捗
要件定義	現行業務の確認	現在の業務手順や課題を整理	事業会社・システム開発会社	4/1	4/5	完了
要件定義	機能要件の整理	システムに必要な機能を整理	システム開発会社	4/6	4/12	完了
要件定義	要件確認・承認	要件定義の内容を確認し確定	事業会社	4/13	4/15	完了
基本設計	画面設計	画面項目や操作方法を設計	システム開発会社	4/16	4/25	完了
基本設計	データ設計	管理するデータや関連性を整理	システム開発会社	4/16	4/25	完了
詳細設計	機能詳細設計	各機能の具体的な処理内容を設計	システム開発会社	4/26	5/10	完了
開発	各機能の開発	設計内容をもとにプログラムを開発	システム開発会社	5/11	6/10	進行中
テスト	単体テスト	機能単位で正常に動作するか確認	システム開発会社	5/20	6/15	進行中
テスト	結合・総合テスト	機能間の連携やシステム全体を確認	システム開発会社	6/16	6/30	未着手
データ移行	移行データ準備	既存データを整理して移行準備	事業会社・システム開発会社	6/10	6/25	未着手
受入テスト	業務確認	実際の業務を想定してシステムを確認	事業会社	7/1	7/10	未着手
リリース	本番環境への反映	本番環境へシステムをリリース	システム開発会社	7/11	7/15	未着手

これはあくまで簡易的なサンプルです。実際のWBSでは、プロジェクトの規模や開発するシステムに応じて、さらに細かな作業へ分けて管理します。

特に注目したいのは、担当欄に「事業会社」の作業も含まれている点です。

システム開発では、システム開発会社だけが作業を行うわけではありません。現行業務の説明、要件の承認、データの準備、受入テストなど、事業会社側で行う作業もあります。

そのため、WBSを作成するときは「システム開発会社がいつまでに開発するか」だけではなく、「事業会社がいつまでに何を確認・判断・準備するか」まで含めることが重要です。

また、実際のプロジェクトでは、予定日だけでなく実績日、進捗率、前後の作業との関係、課題、遅延理由などの項目を追加すると、より実用的なWBSになります。

システム開発におけるWBSの作り方

プロジェクト全体の工程を整理する

まず、システム開発全体を大きな工程に分けます。

一般的には、要件定義、基本設計、詳細設計、開発、テスト、データ移行、受入テスト、リリースなどがあります。

ただし、実際に必要な工程はシステムによって異なります。

既存システムをリプレイスする場合にはデータ移行が大きな作業になりますし、外部サービスと接続するシステムであれば外部連携に関する設計やテストも必要です。

工程ごとの作業を細分化する

次に、大きな工程を具体的な作業へ分解します。

たとえば要件定義であれば、

・現行業務の確認
・課題の整理
・利用者の整理
・必要機能の整理
・画面要件の整理
・データ要件の整理
・外部システム連携の整理
・非機能要件の整理
・要件の確認、承認

といった作業が考えられます。

「要件定義をする」という一つの作業にまとめてしまうより、何を確認すれば要件定義が完了したと判断できるのかが明確になります。

担当者と期限を設定する

作業を洗い出したら、それぞれに担当者と期限を設定します。

ここで注意したいのが、システム開発会社側の作業だけでWBSを作らないことです。

事業会社側で確認・判断・準備しなければならない作業も含めて整理することで、実際のプロジェクトに沿ったスケジュールになります。

たとえば、システム開発会社が仕様確認を依頼しても、事業会社側の回答に2週間かかれば、その後の開発開始も遅れる可能性があります。

双方の作業を含めて計画することが重要です。

WBSは作って終わりではない

WBSで特に注意したいのが、プロジェクト開始時に作成したものを、そのまま最後まで使い続けてしまうことです。

システム開発では、実際にプロジェクトを進めるなかで、新しい課題が見つかったり、想定していた作業量が変わったりすることがあります。

そのため、WBSは定期的に更新する必要があります。

たとえば週次の進捗会議などで、

・予定通り完了した作業
・遅れている作業
・新たに発生した作業
・今後開始する作業
・事業会社側で判断が必要な事項

などを確認します。

重要なのは「予定との差があるかどうか」だけを見ることではありません。

遅れが発生しているのであれば、原因を確認し、その遅れがリリース予定日やほかの作業にどの程度影響するのかを判断する必要があります。

事業会社の担当者がWBSで確認すべきポイント

WBSはシステム開発会社だけが見るものではありません。

発注する事業会社側も確認することで、プロジェクトの状況を把握しやすくなります。

特に確認したいのは、「自社が対応する作業が明確になっているか」です。

システム開発では、事業会社側にも、業務内容の説明、仕様の確認、社内調整、データの準備、受入テストなど、さまざまな対応が発生します。

これらがWBSに含まれていなければ、システム開発会社側の作業だけが予定通り進んでも、プロジェクト全体では遅延する可能性があります。

また、作業が大きすぎないかも確認したいポイントです。

「開発：3か月」とだけ記載されているWBSでは、途中の進捗を判断することが難しくなります。

何をもってその作業が完了したと判断するのかがわかる程度まで分解されていることが重要です。

WBSがあってもシステム開発が遅れる理由

WBSを作成すれば、必ず予定通りにプロジェクトが進むわけではありません。

たとえば、要件が十分に整理されないまま開発を開始すると、後から仕様変更が繰り返されます。その結果、当初のWBSでは想定していなかった修正作業が増えていきます。

また、事業会社側の意思決定に時間がかかる場合もあります。

「誰が最終的に仕様を決めるのか」が明確でなければ、確認のたびに社内調整が発生し、開発が止まってしまうことがあります。

つまり、WBSそのものを細かく作ることだけが重要なのではありません。

プロジェクトの前提となる要件を整理し、担当者と意思決定の流れを明確にしたうえで、実態に合ったWBSを作ることが大切です。

フルスクラッチ開発ではWBSもプロジェクトに合わせる

パッケージシステムの導入と異なり、フルスクラッチ開発では企業独自の業務や要望をシステムに反映できます。

その分、必要となる作業もプロジェクトごとに異なります。

既存システムとの連携が多い企業もあれば、大量のExcelデータを新しいシステムへ移行しなければならない企業もあります。複数部署をまたぐ業務であれば、各部署との要件確認や受入テストにも時間が必要です。

そのため、過去のプロジェクトで使用したWBSをそのまま流用するのではなく、対象となる業務やシステムの特徴を踏まえて作成する必要があります。

システム開発会社を選ぶ際にも、「WBSを作ってくれるか」だけではなく、「自社の業務を理解したうえで、必要な作業を具体的に洗い出してくれるか」という視点が重要になります。

WBSはシステム開発会社との認識を合わせるための共通資料

WBSの大きな役割の一つが、事業会社とシステム開発会社の認識を合わせることです。

システム開発では、双方が同じゴールを目指していても、「いつまでに何をするのか」「どちらが対応するのか」という細かな認識がずれることがあります。

WBSがあれば、感覚ではなく具体的な作業をもとに会話できます。

「現在どこまで進んでいるのか」

「次に何を決めなければならないのか」

「どの作業が遅れているのか」

「事業会社側で何を準備する必要があるのか」

こうした情報を双方で共有できれば、問題が大きくなる前に対応しやすくなります。

WBSは単なるプロジェクト管理資料ではなく、事業会社とシステム開発会社が同じ認識で開発を進めるための共通資料として活用することが重要です。

システム開発におけるWBSのよくある質問

Q. WBSは誰が作成するのでしょうか？

プロジェクトマネージャーなど、プロジェクト全体を管理する担当者が中心となって作成するのが一般的です。ただし、一人ですべての作業を決めるのではなく、開発担当者や事業会社の担当者などと確認しながら作成することが重要です。特に事業会社側の確認、承認、データ準備などは、実際に必要な期間を双方で確認しておく必要があります。

Q. WBSはいつ作成すればよいですか？

基本的にはプロジェクトの初期段階で作成します。ただし、最初からすべての作業を完全に確定できるとは限りません。要件定義や設計が進むことで、新たに必要な作業が明らかになることもあります。そのため、最初に大枠を作成し、プロジェクトの進行に合わせて詳細化・更新していく方法が現実的です。

Q. WBSはどこまで細かく作ればよいですか？

進捗を判断できる程度まで作業を分けることが目安です。「システム開発：3か月」のような大きな単位では、途中でどこまで進んでいるのかわかりません。一方で、細かく分けすぎるとWBSの更新自体が負担になります。「その作業が完了したかどうかを明確に判断できるか」を基準にすると整理しやすくなります。

Q. WBSとガントチャートは何が違うのでしょうか？

WBSは、プロジェクトを完了するために必要な作業を洗い出して整理するためのものです。ガントチャートは、それぞれの作業をいつ実施するのか、時間軸に沿って視覚的に確認するためのものです。実務では、WBSで整理した作業に日程を設定し、ガントチャートとして表示して進捗を管理するケースも多くあります。

Q. WBSはExcelでも作成できますか？

はい。比較的小規模なシステム開発であれば、ExcelやスプレッドシートでもWBSを作成・管理できます。作業数や関係者が増えると更新や共有が複雑になるため、プロジェクト管理ツールを利用する方法もあります。重要なのは使用するツールではなく、関係者が同じ情報を確認でき、継続的に更新できることです。

Q. WBSの進捗率はどのように管理すればよいですか？

「0％・50％・100％」など一定のルールを設ける方法や、作業ごとに完了条件を決める方法があります。ただし、担当者の感覚だけで「90％完了」とすると、実際の進捗がわかりにくくなる場合があります。「設計書の作成完了」「レビュー完了」「承認完了」など、何をもって完了とするのかを明確にしておくことが大切です。

Q. WBSに事業会社側の作業も入れる必要がありますか？

入れることをおすすめします。業務内容の説明、仕様確認、社内承認、マスターデータの準備、受入テストなど、事業会社側が担当する作業は少なくありません。これらをWBSに入れていないと、開発作業は予定通りでも、事業会社側の確認待ちによってプロジェクト全体が遅れる可能性があります。

Q. 途中で仕様変更が発生した場合、WBSはどうすればよいですか？

仕様変更によって追加・変更される作業を確認し、WBSにも反映します。その際は作業を追加するだけではなく、開発工数やテスト、後続作業、リリース予定日への影響まで確認することが重要です。変更内容だけを管理するのではなく、「変更によって何が増え、どこに影響するのか」をWBS上でも把握できるようにします。

Q. WBSを作成してもプロジェクトが遅れることはありますか？

あります。WBSは遅延を完全になくすためのものではありません。要件変更、想定外の技術的な問題、確認の遅れなどによって予定が変わることはあります。重要なのは、遅れが発生した際に「どの作業が遅れているのか」「後続の作業にどの程度影響するのか」を早く把握し、対応を判断できる状態にしておくことです。

Q. WBSで決めた作業の開始予定日や終了予定日が遅れたらどうすればよいですか？

まず、遅れが発生した理由と、後続の作業への影響を確認します。重要なのは、予定日を過ぎたからといって、単純にWBSの日付を書き換えて終わらせないことです。

たとえば、設計の完了が3日遅れた場合、その後の開発やテストも3日ずつ遅れるとは限りません。後続作業との関係を確認し、担当者の調整や作業順序の変更などによって影響を抑えられる場合もあります。

一方で、リリース予定日に影響する可能性がある場合は、事業会社とシステム開発会社で早めに共有し、対応を検討する必要があります。WBSは予定通り進んでいるかを確認するだけではなく、遅れを早期に発見し、その影響と対応を判断するためにも活用することが重要です。

Q. システム開発会社から提示されたWBSで特に確認すべき点は何ですか？

まず、自社側で対応する作業が含まれているかを確認します。そのうえで、作業が大きな単位のままになっていないか、担当者と期限が明確になっているか、重要な確認・承認のタイミングが設定されているかを確認するとよいでしょう。WBSの細かさそのものよりも、「誰が、何を、いつまでに行えばプロジェクトが前に進むのか」がわかる状態になっていることが重要です。

まとめ

システム開発におけるWBSは、システムを完成させるために必要な作業を細かく分け、担当者や期限、進捗状況を管理するためのものです。

WBSを適切に作成することで、作業の抜け漏れを防ぎ、進捗状況や遅延している作業を把握しやすくなります。

一方で、WBSを作成すること自体が目的になってはいけません。

重要なのは、自社のシステム開発に必要な作業が十分に洗い出されていること、事業会社とシステム開発会社それぞれの担当が明確になっていること、そしてプロジェクトの進行に合わせて継続的に更新されていることです。

特にフルスクラッチのシステム開発では、企業ごとに業務や要件、既存システム、データ移行などの条件が異なります。一般的なWBSをそのまま当てはめるのではなく、実際の業務や開発内容に合わせて作成することが大切です。

WBSを「予定を記載する表」ではなく、「必要な作業を明確にし、事業会社とシステム開発会社が同じ認識でプロジェクトを進めるための管理手段」として活用することが、システム開発を円滑に進めるポイントです。

さいごに

フルスクラッチのシステム開発では、決められた製品を導入する場合とは異なり、企業ごとの業務や課題、既存システム、運用方法などを踏まえて開発を進める必要があります。そのため、システムそのものを作る技術力だけでなく、必要な作業を整理し、事業会社と認識を合わせながらプロジェクトを進める力も重要です。

当社フレシット株式会社では、お客様のご要望をそのままシステムにするのではなく、実際の業務やシステムを導入する目的を理解したうえで、必要な機能や進め方を整理し、フルスクラッチ（オーダーメイド）でシステムを開発しています。

「自社の業務に合うパッケージが見つからない」「Excelや既存システムでの管理に限界を感じている」「独自の業務に合わせたシステムを作りたい」といった場合も、業務の整理や要件定義の段階からご相談いただけます。

システム開発を検討しているものの、何から決めればよいかわからない場合でも問題ありません。お客様と一緒に必要なことを一つずつ整理し、開発中の進捗や課題も共有しながら、実際の業務で長く使えるシステムの実現を支援します。

自社の業務に合わせたフルスクラッチのシステム開発をご検討の際は、ぜひ当社フレシット株式会社へご相談ください。

＞＞フルスクラッチ（オーダーメイド）のシステム開発について詳細はこちら