プロジェクト管理の現場で「WBS」と「ガントチャート」という言葉を耳にしたとき、「似たようなものだろう」と感じる方は多いのではないでしょうか。実際、この2つを混同しているチームは少なくなく、うまく使い分けられずにプロジェクトが混乱するケースも見られます。
WBSとガントチャートはそれぞれ異なる役割を持ちながら、組み合わせることで真価を発揮するツールです。WBSで「何をするか」を整理し、ガントチャートで「いつ・誰がするか」を計画する。この2段階のアプローチが、プロジェクトの成功を支えます。
特にシステム開発を外注している方や、初めてプロジェクト管理に取り組む担当者にとっては、開発会社からWBSやガントチャートを受け取っても「何を確認すればいいか分からない」という状況が生じやすいものです。
この記事では、WBSとガントチャートの基本的な定義・違い・使い方を解説したうえで、システム開発の現場での実践的な活用法と、発注者が押さえておくべき確認ポイントまで詳しく紹介します。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
WBSとは？プロジェクト管理における役割と目的
WBSの定義と仕組み（ツリー構造・タスクの階層化）
WBS（Work Breakdown Structure）とは、日本語で「作業分解構造図」と呼ばれるプロジェクト管理手法です。プロジェクト全体を段階的に細かい作業（タスク）に分解し、ツリー状（階層構造）に整理したものです。
プロジェクトマネジメントの国際標準であるPMBOK（プロジェクトマネジメント知識体系ガイド）では、WBSを「プロジェクトチームが実行すべき作業の全体スコープの階層的分解」と定義しています。
具体的なイメージとしては、プロジェクト全体を「大分類 → 中分類 → 小分類（実際の作業）」というように木の枝のように分解していきます。
例として、「Webシステムの新規開発」というプロジェクトをWBSで整理すると：
Webシステム新規開発
├── 1. 要件定義
│ ├── 1.1 ヒアリング・現状調査
│ ├── 1.2 要件定義書作成
│ └── 1.3 要件のレビュー・承認
├── 2. 設計
│ ├── 2.1 基本設計
│ └── 2.2 詳細設計
├── 3. 開発
│ ├── 3.1 フロントエンド開発
│ └── 3.2 バックエンド開発
├── 4. テスト
│ ├── 4.1 単体テスト
│ └── 4.2 結合テスト
└── 5. リリース・移行
このようにタスクを分解することで、プロジェクトの全体像が一目で把握できるようになります。
WBSには主に2つの種類があります：
- 成果物型WBS：最終的な成果物（システム、機能など）を基準にタスクを分解する。「何を作るか」が明確な受託開発プロジェクトに適している
- プロセス型WBS：作業の進め方・フェーズを基準にタスクを分解する。「どう進めるか」が重要な社内プロジェクトや研究開発に適している
WBSを作る目的・3つのメリット
メリット1：タスクの見える化（抜け漏れの防止）
WBSを作成することで、プロジェクトに必要な作業をすべて洗い出せます。「考えてみたら設計工程が丸ごと抜けていた」「テスト期間を確保し忘れていた」といった致命的なミスを未然に防げます。
メリット2：工数・スケジュールの見積もり精度向上
タスクを細分化することで、それぞれの作業にかかる時間（工数）を現実的に見積もれるようになります。大きなかたまりのまま「設計：2週間」と見積もるよりも、細かく分解した上で積み上げた方が精度が高くなります。
メリット3：役割分担・責任の明確化
各タスクに担当者を割り当てることで、「誰が何を担当するか」が明確になります。チーム全員が同じ認識を持てるため、コミュニケーションのズレや作業の重複・漏れを防げます。
ガントチャートとは？スケジュール管理の基本ツール
ガントチャートの定義と構成要素
ガントチャートとは、プロジェクトのスケジュールや工程を視覚的に管理するためのグラフです。縦軸に「タスク・作業工程」、横軸に「時間（日付）」を配置し、各タスクの期間を横向きの棒グラフ（バー）で表します。
20世紀初頭にアメリカの機械工学者ヘンリー・ガント（Henry Gantt）が考案したことからその名がつきました。もともとは工場の生産工程管理のために生まれたツールですが、現在ではIT・建設・製造など幅広い業界のプロジェクト管理で活用されています。
ガントチャートの主な構成要素：
要素 | 内容 |
|---|---|
タスク（縦軸） | 実施する作業の一覧 |
時間軸（横軸） | 日付・週・月など |
バー（棒グラフ） | タスクの開始日〜終了日を表す |
マイルストーン | プロジェクトの重要な節目（例：設計完了、リリース日） |
依存関係 | 先行タスクが完了しないと開始できないタスクの関係 |
担当者 | 各タスクを担当する人・チーム |
ガントチャートを使う目的・3つのメリット
メリット1：スケジュールの全体像を一目で把握できる
「いつ・誰が・何をしているか」がひと目でわかります。プロジェクト全体の流れと各タスクの位置づけを視覚的に確認できるため、状況の把握が容易です。
メリット2：進捗状況をリアルタイムで管理できる
各タスクの進捗（完了率）をバーに反映させることで、計画と実績のズレを即座に把握できます。どのタスクが遅れているか、その遅れがプロジェクト全体にどう影響するかを早期に検知できます。
メリット3：タスク間の依存関係が見える
「AタスクがB・Cタスクの前提になっている」という依存関係を矢印（→）で表現することで、ボトルネックとなっているタスクを特定しやすくなります。どのタスクを優先的に対処すべきかの判断が容易になります。
WBSとガントチャートの違い — 役割と使うタイミングの比較
WBSとガントチャートは似て非なるものです。よく「どちらかを使えばいい」と思われがちですが、それぞれ異なる役割を担っています。
役割の違い（「何を」管理するか vs「いつ」管理するか）
観点 | WBS | ガントチャート |
|---|---|---|
主な目的 | 作業内容の洗い出しと構造化 | スケジュールの計画と進捗管理 |
答える問い | 「何を（What）やるか？」 | 「いつ（When）・誰が（Who）やるか？」 |
管理対象 | タスクの階層と網羅性 | タスクの時間・期間・担当者 |
作成するタイミングと形式の違い
観点 | WBS | ガントチャート |
|---|---|---|
作成タイミング | 先に作成（プロジェクト計画の最初） | 後から作成（WBSを基に作成） |
表示形式 | ツリー構造（階層図） | バーチャート（横棒グラフ） |
時間軸 | なし（タスクの構造のみ） | あり（開始日・終了日・期間） |
WBSとガントチャートの違い・比較表（まとめ）
項目 | WBS | ガントチャート |
|---|---|---|
目的 | 作業の洗い出し・構造化 | スケジュール管理・進捗管理 |
作成タイミング | プロジェクト計画の初期 | WBS作成後 |
表示形式 | ツリー構造 | 横棒グラフ（バーチャート） |
時間情報 | なし | あり（開始日・終了日） |
担当者情報 | あり（設定可能） | あり（明示） |
管理の粒度 | タスクの階層と網羅性 | タスクのスケジュールと進捗 |
得意なこと | 「何を・どこまでやるか」の整理 | 「いつ・誰がやるか」の可視化 |
WBSとガントチャートの関係 — なぜ両方必要か
WBSとガントチャートの作成フロー
WBSとガントチャートは「セット」で使うことで真価を発揮します。プロジェクト管理の標準的なフローは以下のとおりです：
ステップ1：WBSでタスクを洗い出す プロジェクト全体を構造化し、必要な作業を網羅的に整理します。「何を・どこまでやるか」のスコープを明確にします。
ステップ2：WBSを基にガントチャートを作成する 洗い出したタスクを時間軸に配置し、各タスクの開始日・終了日・担当者を設定します。タスク間の依存関係も整理します。
ステップ3：ガントチャートで進捗を管理する プロジェクト進行中は定期的にガントチャートを更新し、計画と実績のズレを管理します。
このように、WBSは「何をするか」の設計図、ガントチャートはその設計図に「時間と人」を加えた実行計画と捉えることができます。
どちらか一方だけ使うときのリスク
WBSだけ使う場合： タスクの全体像は見えますが、「いつ・誰が・どのくらいの期間で」という情報がありません。スケジュール管理ができず、締め切り間際に「こんなにタスクが残っていたのか」と気づくリスクがあります。
ガントチャートだけ使う場合： スケジュールは管理できますが、「そもそもすべきタスクを網羅できているか」の確認が難しくなります。作業の抜け漏れが発生しやすく、後から大量のタスクが追加されてスケジュールが崩壊するリスクがあります。
両方を組み合わせることで「やるべきことを網羅しつつ、スケジュール通りに進められる」状態が実現します。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
システム開発プロジェクトでのWBS・ガントチャート活用法
システム開発のフェーズとWBSの対応
システム開発では、一般的に以下のフェーズでプロジェクトが進行します。WBSはこれらのフェーズを大分類として、さらに細かいタスクへと分解します：
フェーズ | WBSの主なタスク例 |
|---|---|
要件定義 | ヒアリング実施、要件定義書作成、レビュー・承認 |
基本設計 | 画面設計、DB設計、外部連携設計 |
詳細設計 | 機能別の詳細仕様書作成 |
開発 | フロントエンド開発、バックエンド開発、API連携開発 |
テスト | 単体テスト、結合テスト、受入テスト |
リリース | 本番環境構築、データ移行、リリース作業 |
システム開発のWBSで重要なのは、「開発会社だけでなく、発注者側が行う作業もWBSに含める」ことです。例えば、要件定義のヒアリングへの参加、成果物のレビュー・承認、受入テストの実施など、発注者側にも多くのタスクがあります。これらをWBSに明記しておくことで、「誰が何をいつまでに行うか」が明確になります。
開発スケジュールをガントチャートで管理するポイント
システム開発のガントチャートでは、以下の点を特に意識することが重要です：
依存関係の整理 要件定義が完了しなければ設計を始められない、設計が完了しなければ開発を始められない、というようにシステム開発では前のフェーズの完了が次のフェーズの開始条件になっていることが多くあります。これらの依存関係をガントチャートに明示することで、遅延が発生した際の影響範囲をすぐに把握できます。
マイルストーンの設定 「要件定義完了（○月○日）」「設計完了（○月○日）」「リリース（○月○日）」など、重要な節目をマイルストーンとして設定します。マイルストーンを意識することで、プロジェクト全体の進捗が把握しやすくなります。
バッファ（余裕時間）の確保 特にテスト工程では、不具合の発生・修正サイクルが読めないため、十分なバッファを設けることが重要です。「バッファなし」で計画を立てると、少しの遅れが連鎖してリリース日に間に合わないという事態になりやすいです。
発注者が確認すべきWBS・ガントチャートのチェックポイント
開発会社からWBSやガントチャートを受け取った際、発注担当者は何を確認すればよいのでしょうか。以下のチェックポイントを参考にしてください。
WBSを受け取ったときの5つの確認ポイント
チェック1：プロジェクトの全フェーズが網羅されているか 要件定義〜リリースまでの主要フェーズがすべて含まれているか確認します。特に「移行・データ移行」「運用・保守への引き継ぎ」「ユーザー向けマニュアル作成」などが漏れていないか注意が必要です。
チェック2：発注者側のタスクが明記されているか WBSには開発会社側の作業だけでなく、発注者側が行うべきタスク（ヒアリングへの参加、成果物のレビュー、受入テストなど）も含まれているはずです。これらが明記されていない場合は、責任の所在が不明確になりやすいため確認が必要です。
チェック3：タスクの粒度が適切か タスクが大きすぎると進捗が把握しにくく、細かすぎると管理が煩雑になります。目安として「1タスクにかかる時間が半日〜1週間程度」の粒度が管理しやすいとされています。「システム開発」のような大きすぎるタスクは分解が足りず、逆に「特定の変数名を決める」のような細かすぎるタスクは管理コストが高くなります。
チェック4：各タスクに担当者と期限が設定されているか 「誰が・いつまでに」が明確でないタスクは、実際には誰も対応しないまま放置されるリスクがあります。担当者が空欄のタスクや期限が設定されていないタスクには注意が必要です。
チェック5：成果物・完了基準が定義されているか 「設計完了」「テスト完了」という表現だけでは、何をもって「完了」とするかが曖昧です。「○○の設計書がレビュー承認された状態」「テスト仕様書に記載された全ケースが合格した状態」というように、完了基準が明確に定義されているか確認しましょう。
ガントチャートを受け取ったときの5つの確認ポイント
チェック1：全WBSのタスクがガントチャートに反映されているか WBSで洗い出したタスクがすべてガントチャートに含まれているか確認します。「WBSにはあったが、ガントチャートからは消えている」というタスクがないかチェックしましょう。
チェック2：タスクの依存関係が正しく設定されているか 前のタスクが完了しなければ始められないタスク（依存関係）が正しく設定されているか確認します。例えば「設計が完了する前に開発を開始するスケジュールになっていないか」などを確認します。
チェック3：バッファが確保されているか 各フェーズの間や、テスト工程の後にバッファが確保されているか確認します。バッファなしで「ぎゅうぎゅうに詰め込んだスケジュール」は、少しの遅れが全体に波及する危険性が高くなります。
チェック4：発注者側のレビュー・承認期間が確保されているか 開発会社から成果物が上がってきたとき、発注者側がレビュー・フィードバックを行う期間がスケジュールに含まれているか確認します。「開発完了と同時にリリース」というスケジュールでは、受入テストや最終確認の時間が取れません。
チェック5：リリース日から逆算してスケジュールに余裕があるか 最終的なリリース予定日から逆算して、現実的な期間でプロジェクトが完了できるかを確認します。「どう見てもスケジュールがタイト」と感じる場合は、着手前に開発会社とスコープ（対象範囲）の見直しを相談することが重要です。
WBS・ガントチャートでよくある失敗と対策
プロジェクト管理の現場では、WBSとガントチャートを導入しても効果を発揮できないケースが多く見られます。代表的な失敗パターンと対策を紹介します。
WBSでよくある失敗（タスクの粒度問題・抜け漏れ）
失敗1：タスクが細かすぎて管理できなくなる WBS作成に熱心になりすぎて、「ファイルの命名規則を決める」「ミーティングの日程を確認する」といった数十分以内に終わるタスクまで細かく分解してしまうケースです。管理コストが増大し、かえって非効率になります。
対策：1つのタスクにかかる時間を「半日〜1週間（4〜40時間程度）」を目安にするとよいでしょう。いわゆる「8/80ルール」として、最小8時間・最大80時間の範囲に収めるという基準も参考になります。
失敗2：初期設計後に大量のタスクが追加される（スコープクリープ） プロジェクト途中で「これもやってほしい」という追加要望を安易に受け入れ続けた結果、WBSがどんどん肥大化してスケジュールが崩壊するケースです。
対策：追加要望が発生した際は、必ずプロジェクトのスコープ（対象範囲）を再定義し、影響する工数・期間・コストを見積もったうえで変更可否を判断する「変更管理プロセス」を設けることが重要です。
ガントチャートでよくある失敗（形骸化・更新されない）
失敗1：ガントチャートが最初の計画のまま更新されない 作成当初は詳細なガントチャートを作ったものの、プロジェクトが進むにつれて誰も更新しなくなり、実態と全く異なる「名ばかりガントチャート」になってしまうケースです。
対策：週次や隔週でのガントチャートレビューをプロジェクトの定例会議に組み込みます。「現在の進捗に合わせたガントチャートの更新」を担当者の通常業務として位置づけることが重要です。
失敗2：担当者が誰も進捗を報告しない ガントチャートはあるが、各担当者が「完了した」「遅れている」という情報を報告しないため、PMが状況を把握できないまま締め切りを迎えるケースです。
対策：ガントチャートの更新フローを明確にし、各担当者がタスク完了時・遅延発生時に速やかに更新（または報告）するルールを設けます。プロジェクト管理ツール（Backlog、Asana等）を使うと更新の負担を軽減しやすくなります。
WBS・ガントチャートの作成ステップ
WBSの作り方（4ステップ）
ステップ1：プロジェクトの目標と成果物を定義する WBSを作る前に、「このプロジェクトが完了した状態は何か」を明確にします。目標が曖昧なままタスクを洗い出してもスコープが定まりません。
ステップ2：大分類のタスク（フェーズ）を洗い出す プロジェクト全体を大きなかたまり（フェーズ）に分けます。システム開発であれば「要件定義 → 設計 → 開発 → テスト → リリース」のようなフェーズ分けが基本です。
ステップ3：各フェーズをサブタスクに分解する 大分類の各フェーズをさらに細かい作業に分解します。「設計」であれば「画面設計・DB設計・外部連携設計」というように、具体的な作業項目まで落とし込みます。
ステップ4：担当者・期限・完了基準を設定する 各タスクに担当者を割り当て、期限と「何をもって完了とするか」の基準を設定します。
ガントチャートの作り方（WBSから変換する流れ）
ステップ1：WBSのタスクを縦軸に並べる WBSで作成したタスク一覧を、実施順序（工程順）に並べてガントチャートの縦軸に配置します。
ステップ2：各タスクの開始日・終了日を設定する 各タスクの開始日と終了日を決め、横軸の時間軸上にバーを配置します。依存関係を考慮しながら設定します。
ステップ3：タスク間の依存関係を矢印で結ぶ 「AタスクがBタスクの前提」という依存関係を矢印で表現し、ボトルネックとなるタスクを明確にします。
ステップ4：担当者を割り当て、マイルストーンを設定する 各タスクに担当者を設定し、重要な節目となるマイルストーン（○○完了・○○提出など）を設定します。
ガントチャートの作成にはエクセルで作成する方法から、Backlog・Asana・Jootoなどのプロジェクト管理ツールを活用する方法まで様々な選択肢があります。チームの規模や管理の複雑さに合わせて、適切な方法を選びましょう。
まとめ
この記事では、WBSとガントチャートの違いと活用方法について解説しました。最後に要点を整理します。
WBSとガントチャートの違い（3行まとめ）
- WBSは「何を・どこまでやるか」を整理するツール（ツリー構造）
- ガントチャートは「いつ・誰がやるか」を計画するツール（バーチャート）
- 2つはセットで使う：先にWBSでタスクを洗い出し、次にガントチャートでスケジュール化する
システム開発プロジェクトで特に重要なポイント
- 発注者側のタスク（レビュー・承認・受入テスト等）もWBSに含めること
- ガントチャートには発注者側のレビュー・承認期間を確保すること
- バッファを確保し、特にテスト工程に余裕を持たせること
まずはWBSで作業の全体像を整理することから始めてみてください。シンプルなエクセルシートでも、「フェーズ → サブタスク → 担当者・期限」という構造で作るだけで、プロジェクトの見通しが大きく改善されます。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
