WBSの具体的な作り方から実例・テンプレ集まとめ

新しいプロジェクトを任されたものの、WBSを作れと言われて手が止まってしまう瞬間は多くの職場で起きています。
タスクを書き出してみたものの抜け漏れが不安で、メンバーとの認識もそろわず、スケジュール表もなかなか完成しないという声もよく聞かれます。
この記事では、WBSの意味から作り方、具体例、テンプレート活用のコツまでを順番に整理し、今日から自分のプロジェクトで使えるレベルまで落とし込んでいきます。
「なんとなく分解したタスク一覧」ではなく、プロジェクト成功につながる実務的なWBSを目指していきます。

WBSの基本的な意味と役割を理解する

ここでは、WBSとは何かという基本と、なぜプロジェクトで重要なのかを整理します。
まず全体像を押さえることで、後半の作り方や例が自分の仕事にどうつながるかをイメージしやすくなります。
「結局WBSで何をしたいのか」という目的を明確にしながら読み進めてください。

まず押さえたいWBSの結論と読みどころ

WBSは、プロジェクトの成果物と作業を階層構造で整理し、やるべき仕事の全体像と抜け漏れを見える化するための表や図です。
プロジェクト管理の標準では、プロジェクトのスコープを階層的に分解した構造として位置づけられています。
(プロジェクトマネジメント協会)

読み進める上で押さえておきたい要点は次の三つです。

1つ目は、WBSは「作業そのもの」ではなく「仕事の構造」を表すものだという点です。
2つ目は、タスクの抜け漏れや重複を減らし、スケジュールやガントチャート、要員計画の土台になるという点です。
3つ目は、プロジェクトのタイプごとにある程度パターン化できるため、毎回ゼロから作るものではないという点です。

この三つを頭に入れておくと、後半の作り方や例を読んだときに、自分のプロジェクトではどこをどう修正すればよいかを判断しやすくなります。

WBSの意味と構造をシンプルに整理する

WBSは「Work Breakdown Structure」の略で、日本語では作業分解構成図などと呼ばれます。
上のレベルにある大きな成果物やフェーズを、下のレベルでより小さな要素やタスクに分解していくのが特徴です。

典型的な構造は次のようなイメージです。

• レベル1：プロジェクト全体
• レベル2：フェーズや大きな成果物
• レベル3：サブ成果物や大きめの作業グループ
• レベル4：担当者に割り当てられるタスク単位

多くの場合、一番下の段にいる要素を「この担当者が、この期間に、このアウトプットを出す」レベルまで細かくすることが実務上の目安になります。
標準的な解説でも、スコープやコスト、スケジュールの基準線をそろえる土台としてWBSが位置づけられています。
(プロジェクトマネジメント協会)

WBSが力を発揮する代表的なプロジェクト

WBSはほぼすべてのプロジェクトで使えますが、特に効果が大きい代表的なパターンを挙げると次のようになります。

• システム開発やシステム導入
• WebサイトやLPの制作、リニューアル
• 製品開発や新サービス立ち上げ
• 会社の移転、拠点開設などのイベント的なプロジェクト
• 社内制度の新設や業務プロセス改善

例えばシステム開発では「要件定義」「設計」「実装」「テスト」「リリース」といったフェーズごとにタスクを分解していくことで、レビュー漏れやテスト漏れに気付きやすくなります。
Web制作では、「企画」「構成」「デザイン」「コーディング」「公開」「運用」といった流れを分解することで、依頼元との認識合わせにも役立ちます。

現場では、同じようなプロジェクトが何度も繰り返されるため、これらの代表パターンをベースに少しずつ標準WBSを育てていくチームも多く見られます。

WBSに関するよくある誤解と注意点

WBSには、現場でよくある誤解や注意したいポイントがあります。

1つ目は「タスクを細かくしすぎればよい」という誤解です。
細分化しすぎると管理コストだけが増え、かえって現場が疲弊してしまいます。
作業時間の目安が1〜数日程度でイメージできる粒度を目標にするとバランスが取りやすくなります。

2つ目は「WBSを作れば計画は完成」という考え方です。
WBSはあくまでスコープや作業構造を示すもので、工数見積もりやガントチャート、リスク管理などと組み合わせて初めて計画が機能します。

3つ目は「WBSは一度作ったら固定」という思い込みです。
実務では、要件変更やリスク顕在化に合わせてWBSも更新していくことが多く、変化に合わせて見直しやすい構造になっているかどうかが重要な判断基準になります。

失敗しにくいWBSの作り方ステップとコツ

ここでは、初めてでも迷いにくいWBSの作り方をステップで解説します。
現場でよく使われる作り方をベースに、つまずきやすいポイントや判断基準も合わせて紹介します。
「とりあえずタスクを書き出す」段階から一歩進んで、チームで共有しやすいWBSを目指します。

最短ルートでWBSを作る手順の全体像

多くの解説で紹介されているWBS作成の流れは、要約すると次のようなステップになります。
(タイムクラウド)

1. プロジェクトのゴールと成果物を明確にする
2. フェーズや大きな作業のかたまりに分ける
3. 各かたまりをタスクレベルまで分解する
4. 抜け漏れや重複がないかを複数人でチェックする
5. 必要に応じて担当者や期間、優先度を紐付ける

ポイントは、いきなり細かいタスクから考えないことです。
まずはゴールと成果物をはっきりさせたうえで、フェーズなどの大きな箱を作り、最後に細かくしていくほうが全体の筋が通りやすくなります。

作成前に確認しておきたい前提条件

WBSを作る前に確認しておくと、後からの手戻りを減らせる前提条件があります。

• プロジェクトのゴールが一文で説明できるか
• 主要な成果物が列挙できているか
• 予算や期間などの大きな制約条件が分かっているか
• 関係者やチームメンバーが大まかに把握できているか

例えば、ゴールが「とにかくいいサイトを作る」のように曖昧なままだと、WBSも作業者ごとに解釈がずれてしまいます。
一方、「新サービスの紹介サイトを、〇月末までに公開し、問い合わせを月〇件以上獲得できる状態にする」のようにゴールが具体的だと、分解の方向性がそろいやすくなります。

現場では、キックオフミーティングの前後でこれらの前提条件を一度確認し、必要なら簡単なプロジェクト憲章やメモにまとめてからWBS作りに入るケースが多く見られます。

WBS作成の具体的な5ステップ

ここでは、実務で使いやすい形でステップを5つに整理します。

1. ゴールと主要成果物を書き出す
2. 成果物から逆算してフェーズを決める
3. 各フェーズを「誰が何を出すか」で分解する
4. タスクの粒度をそろえながら詳細化する
5. チェックと修正を繰り返す

具体的なイメージが持てるように、会話形式の例で見てみます。

Aさん：このプロジェクトのゴールは何ですか。
Bさん：新サービスの紹介サイトを作って、リリース日までに公開することです。
Aさん：では成果物は、そのサイト本体と、原稿、デザインデータなどですね。
Bさん：はい。
Aさん：それなら、フェーズは企画、原稿作成、デザイン、実装、テスト、公開あたりになりそうです。

このように、成果物とフェーズの会話から始めると、自然とWBSの上位レベルが形になっていきます。

つまずきやすいポイントと判断基準

WBS作成でつまずきやすいポイントは、主に次の三つです。

1つ目は「どこまで細かく分解するかが分からない」という悩みです。
判断基準としては、次のような観点が使えます。

• 作業時間の目安が1〜3日程度か
• 誰が担当するかが明確に決められるか
• 完了条件を一言で説明できるか

この三つを満たしていれば、ひとまずそのレベルで止めるのが現実的です。

2つ目は「似たようなタスクが何度も出てきて整理できない」という問題です。
この場合、フェーズや成果物の切り方を見直すと解決することが多く、構造の見直しを優先するか、タスク名の整理を優先するかを意識的に切り分けると混乱が減ります。

3つ目は「メンバー間で認識がずれる」という課題です。
ここでは、WBSを1人で作り込むのではなく、ドラフトを共有して複数人でレビューするのが有効です。
プロジェクト管理の解説でも、複数人でのチェックが作業漏れの防止につながるとされています。
(スモールビジネスを世界の主役に フリー株式会社)

WBSの例・テンプレート活用と現場での運用

最後に、具体的なWBSの例と、テンプレートや標準WBSの活用方法を見ていきます。
自分のプロジェクトと近い例をイメージしながら読むことで、実際のドラフト作成にスムーズに移行できるようになります。
また、運用段階でのWBSの使い方も合わせて意識しておくと、作りっぱなしになりにくくなります。

システム開発プロジェクトのWBS例

システム開発プロジェクトのシンプルなWBSの例を、上から順に挙げてみます。

• レベル1：新システム開発プロジェクト
• レベル2：企画、要件定義、設計、開発、テスト、リリース、保守準備
• レベル3（例）
  • 要件定義：業務ヒアリング、要件整理、要件レビュー
  • 設計：基本設計、詳細設計、インフラ設計
  • 開発：環境構築、実装、単体テスト
  • テスト：結合テスト、総合テスト、受入テスト支援

さらにレベル4として、例えば「業務ヒアリング」を個別の部門ごとのタスクに分解するなど、プロジェクト規模に応じて細かくしていきます。

実務では、過去の類似プロジェクトのWBSをベースに、今回特有の要素を追加したり不要な要素を削ったりしながら調整していくケースが多く見られます。

Webサイト制作プロジェクトのWBS例

Webサイト制作のプロジェクトでは、次のような構造がよく使われます。

• レベル1：企業Webサイトリニューアルプロジェクト
• レベル2：企画、情報設計、デザイン、コンテンツ制作、コーディング、テスト、公開、運用設計
• レベル3（例）
  • 企画：現状分析、要件整理、サイトコンセプト策定
  • 情報設計：サイトマップ作成、ワイヤーフレーム作成
  • デザイン：トンマナ定義、トップページデザイン、下層テンプレートデザイン
  • コンテンツ制作：原稿作成、写真撮影、原稿レビュー
  • コーディング：テンプレート実装、レスポンシブ対応、CMS設定

ここでも、レベル4として「ページごとの原稿作成」「特集ページのワイヤーフレーム作成」などに細分化することで、担当者とスケジュールを具体的に割り当てやすくなります。

現場では、営業用LP、採用サイト、コーポレートサイトなど、サイトの目的ごとに少しずつ異なるWBSパターンを持ち回るチームも多く、これが標準WBSのベースになっていきます。

テンプレートと標準WBSの作り方と使い分け

WBSを毎回ゼロから作るのは非効率であり、解説でもプロジェクトタイプごとの標準WBSを持つことが推奨されています。
(株式会社システムインテグレータ)

テンプレートと標準WBSの考え方は次のように整理できます。

• テンプレート
  • Excelやスプレッドシート、プロジェクト管理ツールに用意するフォーマット
  • 行や列の構成、入力項目、色分けルールなどをあらかじめ決めておくもの
• 標準WBS
  • プロジェクトタイプごとの「よくあるタスク構成」そのもの
  • 例えば「システム開発標準WBS」「Web制作標準WBS」など

運用のポイントとしては、次のような流れが現実的です。

1. まずは1つの代表プロジェクトで標準WBS候補を作る
2. 実際の案件で使いながら、漏れや重複を見つけて修正する
3. 改善されたWBSをチームの標準として保存し、次の案件で再利用する

プロジェクト管理ツールの中には、WBSやガントチャートのテンプレート機能を備えた製品も多く、計画から進捗管理までを一貫して扱えるようになっています。
(Asana)

よくある質問

Q1．WBSとガントチャートはどちらから作るべきですか。
A．多くの場合、先にWBSで作業構造とスコープを整理し、その結果をもとにガントチャートでスケジュールを組み立てる流れが分かりやすくなります。

Q2．WBSの粒度はどこまで細かくするべきですか。
A．目安としては、1〜3日程度で完了する作業単位であり、担当者と完了条件を明確にできるレベルが現実的です。
ただし、プロジェクトの重要度やリスクに応じて調整することが前提になります。

Q3．途中で要件が変わった場合、WBSはどこまで修正すべきですか。
A．影響範囲に応じて、関連するフェーズとタスクが正しく反映されるところまでは見直したほうが安全です。
軽微な変更であればタスクの追加や修正だけで済む場合もありますが、ゴールや成果物が変わる場合は上位レベルから見直す必要があります。

Q4．小規模なプロジェクトでもWBSは必要ですか。
A．タスク数が少ない場合でも、簡易なWBSを作ることで作業の抜け漏れ防止やメンバー間の認識合わせに役立つことが多くあります。
ただし、工数とのバランスを見て、必要な部分だけを簡略化して作るという判断も現実的です。

WBSの作り方と例についてのまとめ

・WBSは成果物と作業を階層構造で整理するための地図
・プロジェクトのスコープと抜け漏れを見える化する役割を持つ
・上位レベルからフェーズや成果物単位で分解していく
・最下層は担当者と完了条件を紐付けられる粒度が目安
・システム開発やWeb制作など反復されるプロジェクトで特に効果が大きい
・まずゴールと成果物を一文で説明できる状態にしてから作成を始める
・作業の細かさは作業時間と完了条件を基準に判断する
・タスクの抜け漏れや重複は複数人レビューで洗い出す
・WBSは一度作ったら終わりではなく変更に合わせて更新する
・システム開発では要件定義からテストまでフェーズごとに分解する
・Web制作では企画から公開までの流れを標準パターン化しやすい
・テンプレートと標準WBSを持つことで毎回ゼロから作る手間を減らせる
・プロジェクト管理ツールのテンプレ機能を組み合わせると運用負荷を抑えられる
・WBSとガントチャートはWBSを先に作ると計画が組み立てやすい
・自分の現場に合う粒度とパターンを少しずつ育てていくことが重要