システム開発を依頼したところ、見積書と一緒にWBSとガントチャートが送られてきた。しかし、2つの資料の違いがはっきりせず、どこを見れば見積を信じてよいのか判断できない。そんな不安を抱える発注担当者の方は少なくありません。
結論から言うと、WBSは「何を作業として含めるか（範囲と作業の中身）」を示す資料、ガントチャートは「いつ・誰が進めるか（時間と担当）」を示す資料です。この違いは、発注側にとっては次のように使い分けられます。
- WBS：見積と契約の範囲を確認する資料（何が含まれ、何が含まれないか）
- ガントチャート：納期と、発注者側のレビュー負担を確認する資料
- WBSの完了基準・引き継ぎ項目：保守契約へのつなぎ目を確認する資料
この記事では、WBSとガントチャートの違いを最初に整理し、そのうえで、開発会社から提出された資料を見積・契約・保守の判断にどう使うかを解説します。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
WBSとガントチャートの違い【比較表で結論】
まず、2つの違いを一覧にします。
項目 | WBS | ガントチャート |
|---|---|---|
答える問い | 何をやるか（What） | いつ・誰がやるか（When・Who） |
目的 | 作業の洗い出しと構造化 | スケジュール計画と進捗管理 |
表示形式 | ツリー構造（階層図・一覧表） | 横棒グラフ（バーチャート） |
時間情報 | 基本的になし | あり（開始日・終了日・期間） |
作成順 | 先に作る | WBSを基に後から作る |
発注者にとっての使いどころ | 見積・契約範囲の確認 | 納期・レビュー負荷の確認 |
WBSが「作業の設計図」だとすると、ガントチャートはその設計図に「時間と人」を載せた実行計画です。ガントチャートだけでは作業の抜け漏れは見つけにくく、WBSだけでは納期の現実性は分かりません。そのため、2つはセットで確認します。
WBSとは？見積の「範囲と根拠」が分かる資料
WBS（Work Breakdown Structure）は「作業分解構造図」と訳され、プロジェクト全体を段階的に細かい作業に分解してツリー状に整理したものです。プロジェクトマネジメントの標準的な知識体系であるPMBOKでも、プロジェクトの全体スコープを階層的に分解したものとして位置づけられています。
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 結合テスト
│ └── 4.3 受入テスト（発注者）
└── 5. リリース・移行・保守引き継ぎ
WBSには、成果物を基準に分解する「成果物型」と、作業の進め方を基準に分解する「プロセス型」があります。受託開発では、何を納品してもらうかが明確になる成果物型が基本です。
発注者にとって重要なのは、WBSが見積の積み上げ根拠になる点です。作業が細かく分かれていれば、見積金額がどの作業の積み上げなのかを追えます。逆に「開発一式」のような大きな塊のままだと、金額の根拠も範囲も確認できません。
ガントチャートとは？納期とレビュー負荷が分かる資料
ガントチャートは、縦軸にタスク、横軸に時間を取り、各タスクの期間を横棒で表したグラフです。20世紀初頭にヘンリー・ガントが工場の生産管理のために考案したとされ、現在はIT・建設・製造など幅広い分野で使われています。
主な構成要素は次のとおりです。
要素 | 内容 |
|---|---|
タスク（縦軸） | 実施する作業の一覧 |
時間軸（横軸） | 日・週・月など |
バー | タスクの開始日から終了日までの期間 |
マイルストーン | 要件定義完了、リリース日などの節目 |
依存関係 | 先行タスクが終わらないと始められない関係 |
担当者 | タスクを担当する人・チーム |
発注者がガントチャートで見るべきなのは、納期が現実的かと自社のレビュー・承認の時間が確保されているかの2点です。開発会社の作業だけが並び、発注者のレビュー期間が見当たらない場合は、後から自社の対応が遅れの原因にされかねません。
発注者はWBSをどう読む？見積・契約・保守の判断に使う
ここからが、発注者にとって最も重要なパートです。WBSとガントチャートの違いを知るだけでは、見積を信じてよいかは判断できません。資料を「何の判断に使うか」で確認観点を分けます。
見積の妥当性を確認する：WBSの作業と金額が対応しているか
見積書の項目とWBSの作業が、対応づけられるかを確認します。
- 見積項目とWBSの作業が紐づいているか：見積に「設計」「開発」しかなく、WBSにはテスト・移行・マニュアル作成があるのに金額が見えない、といったズレがないか
- タスクの粒度が適切か：「開発一式」のような大きな塊は根拠が追えません。目安として、1タスクが半日〜1週間（4〜40時間程度）に収まっていると進捗も金額も追いやすくなります
- 工数の根拠を聞けるか：各フェーズの人日（1人が1日働いた量）が、WBSの作業量と大きく食い違っていないか。納得できない場合は、算出の考え方を質問します
契約範囲を確認する：含まれる作業と含まれない作業を言葉にする
契約後の追加費用の多くは、「含まれていると思っていた作業が範囲外だった」というズレから生じます。WBSは、このズレを契約前に見つけるための資料です。
- 発注者側の作業が明記されているか：ヒアリングへの参加、成果物のレビュー・承認、受入テストなどが書かれていないWBSは、責任の所在が曖昧になります
- 抜けやすい作業が入っているか：データ移行、本番環境の構築、ユーザー向けマニュアル作成、運用・保守への引き継ぎなど
- 範囲外の作業が明示されているか：WBSに載っていない作業は、原則として見積に含まれていないと考えて確認します。気になる作業は「これは範囲内ですか」と書面で確認しましょう
- 変更が発生した場合の扱い：追加要望が出たときに、費用・納期をどう見直すか（変更管理のルール）を契約前に確認します
保守・運用への引き継ぎを確認する：完了基準と引き継ぎ項目
納品後の保守を見据えると、WBSの「完了基準」と「引き継ぎ」の項目が重要になります。
- 完了基準が定義されているか：「設計完了」「テスト完了」だけでは、何をもって完了かが曖昧です。「設計書がレビュー承認された状態」「テスト仕様書の全ケースが合格した状態」のように、状態で書かれているかを確認します
- 引き継ぎ作業が作業として存在するか：ソースコード、設計書、環境情報、運用手順などの引き渡しがWBSの作業として載っているか。載っていない場合は、納品後に追加費用が発生しやすい箇所です
- 保守契約との境界が分かるか：不具合対応（契約不適合責任の範囲）と、機能追加や運用サポート（保守契約の範囲）の線引きを、契約前に確認します
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
発注者がガントチャートで確認する5つのポイント
ガントチャートでは、納期の現実性と発注者側の負荷を確認します。
1. WBSの作業がすべて反映されているか WBSにはあった作業が、ガントチャートから消えていないかを確認します。
2. 依存関係が正しいか 設計が終わる前に開発が始まるなど、無理のある並びになっていないかを確認します。
3. バッファ（余裕期間）があるか 特にテスト工程は、不具合の修正が何度発生するか事前に読みにくい工程です。バッファのない計画は、少しの遅れがリリース日に直結します。
4. 発注者のレビュー・承認期間が確保されているか 成果物が納品されてから、発注者が確認してフィードバックする期間が含まれているかを確認します。自社のレビューが遅れた場合のスケジュールへの影響も、あらかじめ聞いておくと安心です。
5. リリース日から逆算して現実的か 「どう見てもタイト」と感じたら、着手前にスコープ（範囲）の見直しを相談します。納期を守るために品質確認が削られていないかも見ておきましょう。
契約前に開発会社へ確認したい質問例
資料を読んだうえで、次の質問を打ち合わせに持ち込むと、見積と契約の認識ズレを減らせます。
目的 | 質問例 |
|---|---|
見積 | 見積の各項目は、WBSのどの作業の積み上げですか |
見積 | 工数の算出根拠（類似案件の実績・前提条件）を教えてください |
契約範囲 | WBSに載っていない作業は、範囲外と考えてよいですか |
契約範囲 | 追加要望が出た場合、費用と納期はどう見直しますか |
発注者の負荷 | 当社側で必要なレビュー・判断の回数と、1回あたりの想定期間を教えてください |
スケジュール | 当社のレビューが遅れた場合、納期にどう影響しますか |
保守 | 納品時に引き渡される成果物（ソース・設計書・環境情報）の一覧を教えてください |
保守 | 不具合対応と保守契約の範囲の境界は、どこですか |
WBSとガントチャートの関係：なぜ両方必要か
最後に、基本の整理です。WBSとガントチャートは次の順に作ります。
- WBSで作業を洗い出す：何を・どこまでやるかのスコープを明確にする
- WBSを基にガントチャートを作る：各作業の開始日・終了日・担当者・依存関係を設定する
- ガントチャートで進捗を管理する：計画と実績のズレを定例会議で確認する
WBSだけの場合は、全体の作業は見えても納期の見通しが立たず、期限間際に残作業の多さに気づくリスクがあります。ガントチャートだけの場合は、スケジュールは見えても、そもそも必要な作業が網羅されているか確認できず、後から作業が追加されて計画が崩れやすくなります。
WBS・ガントチャートでよくある失敗と対策
発注者がプロジェクトに関わる場合も、次の失敗は他人事ではありません。
WBSの失敗：粒度が粗すぎる・細かすぎる 粗すぎると範囲と金額の根拠が追えず、細かすぎると管理の手間が増えます。1タスクを4〜40時間程度に収めるのが目安です（最小8時間・最大80時間を基準にする「8/80ルール」もあります）。
WBSの失敗：スコープクリープ 途中の追加要望を受け入れ続けた結果、作業が膨らんで納期や予算が崩れるケースです。要望が出たら、範囲を見直し、費用・納期への影響を見積もってから判断する変更管理の手順を決めておきます。
ガントチャートの失敗：更新されず形骸化する 最初の計画のまま誰も更新しなくなるケースです。週次または隔週の定例にガントチャートの確認を組み込み、遅延の報告ルールを決めておきましょう。
WBS・ガントチャートの作り方（簡易版）
自社でプロジェクトを管理する場合の最低限の手順です。
WBSの作り方（4ステップ）
- プロジェクトの目標と成果物を定義する
- 大分類（要件定義→設計→開発→テスト→リリース）を洗い出す
- 各フェーズをサブタスクに分解する
- 担当者・期限・完了基準を設定する
ガントチャートの作り方（4ステップ）
- WBSのタスクを工程順に縦軸へ並べる
- 各タスクの開始日・終了日を設定する
- 依存関係を矢印などで結ぶ
- 担当者とマイルストーンを設定する
作成にはExcelのほか、Backlog・Asana・Jootoなどのプロジェクト管理ツールも使えます。チームの規模と管理の複雑さに合わせて選びましょう。
まとめ
WBSとガントチャートの違いと、発注判断での使い方を整理します。
- WBSは「何を・どこまでやるか」を示す資料。見積の根拠と契約範囲の確認に使う
- ガントチャートは「いつ・誰がやるか」を示す資料。納期の現実性と、発注者のレビュー負荷の確認に使う
- WBSの完了基準と引き継ぎ項目は、納品後の保守契約へのつなぎ目の確認に使う
- 発注者側の作業（ヒアリング・レビュー・受入テスト）がWBSとガントチャートの両方に入っているかを必ず確認する
開発会社から資料が届いたら、まず「見積項目とWBSの作業が対応しているか」から確認してみてください。システム開発の依頼前に確認すべき項目をまとめた資料も用意していますので、あわせて活用してください。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
よくある質問
- WBSとガントチャートの一番大きな違いは何ですか？
WBSは「何をやるか」という作業の中身を階層的に整理したもので、ガントチャートは「いつ・誰がやるか」という時間と担当を横棒グラフで示したものです。WBSには基本的に時間軸がなく、ガントチャートには時間軸があります。
- WBSは必ずガントチャートより先に作らないといけませんか？
原則としてWBSを先に作成することを推奨します。作業を網羅的に洗い出してからでないと、ガントチャートに必要な作業が抜け落ち、スケジュールが崩れるリスクがあります。
- WBSとガントチャートは開発会社が作るもので、発注者は確認するだけでよいですか？
確認だけでは不十分です。発注者側の作業（ヒアリング参加・成果物レビュー・受入テスト）がWBSに明記され、ガントチャートにレビュー期間が組み込まれているかを、発注者自身が確認・要求する必要があります。
- 見積書の金額が妥当かを、WBSでどう判断すればよいですか？
見積の各項目がWBSのどの作業の積み上げなのかを対応づけて確認します。対応が取れない項目や、WBSにあるのに見積で金額が見えない作業があれば、開発会社に算出根拠を質問してください。
- ガントチャートで遅延が発生したとき、発注者はいつ介入すればよいですか？
マイルストーン（設計完了・テスト開始など）に達しても遅延が解消されていない時点が目安です。フェーズをまたぐ遅延はスコープや予算に直結するため、速やかに状況確認と対応策の協議を求めましょう。
- WBSやガントチャートのひな型は発注者が事前に用意すべきですか？
基本的に開発会社が作成するため、発注者がひな型を用意する必要はありません。ただし、発注者側の作業をWBSに含めること、ガントチャートにレビュー期間を確保することの2点は、契約前に明示的に伝えておくことをおすすめします。
