目次
はじめに
「WBSってどうやって作ればいいの？」「タスクを書き出してと言われても、どこから手をつければいいのか分からない…」そんなふうに感じたことはありませんか。
WBSの作り方に迷っていると、やるべき作業だけが頭の中でどんどん膨らんでしまいます。資料作成、打ち合わせ、設計、テスト…とやることは思い浮かぶのに、いざ紙や画面に書き出そうとすると手が止まってしまう。何から書けばいいのか分からず、ノートだけが白いまま残ってしまうこともありますよね。
会議で「まずはタスクを出しましょう」と言われても、「どこまで細かく書けばいいの？」と迷ってしまい、ざっくりした項目だけを書いてそのままにしてしまうこともあります。逆に、思いつくままに細かく書きすぎてしまい、一覧が長くなりすぎて、全体の流れが見えなくなることもあるでしょう。その結果、作業の重なりや抜け漏れに後から気づいて、慌てて修正する…という経験をした方もいるかもしれません。
この記事では、そうした迷いをひとつずつほどきながら、「まずはここから書いてみましょう」「次はここを確認してみましょう」と、順番に取り組める5つの流れをご紹介します。具体例も交えながら説明していきますので、読みながら実際に手を動かしていただけます。
読み終えるころには、「とりあえず書いてみよう」と自然に動き出せるはずです。そして、WBSを誰かに作ってもらうのではなく、ご自身の手で組み立てられる状態を目指していきましょう。
WBSとは？
WBSとは、プロジェクトを感覚や経験だけで進めるのではなく、「何を・どこまで・どの順番でやるのか」を見える形にするための基本的な管理手法です。作業の抜け漏れや範囲のあいまいさを防ぎ、関係者全員が同じ全体像を共有できる状態をつくるために使われます。では具体的に、WBSはどのような構造を持ち、何を整理するためのものなのでしょうか。
WBSは作業を階層的に分解して整理した計画図
WBS（Work Breakdown Structure）は、プロジェクトで発生する作業を「企画」「設計」「制作」「テスト」などの大きな単位から順番に分け、その中身をさらに「画面設計書の作成」「トップページのコーディング」「動作確認」などの具体的な作業まで細かく書き出した一覧表です。大きな作業の下に小さな作業をぶら下げる形で並べ、最終的に担当者名・開始日・終了日・必要時間を入れられる単位まで分解します。これにより、「誰が・何を・いつまでに行うか」を一覧で確認でき、作業計画の基準になります。
プロジェクト全体の作業範囲（スコープ）を明確にするための手法
WBSを作る目的は、プロジェクトで実行する作業をすべて書き出し、「何をやるか」「何をやらないか」を文書で決めることです。作業を一覧にすると、「テスト工程が抜けている」「同じ資料を2人が作ろうとしている」といった漏れや重複にその場で気づけます。また、「今回はスマホ画面まで対応するが、アプリ開発は含めない」など、実施範囲と対象外の線引きも明確になります。途中で「追加でこの機能も入れてほしい」と依頼が出た場合も、最初のWBSと照らし合わせて、当初計画に含まれているかどうかを判断できます。スコープを管理する基準表として使う点が重要です。
成果物を起点に必要な作業を洗い出すための構造
WBSは「作業内容」から書き始めるのではなく、「最終的に納品するもの」から逆算して作ります。まず「ECサイト公開」「業務システム本番リリース」など完成物を最上位に置き、その完成に必要な工程を下に並べます。たとえば「業務システム本番リリース」を置いた場合、その下に「基本設計書作成」「プログラム実装」「単体テスト実施」などを展開し、さらに「ログイン画面設計」「商品登録機能コーディング」のように具体的な作業まで分解します。この手順で作ると、完成物に直接関係しない作業を除外でき、納品に必要な作業だけを計画に残せます。
WBSを作る前に決めておくこと（事前準備）
WBSは、いきなり作業を分解し始めるとうまく機能しません。ゴールがあいまいなまま細かいタスクを書き出しても、後から抜けや重複が発生しやすくなるからです。まずは「何を完成とするのか」「どこまでが今回の対象なのか」「どの粒度で分解するのか」という前提をそろえる必要があります。ここを決めてから分解を始めることで、WBSは初めて正しく機能します。
最終的に完成させる成果物（ゴール）をはっきりさせる
WBSは、最終的に何を完成とするかが決まっていないと作れません。最初に「3月31日までにECサイトを公開する」「テスト済みの業務システムを本番環境で稼働させる」など、納品物と完了条件を文章で決めます。成果物を決めないまま分解を始めると、「やはりスマホ対応も必要だった」「マニュアル作成が抜けていた」と途中で作業が増えたり減ったりして計画が崩れます。最初にゴールと完了基準を具体的に決めておくことで、必要な作業だけを順番に書き出せます。
このプロジェクトで「どこまでやるか（スコープ）」を決める
次に、決めたゴールに対して「今回のプロジェクトで実施する範囲」を文章で確定します。たとえば「ECサイトのデザインと構築までは対応するが、商品撮影と広告運用は含めない」のように、責任を持つ作業と対象外の作業を具体的に分けます。範囲を決めないまま進めると、「ついでにこの機能も追加してほしい」と依頼が増え、作業時間や納期が簡単に延びます。関係者全員で実施範囲を確認してからWBSを作ることで、実際に行う作業だけを一覧にできます。
作業をどの細かさまで分けるかの基準を決める
WBSでは、作業をどの単位まで分けるかで管理のしやすさが変わります。1時間単位まで細かく分けると項目数が増えすぎて更新が大変になり、「設計」「開発」だけのように大きすぎると進み具合が分かりません。そのため、「1人に割り当てられる単位」「開始日と終了日を入れられる単位」「作業時間を見積もれる単位」まで分ける、といった基準を先に決めます。基準を決めておけば、途中で細かさがばらつかず、同じ大きさの作業単位でWBSを作れます。
WBSの作り方｜迷わず作成できる5つのステップ
WBSは考え方を理解するだけでは不十分で、実際に「どの順番で分解していくか」を決めておかないと手が止まります。自己流で進めると、ゴールがぶれたり、分解の粒度が揃わなかったりして、使えないWBSになりがちです。そこでここでは、初めてでも迷わず作成できる具体的な5つの手順に沿って、上から順番に分解していく流れを整理します。
ステップ① 最終成果物をWBSの最上位に置く（ゴールを固定する）
最初に、プロジェクトで完成させる成果物をWBSの一番上に書きます。たとえば「自社サイト公開」「社内業務システム本番稼働」など、納品物や完了状態を具体的な言葉で置きます。以降の作業分解はすべてこの成果物を基準に下へ広げます。ゴールを書かずに作業から並べ始めると、「本来不要な資料作成」や「目的と関係の薄い改善作業」が混ざります。最上位に成果物を固定することで、各作業が何の完成に向かっているかを常に確認できます。
ステップ② 成果物を作るための主要作業（フェーズ）に分ける
次に、その成果物を完成させるまでの流れを大きな工程ごとに分けます。たとえば「自社サイト公開」であれば、「要件定義」「デザイン作成」「コーディング」「動作テスト」「公開作業」といった単位に区切ります。この段階では「トップページ画像作成」などの細かい作業までは書かず、全体の流れが一目で分かる大きさで整理します。ここで、完成までの工程を横並びで確認できる骨組みを作ります。
ステップ③ 主要作業をタスクまで分解して「実行できる形」にする
各工程の中にある作業を、実際に担当者が着手できる単位まで細かく分けます。たとえば「設計」という大きな項目のままにせず、「ログイン画面の設計書作成」「商品登録画面の設計書作成」「設計書レビュー修正対応」など、具体的な行動名に分解します。1人に割り当てられ、開始日と終了日を設定でき、作業時間を見積もれる大きさが目安です。ここまで落とし込むことで、担当割り当てや進捗確認に使える計画になります。
ステップ④ 抜け漏れ・重複・粒度のばらつきをその場で整える
分解が終わったら、一覧を上から下まで確認します。「テスト実施」が2回書かれていないか、「マニュアル作成」が抜けていないかなどを一つずつ見ます。同じ内容のタスクがあれば統合し、必要な作業が足りなければ追加します。また、「サイト全体修正」のように大きすぎる項目と、「ボタン色変更」のように小さすぎる項目が混ざっている場合は、大きさをそろえます。この見直しを行うことで、担当割り当てや進捗管理に使いやすいWBSになります。
ステップ⑤ 各タスクの担当者と完了条件（Done）を決めて締める
最後に、各タスクごとに担当者名を入れ、「どの状態になれば完了か」を具体的に書きます。担当者が空欄のままだと誰も着手せず、完了基準がないと終わったか判断できません。たとえば「設計書を共有フォルダに保存し、責任者の承認コメントが付いたら完了」「テスト項目をすべて実施し、不具合ゼロを確認したら完了」など、確認できる条件を設定します。ここまで決めて初めて、進捗確認と責任管理に使える計画になります。
WBSの作り方の具体的な例
ここまで手順を理解しても、実際のイメージが湧かなければ手は動きません。WBSは抽象的に考えるよりも、具体的な題材に当てはめて見ることで構造が一気に理解できます。そこでここでは、実務に近いWebサイト制作プロジェクトと、身近なカレー作りという2つの例を使って、どのように分解していくのかを具体的に確認します。
例① Webサイト制作プロジェクトでのWBS作成例
たとえば企業のWebサイト制作では、最上位に「コーポレートサイト公開（本番サーバーで表示確認完了）」と書きます。その下に「要件定義」「ワイヤーフレーム作成」「デザイン制作」「HTML/CSSコーディング」「動作テスト」「公開作業」と並べます。さらに「デザイン制作」の中を「トップページデザイン作成」「会社概要ページデザイン作成」「デザイン修正対応」に分けます。このように完成物から工程、工程から具体的な作業名へ順番に落とすことで、担当者の割り当てと作業の実行順が一覧で確認できます。
例② カレー作りを題材にしたWBS分解の例
WBSは日常の作業にも使えます。たとえばカレー作りでは、最上位に「カレーを皿に盛って食卓に出す」と書きます。その下に「材料購入」「下ごしらえ」「煮込み」「盛り付け」を並べます。さらに「材料購入」は「スーパーで玉ねぎ・にんじん・じゃがいも・肉を買う」「カレールーの在庫を確認する」に、「下ごしらえ」は「野菜の皮をむく」「一口大に切る」「肉を切る」に分けます。このように完成状態から順番に作業を書き出すと、買い忘れや切り忘れ、工程の抜けを防げます。
WBS作成でよくある失敗
WBSは形式だけ整えても、分解の仕方を間違えると実務では使えません。見た目はそれらしくても、「実行できない」「管理できない」WBSになってしまうケースは少なくありません。ここでは、実際の現場で起きやすい典型的な失敗パターンを押さえながら、どこでつまずきやすいのかを具体的に整理します。
作業内容ではなく工程名（フェーズ名）だけを書いてしまう
WBSに「設計」「開発」「テスト」だけを書くと、担当者が何をすればよいか分かりません。これらは工程の区分であり、実際の作業名ではありません。そのままでは担当者を決められず、作業日数も見積もれません。「基本設計書を作成する」「商品登録機能を実装する」「単体テストを実施する」のように、実際に行う行動名まで分けて書く必要があります。
タスクの細かさ（粒度）がそろっていない
あるタスクは「システム開発」のように大きすぎ、別のタスクは「ログイン画面の文言を1か所修正」のように小さすぎる状態になると、進捗を比較できません。同じ階層に並ぶ項目は、大きさをそろえる必要があります。1人に割り当てられ、開始日と終了日を入れられ、作業時間を見積もれる単位に統一します。大きすぎる項目は分割し、小さすぎる項目はまとめることで、一覧で進み具合を確認できます。
成果物の作成に直接関係しない作業を入れてしまう
WBSには、完成物を作るために必要な作業だけを書きます。成果物と関係のない業務まで入れると、一覧が膨らみ管理しにくくなります。たとえば「毎週の定例会議」「部署全体の朝礼準備」など、今回の納品物に直接関係しない活動をすべて入れると、実作業が見えにくくなります。各項目が完成物に直結しているかを基準に選び、関係のない業務は別の管理表で扱います。
WBSをスケジュール・ガントチャートに落とし込む方法
WBSはあくまで「作業の構造図」であり、そのままでは日程管理はできません。実行フェーズに進むためには、分解したタスクを時間軸に並べ替え、いつ・誰が・どのくらいの期間で行うのかを明確にする必要があります。ここでは、作成したWBSをスケジュールやガントチャートへ具体的に落とし込む流れを整理します。
WBSのタスクを時系列に並べて工程表（ガントチャート）に変換する
WBSは作業名の一覧なので、そのままでは実施日が分かりません。各タスクを実行順に並べ替え、「4月1日開始・4月5日終了」のように開始日と終了日を入れて工程表にします。「設計書が完成しないと実装できない」といった前後関係や、「デザインとサーバー準備は同時に進められる」といった並行作業を整理します。こうしてWBSの各タスクを時間軸に並べると、ガントチャートとして使える日程表になります。
各タスクの担当者と工数を設定して日程に反映する
次に、各タスクに担当者名を入れ、必要な作業時間を「8時間」「16時間」のように見積もります。作業時間が分かれば、その担当者が1日何時間使えるかを基準に、完了までの日数を計算できます。同じ人が複数タスクを持つ場合は、期間が重ならないよう開始日をずらします。担当者と作業時間を日程表に反映させることで、実際に回せるスケジュールになります。
WBSを実務で運用するときの注意点
WBSは一度作って終わりではなく、実務の進行に合わせて使い続けてこそ意味があります。作成時点では正しく見えていても、仕様変更や想定外の作業が発生すれば、放置したWBSはすぐに現場とずれていきます。ここでは、WBSを形だけの資料にしないために、日々の運用で意識すべきポイントを整理します。
仕様変更や追加作業が出たらWBSも必ず更新する
プロジェクトでは途中で「この機能も追加したい」「仕様を変更したい」といった依頼が出ます。そのとき、実作業だけ増やしてWBSを直さないと、一覧と実態がずれます。追加した作業はWBSに書き足し、不要になった作業は削除します。変更内容をその都度反映させないと、進捗率や作業時間の合計が実際と合わなくなります。
WBSをスケジュール・担当割り当てと常に連動させる
WBSは一覧だけで管理せず、日程表や担当一覧とセットで更新します。WBSにタスクを追加しても、ガントチャートの開始日や担当者表が古いままだと現場はその通りに動きません。タスクを増やした・内容を変えた・削除した場合は、日程表の期間と担当者名も同時に修正します。関連する表を同じ内容にそろえることで、指示の食い違いを防げます。
定期的に見直して実態とのずれを修正する
計画どおりに進むことは少なく、日が経つと実際の進み具合と差が出ます。週1回など日を決めてWBSを開き、完了したタスクにチェックを入れ、遅れている項目は日程を修正します。追加で必要になった作業があれば書き足します。進んでいない項目を放置せず、その都度一覧を直すことで、今の状況に合った計画を保てます。
まとめ
WBSの基本概念から、作成前に決めるべき準備事項、5つの作成ステップ、よくある失敗、スケジュールへの落とし込み方法、実務での運用ポイントまでを整理しました。
WBSは単なる作業一覧ではありません。
最上位に成果物を置き、そこから工程、さらに実行可能なタスクへと分解することで、「誰が・何を・いつまでに行うか」を明確にするための設計図です。
作成時は以下が重要です。
・ゴールと完了条件を最初に決める
・スコープ（やる範囲）を明確にする
・担当者を割り当てられる単位まで分解する
・抜け・重複・粒度のばらつきを整える
・日程・工数・担当表と必ず連動させる
・変更が出たら必ず更新する
WBSの質は「どこまで具体的に分解できているか」で決まります。
工程名だけで止めず、行動レベルまで落とし込むことが、実行できる計画に変えるポイントです。
分解の基準をそろえ、定期的に更新を続ければ、WBSは現場で使える管理ツールとして機能し続けます。