WBS とは何か。初めて聞いた人のための入門
プロジェクト管理の話をすると、必ずといっていいほど出てくる言葉が「WBS」です。
私が初めてこの言葉を聞いたのは、受託開発の現場でした。「WBSを切ってください」と言われたとき、正直なところ何を求められているのかよくわかりませんでした。タスクリストを渡せばいいのか、スケジュール表のことなのか。
試しに「タスクをExcelで一覧にして渡す」という対応をしたところ、「もう少し構造化してほしい」と言われました。そのとき、WBSとは単なるタスクリストとは異なるという認識を初めて持ちました。
この記事では、WBS を初めて聞いた方でもわかるように、定義から実務での使い方まで整理しました。
WBS とは何か
WBS は「Work Breakdown Structure」の略で、日本語にすると「作業分解構造」です。
一言でいうと、プロジェクトの作業全体を階層構造に分解して整理する考え方です。
なぜ分解するのかというと、プロジェクトを大きな塊のまま管理しようとすると「全体でどのくらい進んでいるか」「どの部分が遅れているのか」が見えないからです。100時間のプロジェクトが60時間経過したとき、「あと40時間で終わるか」を判断するには、内部の状態が見えていなければなりません。
WBS は、その「内部の状態」を見えるようにするための設計思想です。
なぜ見積もりが外れるのか
私がフリーランスとして仕事を始めた頃、見積もりが毎回大きく外れていました。
「Webサイト制作：80時間」という見積もりを出して、実際には160時間かかる、ということが何度もありました。当時は「自分の感覚が悪い」と思っていたのですが、原因はそこではありませんでした。
作業の粒度が大きすぎたことが問題でした。
「Webサイト制作：80時間」という見積もりは、内訳がありません。ヒアリングに何時間、ワイヤーフレームに何時間、実装に何時間、テストに何時間かかるのかが分解されていないと、終わってみるまで何が起きているかわかりません。
WBS で作業を細かく分解してから見積もると、「このフェーズは過去の案件でだいたい20時間かかっていた」という比較ができるようになります。根拠のある見積もりができるようになるのは、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サイトを受託した場合のWBS例です。
📁 コーポレートサイト制作
▾ 要件定義
▾ ヒアリング
□ ヒアリングシートの作成（2h）
□ クライアントとのヒアリング実施（3h）
□ 議事録・要件まとめ（1h）
▾ 設計
▾ ワイヤーフレーム
□ トップページWF作成（4h）
□ サービスページWF作成（3h）
□ 会社概要・その他ページWF（2h）
□ クライアントレビュー対応（2h）
▾ デザインカンプ
□ トップページデザイン（8h）
□ 共通パーツ（ヘッダー・フッター）（4h）
□ クライアントレビュー対応（3h）
▾ 実装
▾ HTMLテンプレート
□ 共通ヘッダー・フッター実装（3h）
□ トップページ実装（4h）
□ サービスページ実装（3h）
▾ テスト・納品
▾ 動作確認
□ クロスブラウザ確認（2h）
□ クライアントレビュー対応（3h）
このように整理すると、「設計フェーズで予算の何%を消化したか」「どの成果物の見積もりが甘かったか」が、数値として取り出せるようになります。
また、このWBSで注目してほしいのは「クライアントレビュー対応」がタスクとして明示されていることです。これは見積もり時に抜けやすい作業の代表格です。WBSで分解することで、「レビュー対応の工数を含めていなかった」という見落としを事前に防げます。
WBSを作るときの注意点
実際にWBSを作り始めると、いくつかつまずきやすいポイントがあります。
フェーズと成果物を混同してしまう：「設計」はフェーズですが、「ワイヤーフレーム」は成果物です。時間の流れを表すものがフェーズ、フェーズの中で生み出すものが成果物、という区別を意識すると整理しやすくなります。
コミュニケーション工数を忘れる：打ち合わせ・メール対応・仕様確認はタスクとして入れましょう。これが漏れると見積もりが実態より少なくなります。
最初から完璧を目指しすぎる：最初のWBSは荒くて構いません。プロジェクトが進むにつれて細かく更新していく使い方で問題ありません。WBSは「一度作って完成」ではなく、実態に合わせて更新するものです。
まとめ
- WBS はプロジェクトの作業を階層構造に分解する考え方
- 見積もり精度を上げるために、分解は不可欠
- 4階層（プロジェクト→フェーズ→成果物→タスク）が実務での標準的な構造
- タスクは「4時間以内」を目安に分解する
- コミュニケーション工数・レビュー対応も忘れずにタスク化する
見積もりが外れ続けている場合、多くはタスクの粒度が大きすぎることが原因です。WBSで構造化することで、どの工程が膨らんでいるかを数値で把握できるようになり、次の見積もり精度が改善されます。最初は荒くても構いません。まず「フェーズに分ける」だけでも、見積もりの根拠の作り方が変わります。
本記事で取り上げた「WBS による作業分解と工数把握」は、LayerClock でも対応しています。 4階層WBS構造でプロジェクトを分解し、タイマー計測で実績を積み上げることで、見積もり精度を高める仕組みを無料から試すことができます。