WBSの粒度をどこまで細かくするか
WBS（作業分解構成図）を作るとき、多くのPMが迷うのは「どこまで細かく分けるか」です。
細かすぎると更新が追いつかず、誰も見ない工程表になります。粗すぎると「設計30人日」のような塊になり、進捗が％でしか言えなくなります。止めどころには、判断基準があります。
■ WBSは「作業の一覧」ではなく「成果物の分解」
よくある誤解は、WBSを「やることリスト」だと考えることです。そうすると、思いついた作業を並べただけの一覧になり、漏れているかどうかが分かりません。
WBSは、プロジェクトの成果物を段階的に分解していくものです。「何を作るか」から出発すると、抜けに気づきやすくなります。
第1階層 プロジェクト全体
第2階層 工程（要件定義／設計／製造／テスト／移行／稼働支援）
第3階層 まとまり（設計であれば、受注入力／在庫引当／出荷指示／帳票）
第4階層 ワークパッケージ（担当1人に割り当てられる単位）
規模によっては3階層で足りますし、大きければ5階層になることもあります。階層の数を先に決めず、止めどころの条件で判断します。
■ 分解を止める3つの条件
次の3つを満たしたら、それ以上細かくしません。
① 担当者を1人に決められる 2人以上で分担することになるなら、まだ分けられます
② 所要日数を見積もれる 目安は5日以内。1か月かかる箱は、中身が見えていない証拠です
③ 終わったかどうかを他人が判定できる 「設計書を作成する」は判定できますが、「設計を進める」は判定できません
③が特に重要です。完了の判定ができない単位は、進捗報告のときに必ず揉めます。「だいたい終わっています」という報告は、ここから生まれます。
■ 分けすぎるとどうなるか
1日未満の作業まで分解すると、項目数が数百になります。すると次のことが起きます。
誰も更新しなくなる。実態と工程表がずれていく
更新のための会議が必要になる。管理のための管理が始まる
全体が見えなくなる。どこが遅れているか分からなくなる
細かい作業手順は、担当者の手元のToDoで管理すればよいものです。WBSに載せる必要はありません。
■ 100％ルール：分解したら、親と子が一致するか確認する
WBSには「100％ルール」という考え方があります。子の要素をすべて足すと、親の要素がちょうど過不足なく表現されるという原則です。
設計工程を「受注入力／在庫引当／出荷指示」の3つに分けたとき、帳票の設計が抜けていれば、子を足しても親になりません。分解のたびに、「これで全部か」と確認します。
逆に、親に含まれないものを子に入れてもいけません。スコープ外のものがWBSに紛れ込むと、そこから作業が発生します。
■ 忘れられやすい作業
成果物から分解していくと、次のような作業が漏れがちです。意識して入れます。
レビューと承認の時間（作るだけでなく、見てもらう時間が要ります）
データ移行（既存データの調査・変換・検証）
教育・マニュアル作成
他システムとの接続テストの調整
本番環境の準備と切替作業
プロジェクト管理そのもの（会議、報告書作成）
とくにレビュー待ちの時間は、計画に入っていないことが多く、遅れの原因になります。
■ 作ったあとの使い方
WBSは、作って終わりではなく次の3つに使います。
見積の土台 ワークパッケージごとに工数を出し、足し上げる
進捗の単位 ワークパッケージ単位で「完了／未完了」を判定する
変更の影響確認 変更依頼が来たとき、どの箱が増えるかで影響を説明できる
3つ目は実務で効きます。「この変更で、この箱とこの箱が増えます」と示せると、感覚ではなく構造で説明できます。
■ まとめ
WBSの粒度は、「担当者が決まる・日数が見積もれる・完了が判定できる」の3つで決めます。階層の深さをそろえる必要はありません。
いま手元の工程表を見て、完了判定ができない項目がないかを確認してみてください。それが見つかったら、そこが遅れの隠れ場所です。