WBSの作り方：ディレクターが最初に決める「分解の単位」

WBS（Work Breakdown Structure）は、作業を細かく書き出すための表だと思われがちですが、私は「分解の単位を決める道具」だと考えています。単位が決まっていないWBSは、行が増えるほど信用できなくなります。逆に、単位が決まっていれば、行が少なくても見積もりと進行管理に耐えます。

Web制作会社、事業会社のWeb担当、大手ITのテクニカルディレクター、そして独立後の一人体制。立場が変わってもWBSの作り方だけは変えずに済んだので、その手順を書きます。

最初に決めるのは「終わりが判定できる大きさ」

WBSの1行は、誰が見ても「終わった／終わっていない」を判定できる大きさにします。私はこれを「判定できる単位」と呼んでいます。

たとえば「デザイン」は判定できません。トップページのデザインなのか、全ページなのか、修正込みなのかが分からないからです。一方で「トップページのデザインカンプを提出し、クライアントの確認を1回受ける」は判定できます。

ここで大事なのは、細かさではなく判定のしやすさです。細かく刻んだ結果として判定しやすくなることはありますが、細かく刻むこと自体が目的になると、WBSは「管理のための管理」になります。

私の目安は次の3つです。

• 1行の作業は、1人で2〜5営業日に収まる
• 成果物の名前が書ける（「〜のカンプ」「〜の仕様書」「〜の実装」）
• 完了の条件が1文で書ける（「確認を1回受ける」「ステージングで表示確認」）

2日未満の作業はまとめ、5日を超える作業は割ります。この幅にすると、週次のレビューで遅れが必ず見えます。

分解の軸は「成果物」で揃える

分解の軸がばらばらだと、同じWBSの中に「工程」の行と「成果物」の行と「担当者」の行が混ざります。私は成果物を軸に揃えています。

工程で分ける（企画→設計→デザイン→実装→検証）のは分かりやすい反面、実際の制作は工程を往復します。デザインの途中で設計に戻ることは日常です。工程軸のWBSでは、この往復が「遅れ」として記録されてしまいます。

成果物で分けると、往復は「同じ成果物の中での作業」になり、WBSの構造を壊しません。

軸	行の例	往復が起きたとき
工程	設計 / デザイン / 実装	設計に戻ると「設計の遅れ」に見える
成果物	トップページ / 会社概要 / 問い合わせフォーム	同じ行の中で完結する

成果物軸で一段目を切り、二段目で「カンプ／実装／検証」のように分けると、工程の情報も失いません。

「やらないこと」を最初の行に書く

WBSの先頭に、このプロジェクトでやらないことを1〜3行書いておきます。「多言語対応はしない」「既存コンテンツの移行は対象外」「写真撮影はクライアント手配」といった内容です。

これは進行管理のためというより、見積もりの前提を固定するためです。やらないことが書かれていないWBSは、後から「これも含まれていると思っていた」という話が必ず出ます。私はこの1〜3行を、要件定義書ではなくWBSの側にも書くようにしています。見積もりを見る人はWBSを見るからです。

単位が決まると、ガントチャートは「後から」引ける

WBSとガントチャートを同時に作ろうとすると、日程に引きずられて分解の単位が歪みます。「この週に収めたいから、この作業を1行にまとめておこう」という判断が入り込みます。

順番は、WBSで単位を決める → 依存関係を書く → ガントに置くです。単位と依存が決まっていれば、ガントは機械的に引けます。逆に、ガントから作ると、WBSは日程の言い訳になります。

依存関係の書き方は別の記事で扱いますが、WBSの段階では「この行は、どの行が終わらないと始められないか」を1行ごとにメモしておく程度で十分です。

明日から試せる一手

いま手元にあるWBSの各行に、「完了の条件」を1文で書けるかを確認してみてください。書けない行は、単位が決まっていない行です。その行を「2〜5営業日で、成果物の名前が付く大きさ」に割るか、まとめるかを決めるだけで、WBSの信用度は変わります。

行数を増やすことではなく、1行ずつ判定できる状態にすること。WBSの作り方は、それに尽きると思っています。