WBS（タスク分解）の基本 — プロジェクトを成功させる5つのコツ

プロジェクトが途中で行き詰まる原因の多くは、「最初のタスク分解が甘かった」ことに集約されます。逆に言えば、最初にWBSを丁寧に作っておけば、その後のスケジュール管理・担当割り当て・進捗確認のすべてがスムーズに進みます。本記事では、WBSの基本概念から実務での作り方、現場でよくある落とし穴までを順に解説します。

WBSとは — プロジェクトを「やるべきこと」に分解する設計図

WBSは「Work Breakdown Structure」の略で、日本語では「作業分解構成図」と訳されます。プロジェクト全体のゴールを、最終成果物 → 中項目 → 小項目 → 具体的なタスクという階層構造に分解した一覧表のことです。

ガントチャートが「いつ何をやるか」を時間軸で表現する図だとすれば、WBSは「そもそも何をやるべきか」を構造で表現する図です。順序としては、WBSを先に作ってからガントチャートに落とし込むのが基本の流れになります。

WBSを作る4ステップ

ステップ1：最終成果物を1行で定義する

「Webサイトを公開する」「新店舗をオープンする」「展示会に出展する」など、プロジェクトのゴールを1行で書き出します。ここで曖昧だと、後の分解もすべてズレるため、関係者全員の合意が取れる表現に磨きましょう。

ステップ2：大項目（フェーズ）に分ける

最終成果物を、3〜7程度の大きな塊に分解します。Webサイト制作なら「企画」「設計」「制作」「テスト」「公開」のようなフェーズです。ここはタイミング順でも、種類別でも構いません。

ステップ3：中項目に分ける

各フェーズの中で、ひとまとまりの作業単位に分解します。「設計」フェーズなら「サイトマップ作成」「ワイヤーフレーム作成」「デザインカンプ作成」といった具合です。

ステップ4：実行可能なタスクに分解する

中項目をさらに「担当者が1人で着手できる粒度」まで分解します。「ワイヤーフレーム作成」なら「トップページ」「商品一覧」「商品詳細」「お問い合わせ」のようにページ単位まで落とします。

粒度の決め方 — 「1人・1〜3日」が目安

WBSの粒度に正解はありませんが、実務では次の目安が使いやすいでしょう。

「1人の担当者が1〜3日で完了させられるサイズ」を基準にすると、進捗確認のしやすさと管理コストのバランスが取れます。

プロジェクトを成功させる5つのコツ

コツ1：成果物ベースで分解する

「作業」ではなく「成果物」を基準に分解します。「打ち合わせをする」ではなく「議事録を作成する」、「検討する」ではなく「企画書を作成する」のように、終わったときに何が手元に残るかで定義すると、完了判定がぶれません。

コツ2：MECEを意識する

MECE（モレなく、ダブりなく）はWBSの基本原則です。同じレベルのタスクを並べたときに「漏れているものはないか」「同じ内容が別の名前で2つ書かれていないか」を必ずチェックします。

コツ3：100%ルールを守る

各階層において、子要素をすべて合計すると親要素の100%になる、というのが100%ルールです。たとえば「設計」フェーズの中項目を全部足したときに、設計フェーズで必要なことがすべて含まれている状態を目指します。

コツ4：担当者と工数を必ず記載する

タスク名だけのWBSは、見た目は整っていても運用が回りません。各タスクに「誰がやるか」と「何日かかるか」をセットで記入してはじめて、ガントチャートへの展開が可能になります。

コツ5：プロジェクト開始後も更新し続ける

WBSは一度作ったら終わりではありません。途中で「想定外のタスクが発生した」「不要なタスクが見つかった」ことに気づいたら、その都度更新していきます。固定された設計図ではなく、生きた地図として扱う姿勢が大切です。

WBSとガントチャートの連携

WBSで「何をやるか」を整理したら、次はガントチャートに落とし込んで「いつやるか」を決めます。多くのWebガントチャートツールでは、WBSの階層構造をそのまま親子タスクとして表現できるため、再入力の手間なく移行できます。

よくある失敗パターン

• 粒度が細かすぎる：30分単位のタスクまで書いてしまい、メンテナンスが追いつかない
• 粒度が粗すぎる：「企画する」のように1行で済ませてしまい、進捗が見えない
• 個人の頭の中だけにある：WBSを共有せず、本人以外に進捗が分からない
• 初版のまま運用：プロジェクト開始後の変更を反映しない