WBS（作業分解構成図） フレームワーク
施策を「成果物」ごとに階層で分解し抜け漏れを防ぐ作業分解構成図。 担当・工数・期日を割り付ける実行計画の土台になる。
施策を「成果物」ごとに階層で割り、1人が数日で終えられる粒度まで分解する。ガント・RACIの前工程。
分解の単位は「作業（動詞）」でなく「成果物（名詞）」に寄せると、完了判定がぶれない。100%ルール＝親の作業量は子の合計と一致する。
用途
戦略方針で決めた施策を「誰が・いつ・何を終わらせれば完了か」まで落とし込むには、作業を実行可能な粒度まで分解する必要があります。 WBS（Work Breakdown Structure）は、プロジェクト全体を最上位に置き、それを成果物や大タスクへ、さらに担当者一人が数日で終えられる小タスクへと階層的に割り砕く道具です。 「頭の中にある漠然としたやること」を可視化し、抜け・重複を防ぎ、この後の工数見積り・スケジュール（ガントチャート）・責任分担（RACI）・予算配分（リソース配分）すべての共通の土台をつくることが目的です。 分解の単位を「作業（動詞）」ではなく「成果物（名詞）」に寄せると、完了判定が曖昧にならず、進捗管理がぶれません。
使い方
- ゴールと完成の定義を最上位に置く：戦略方針・アクションプランで決めた施策名（例：新規商談獲得の仕組み化）を頂点に据え、『何が揃えば完了か』を1文で言語化する。
- 第1階層を大きな成果物・フェーズで分ける：MECE（漏れなく重複なく）を意識し、5〜9個程度の塊に割る。 工程で分ける（設計→制作→運用）か、成果物で分ける（LP・広告・オペ）かを先に決める。
- 末端（ワークパッケージ）まで分解する：担当者1人が数日〜2週間で終えられ、成果物の完了/未完了を白黒で判定できる粒度まで下げる。 分解しすぎ（管理コスト増）と粗すぎ（見積り不能）の中間を狙う。
- 各末端に担当・工数・成果物を割り付ける：この後の工数見積り・期日設定の入力になる。 ここでは順序（依存関係）はまだ決めず、『やることの全量』の洗い出しに集中する。
- 抜け漏れと粒度を検証する：現場担当と読み合わせ、100%ルール（親の作業量＝子の合計で過不足なし）を確認。 確定後、ガントチャートで順序と期日、RACIで責任を重ねる。
適用例
B2B向けSaaS（会計連携ツール、従業員18名、月額サブスク）で『半年で新規契約を月8件→月20件へ』という戦略方針を実行に移す場面。 頂点に「新規獲得の仕組み化（6か月）」を置き、第1階層を(1)ターゲット再定義(2)ウェビナー集客(3)インサイドセールス立ち上げ(4)導入事例コンテンツ、の4成果物に分解。 (3)をさらに末端まで割ると「架電リスト整備（対象2,000社、担当A、6人日）」「トークスクリプト作成（担当B、4人日）」「CRM商談ステージ設計（担当C、5人日）」「架電トライアル200件（担当A、12人日）」となり、末端は計22の作業（総工数86人日）に。 この段階で「反響後のフォロー担当が未定」という抜けを発見できた。 WBSで全量を86人日と可視化したことで、6か月に均すと月あたり約14人日（既存業務を圧迫しない配分）で回せると分かり、外注すべき「事例記事執筆（15人日）」の切り出し判断も可能になった。
よくある誤解・つまずき
- WBSは『やることリスト（動詞の羅列）』だと思われがちだが、本来は成果物（名詞）を階層で構造化するもの。 『架電する』ではなく『架電済みリスト200件』のように完了状態で書くと、進捗が白黒で判定でき、期日管理がぶれない。
- 分解と同時に順序や期日まで一気に決めようとして手が止まる。 WBSの役割は『作業の全量を漏れなく洗い出す』ことに限定し、順序・依存関係・期日はガントチャート、責任分担はRACIへ渡すと、各工程が軽く回る。
- 細かく割るほど良いという誤解。 末端が半日単位まで細かいと管理表の更新コストが施策の価値を上回る。 担当1人が数日〜2週間で終える粒度を目安にし、100%ルール（親＝子の合計）で過不足だけ確認する。
使うタイミング
アクションプラン（第4プロセス）で、戦略方針が固まり『何をやるか』の方向は決まったが『誰がいつ何を終わらせるか』が曖昧なときに使います。 早すぎる失敗＝ビジョンや戦略方針が未確定なまま作業分解に入ると、前提が変わるたびに全て作り直しになる（分解は方針確定後）。 遅すぎる失敗＝担当割り当てや期日設定を先に始めてしまうと、洗い出せていない作業が実行中に噴出し、スケジュールが破綻する。 WBSはガントチャート・RACI・リソース配分の『前工程』として、これらより先に置くのが正しい順序です。