WBS とは何か。初めて聞いた人のための入門
「このフェーズのタスク、いったん洗い出してみて」——駆け出しの頃、WBS のあるフェーズを指してそう頼まれたことがあります。WBS という言葉自体は知っていましたし、思いつくタスクを並べること自体はできました。ただ、あとから見返すと粒度はバラバラで、半日がかりの作業と数分で終わる作業が同じ列に並んでいる。「分解する」という発想が、まだ身についていなかったのだと思います。
もっと尾を引いたのは、その先でした。最初にこしらえた WBS が、案件が始まって 2〜3 週間もすると更新されなくなり、ただ置いてあるだけのファイルになっていく。このあと立場は何度か変わりましたが、「最初に作った WBS が形骸化する」現象だけは、どこへ行ってもついてきました。
この記事では、WBS を初めて聞いた方でもわかるように、定義から実務での使い方まで整理しました。
WBS とは何か
WBS は「Work Breakdown Structure」の略で、日本語にすると「作業分解構造」です。
一言でいうと、プロジェクトの作業全体を階層構造に分解して整理する考え方です。
なぜ分解するのかというと、プロジェクトを大きな塊のまま管理しようとすると「全体でどのくらい進んでいるか」「どの部分が遅れているのか」が見えないからです。100時間のプロジェクトが60時間経過したとき、「あと40時間で終わるか」を判断するには、内部の状態が見えていなければなりません。
WBS は、その「内部の状態」を見えるようにするための設計思想です。
なぜ見積もりが外れるのか
私が見積もりを出し始めた頃、その数字はよく外れていました。
たとえばツール開発で「〇〇機能の実装：40時間」とひとくくりに見積もって、フタを開けたら倍近くかかっている、ということが何度もありました。当時は「自分の感覚が悪いんだろう」と思っていたのですが、原因はそこではなかったようです。これは個人で受けていた頃の話ですが、のちに組織の中で他人の見積もりを束ねる側に回っても、ズレ方の構造は驚くほど同じでした。
ひとつの「機能」を、それ以上分けずに見積もっていたことが問題でした。 言いかえると、「分解する」という発想が抜けていたのです。
「〇〇機能：40時間」という見積もりには、内訳がありません。画面の実装に何時間、API に何時間、テストや手戻りに何時間——そこが分かれていないと、どこで膨らんだのかは終わってみるまで見えませんし、次に活かすこともできません。
WBS で作業を分解してから見積もると、「この種の機能は前回だいたい〇時間だった」という比較ができるようになります。根拠のある見積もりは、分解する習慣を持ってから初めてできるようになりました。
WBS の4階層
実務では、次の4つの階層で作業を整理するのが一般的です。
1. プロジェクト層
最上位の層です。案件・受注単位で分けます。
例：「〇〇社コーポレートサイト制作」「在庫管理システム開発」
2. フェーズ層
プロジェクトの時系列的な段階です。プロジェクトを「いつ何をやるか」という流れで分けます。
例：「要件定義」「設計」「実装」「テスト」「納品・サポート」
フェーズに分けることで、「設計フェーズの予算をどのくらい消化したか」という把握ができるようになります。フェーズをまたいで工数を合算していると、どの段階で時間を使いすぎているかが見えないままになります。
3. 成果物層
各フェーズで生み出す具体的な成果物・納品物です。フェーズという大きな括りの中で「何を作るか」を分けます。
例（設計フェーズの場合）：「ワイヤーフレーム」「デザインカンプ」「API設計書」
成果物という単位で考えると、見積もり時の見落としが見つかりやすくなります。「ワイヤーフレームとデザインカンプは考えていたが、API設計書を作る工数を見積もりに入れていなかった」という気づきは、成果物レベルで整理することで起きます。
4. タスク層
実際に手を動かす最小単位の作業です。時間を計測する対象になる粒度です。
例（ワイヤーフレームの場合）：「トップページWF作成」「サービスページWF作成」「クライアントレビュー対応」
この4階層で整理すると、「設計フェーズ全体で何時間かかったか」「ワイヤーフレームだけで何時間かかったか」がそれぞれ集計できるようになります。2階層（プロジェクト→タスク）で管理していると、この集計ができません。
タスクはどこまで細かく分解すればいいか
よく聞かれる疑問が「どこまで細かく分けるべきか」です。
私の目安は 「1タスク = 4時間以内に完了できる粒度」 です。
半日（4時間）以内に終わる作業なら、開始と終了を同日中に記録でき、進捗の把握もしやすくなります。「サイト全体のHTML実装」という大きなタスクは、いつ終わるか見えづらいですが、「トップページのヘッダー実装」であれば開始・完了が明確です。
一方、細かすぎると管理コストが増えます。「変数名を決める（15分）」「コメントを書く（10分）」のような粒度まで分解してしまうと、タスクを作ること自体が負担になります。
「4時間以内」を基準に、直感的に分けられる粒度で止めるのがちょうどよいと感じています。
具体例：Webサイト制作プロジェクトのWBS
5ページほどのWebサイト制作を1件請けたとき、という想定でのWBS例です（規模感がイメージしやすいので受託の例にしていますが、社内案件でも構造は変わりません）。
📁 コーポレートサイト制作
▾ 要件定義
▾ ヒアリング
□ ヒアリングシートの作成（2h）
□ クライアントとのヒアリング実施（3h）
□ 議事録・要件まとめ（1h）
▾ 設計
▾ ワイヤーフレーム
□ トップページWF作成（4h）
□ サービスページWF作成（3h）
□ 会社概要・その他ページWF（2h）
□ クライアントレビュー対応（2h）
▾ デザインカンプ
□ トップページデザイン（8h）
□ 共通パーツ（ヘッダー・フッター）（4h）
□ クライアントレビュー対応（3h）
▾ 実装
▾ HTMLテンプレート
□ 共通ヘッダー・フッター実装（3h）
□ トップページ実装（4h）
□ サービスページ実装（3h）
▾ テスト・納品
▾ 動作確認
□ クロスブラウザ確認（2h）
□ クライアントレビュー対応（3h）
このように整理すると、「設計フェーズで予算の何%を消化したか」「どの成果物の見積もりが甘かったか」が、数値として取り出せるようになります。
また、このWBSで注目してほしいのは「クライアントレビュー対応」がタスクとして明示されていることです。これは見積もり時に抜けやすい作業の代表格です。WBSで分解することで、「レビュー対応の工数を含めていなかった」という見落としを事前に防げます。
WBSを作るときの注意点
実際にWBSを作り始めると、いくつかつまずきやすいポイントがあります。
フェーズと成果物を混同してしまう：「設計」はフェーズですが、「ワイヤーフレーム」は成果物です。時間の流れを表すものがフェーズ、フェーズの中で生み出すものが成果物、という区別を意識すると整理しやすくなります。
コミュニケーション工数を見落とす：打ち合わせ・確認・レビュー対応のように、手を動かす作業の合間に挟まる時間です。メール1通は数分でも、案件全体で積み上がると無視できない量になります。1件ずつ細かくタスク化するより、「コミュニケーション」「調整」のような枠をあらかじめ一つ置いておくと、見積もりが実態から大きくズレずに済みます。
最初から完璧に分解しようとする：最初のWBSは荒くて構いません。いきなり全フェーズを4時間タスクまで割る必要はなく、まずはフェーズと、せいぜい主要な成果物くらいのざっくりした単位で置いておけば十分です。着手が近づいたフェーズだけ、そのつどタスクへ細かく分けていく。WBSは「一度作って完成」ではなく、進みながら実態に合わせて更新していくものです。
結局、WBSの肝はどこか
ここまで定義から4階層、分解の粒度まで見てきましたが、一番大事なのは「WBSは作業を階層に分解して、見積もりの根拠をそこに持たせる考え方だ」という一点です。プロジェクト→フェーズ→成果物→タスクの4階層が実務の標準で、実際に手を動かすタスクは4時間以内を目安にする。コミュニケーションのような抜けやすい時間も、枠をひとつ置いて拾っておく——細かい作法は、だいたいここから導けます。
見積もりが外れるとき、その多くは「分解する」という発想が抜けて、ひとくくりのまま数字を置いていることが原因です。だからといって、最初から全部を細かく割る必要はありません。まずはフェーズに分けるだけでも、見積もりの根拠の作り方は変わってきます。あとは進みながら、着手が近い部分から細かくしていけばいい。ただ正直に言えば、一番難しいのは分解そのものより、作ったWBSを途中で捨てずに更新し続けることのほうです。冒頭に書いた「最初のWBSが2〜3週間で形骸化する」のは、私が今でも油断すると陥るところで、ここは完全には解けていません。
関連記事
本記事で取り上げた「WBS による作業分解と工数把握」は、LayerClock でも対応しています。 4階層WBS構造でプロジェクトを分解し、タイマー計測で実績を積み上げることで、見積もり精度を高める仕組みを無料から試すことができます。