WBSの作り方｜成果物を分解する記入例と工数の二重集計を防ぐ方法

WBS（Work Breakdown Structure）は、承認した仕事の範囲を、成果物と管理できる単位へ分けた構造です。細かい作業を大量に並べることが目的ではありません。必要な成果物が抜けていないか、同じ仕事を二つの担当が見積もっていないか、何をもって完了とするかを確認できる形にします。小さなLP案件の例で、分解、担当、完了証拠、工数集計をつなぎます。

WBSは成果物の構造、ガントは日程、マイルストーンは判断点

WBSは「何を仕上げるか」を示します。ガントチャートは「いつ、どの順序で進めるか」、マイルストーンは「どの節目で何を判断するか」を示します。同じ一覧を使って連携させることはできますが、成果物の階層だけでは日程も公開可否も決まりません。

たとえば「実装」は成果物のまとまりですが、「10月20日に公開する」は日付の条件です。「公開可否を判断する」は承認の節目です。この違いを保つと、制作物ができたから公開試験も終わった、といった取り違えを防ぎやすくなります。

担当や日付を記入する前に、承認済みの対象範囲と成果物一覧を確認します。WBSへ書かなかった作業が自動的に対象外になるわけではありません。見落としなら補い、新しい追加なら変更として扱うため、元の合意へ戻ります。

承認スコープを100%で覆い、漏れと重複を確かめる

PMIのWBSに関する解説では、成果物を基にした階層と、管理業務を含む範囲全体を覆う考え方が示されています。ここでいう100%は、承認した範囲を漏れなく分解するための確認であり、プロジェクトの成功率や進捗率を意味しません。

親の成果物は、子の成果物を合わせた範囲と整合させます。同じ原稿作成を「コンテンツ」と「デザイン」の両方へ丸ごと含めると重複し、調整やレビューを誰も含めないと不足します。担当ごとの希望作業を足すだけでなく、成果物から逆向きに確認してください。

管理、会議、品質確認、権利確認、移行、運用引き継ぎも、必要な範囲ならどこに含むかを決めます。すべてを独立行にする必要はありませんが、内包する行の説明を残します。実作業の入力だけでは、承認待ちの時間や相手への依頼が見えないことにも注意します。

対象外は、その理由と関連する文書を残します。既存の合意と矛盾する場合は、一覧の削除だけで済ませず、関係者で確認します。作業の追加が見つかったときは、記入漏れ、詳細化、新しい要求のどれかを判断し、費用や日程への影響を扱います。

小さなLP案件の成果物ツリーと辞書の記入例

次は「公開して運用できるLP」を親1とする、架空の小規模案件です。5行は末端のワークパッケージで、工数は相場ではなく例示用の見積もりです。レビュー等は各行の含む範囲に入れた前提です。現実の案件で他の承認範囲があれば、その仕事も追加します。

親1の行は要約です。子の工数48時間を表示する場合も、集計では親と子を同時に足しません。公開可否の最終判断は、必要な試験や未解決事項を確認する節目として別に置きます。5行が完了したことと、公開を決める権限を持つことも別です。

辞書には、行番号、成果物、含む作業、含まない作業、前提、受入条件、責任者を残します。「実装済みLP」にどのフォームや環境を含むかなど、表の短い記述だけで足りない部分を補います。誰かが着手でき、別の人が完了を確認できる説明にしてください。

担当責任と完了証拠からワークパッケージの粒度を決める

分解する粒度は、成果物を確認できるか、責任を持つ窓口が定まるか、見積もれるかで決めます。一律の階層数や「必ず8〜80時間」といった基準だけで切ると、小さな仕事を無理にまとめたり、大きな不確実性を隠したりします。

責任者は、完了判断と調整の窓口です。すべての実作業を一人で行う意味ではありません。執筆、専門確認、承認を複数人で分担する場合は、役割と受け渡しを辞書に書きます。共同作業だからと責任者を空欄にすると、未決の確認が残りやすくなります。

細分化する目安は、担当、納品物、完了条件、前提が一つにまとまるかどうかです。例えば「LP全体」では原稿と実装を別々に確認したいなら分けます。逆に、同じ担当が続けて実行し同じ証拠で確認する細かな操作は、辞書の中の作業としてまとめられます。

状態を「完了」へ変える前に、決めた証拠を確認します。作業時間を使い切ったこと、担当者が提出したこと、発注側が受け入れたことは異なります。差戻しがあれば、未完了へ戻す条件や再確認の担当を決め、過去版と修正理由を残してください。

末端行だけの工数合計と完了割合の計算例

上の表をA列からG列へ置き、F列を計画工数、G列を状態、末端行を2〜6行とします。計画工数は数値で入力し、合計は0でない前提です。状態の表記を「完了」でそろえます。親の要約行はこの範囲に含めません。

計画工数合計 = 8 + 12 + 20 + 4 + 4 = 48時間。完了行の計画工数 = 8 + 12 = 20時間。工数重み付き完了割合 = 20/48 = 41.7%、件数比 = 2/5 = 40.0%です。分母が違うため、両方の数値を同じ「進捗」とだけ表示しないでください。

範囲合計はMicrosoftのSUMの説明を参照できます。

条件に一致する工数の合計はMicrosoftのSUMIFSの説明が参考になります。集計範囲と条件範囲の行数をそろえ、状態の文字列を一致させます。

41.7%は、完了と判定した末端行の計画工数による重みです。経過時間、予算消化、実際の残作業、完成予定日の予測ではありません。未完了行にも途中まで実施した仕事があり、残工数が当初見積もりから変わる場合があります。

日程計画へ渡し、変更時に範囲と見積もりを更新する

日程を作るときは、末端成果物を実行タスクへ展開し、先行条件、担当の割当、待ち、稼働日、レビューを確認します。WBS番号に先行IDを付けるだけでは、期間やカレンダーが足りないため、クリティカルパスは計算できません。

範囲を変更したら、影響する末端行、辞書、見積もり、日程、受入条件を同じ版で更新します。追加した仕事を既存の見積もりへ黙って押し込まず、変更理由と合意を残します。記入漏れだった場合も、元の承認範囲を確認して扱いを決めてください。

最初は今進めている一件から、成果物を5〜10個に仮置きし、完了証拠と責任者が説明できるか試します。この個数は開始時の作業方法の一例で、適切な粒度の基準ではありません。漏れと重複を直してから日付を割り当てると、日程の根拠を共有しやすくなります。

次の作業に合わせて、ガントチャートの作り方｜Excel・スプレッドシートの記入例と数式、マイルストーンの設定方法｜完了条件つきテンプレートと記入例、スケジューリングとは？依存関係・稼働日を反映する6ステップを参照してください。