WBSの作り方｜サービス公開までの仕事を、完成物から分解する

こんにちは。バナナデスクです。

「原稿を書く、デザインする、公開する」と並べると、サービスの準備は三つで終わるように見えます。ところが公開直前になって、申込を受け取る人や、受付後に送る案内が決まっていないことに気づくかもしれません。

この抜けを探す時に役立つのがWBSです。思いついた作業を順番に書く前に、公開時に何が揃っていなければならないかを、完成物から分けていきます。

今回は、小さな相談サービスを公開する架空の仕事を、3階層に分解します。工程を増やすためではなく、誰にも割り当たっていない完成物を見つけるための例です。

執筆：バナナデスク｜WEBビジネスの設計・集客・改善

WBSは、日程より先に仕事の範囲を決める

WBSはWork Breakdown Structureの略で、プロジェクトの範囲を、成果物を中心に階層へ分けるものです。PMIの2026年8月の解説でも、日程表や組織図との違い、合意した範囲を漏れや重複なく含める考え方が示されています。

「メールを送る」は活動です。「参加者向けの案内文と送信条件が揃っている」は確認できる成果物です。WBSでは後者を置き、その成果物を作る活動や順番、日付を後から予定へ落とします。

項目	架空の公開案件
目的	案内文整理の相談サービスを、内容理解から受付まで使える状態で公開する
完成条件	提供条件を承認し、公開ページを表示でき、検証用の申込が担当者へ届き、受付後の案内と更新担当が決まっている
含むもの	内容、ページ、受付、引継ぎ、合意と検証の管理記録
含まないもの	広告配信、販売後の継続運用、新しい講座制作、独自の決済システム開発

売上や申込数の目標と、この制作の完成条件も分けます。公開できたことだけで、集客成果まで達成したとは扱いません。

第1階層は全体、第2階層は五つの成果物のまとまり、第3階層は担当を決めて完了を確認できる単位です。番号は追跡用で、実施順を意味しません。

管理記録を入れるのは、打ち合わせを無限に増やすためではありません。誰が何を承認したか、どの変更が公開対象へ入ったかも、完成までに必要だからです。今回の最下層は10項目です。この件数が、すべてのLP制作に必要な標準数ではありません。

辞書というと大きな文書に見えますが、一つの作業単位について「含む範囲、担当、完了条件、対象外」を補う表です。

項目	1.2.2 実装済みページと表示確認記録	1.3.2 受信確認記録と受付用文面
担当	制作担当	受付担当。技術部分は制作担当へ確認
含む範囲	承認済み原稿・画像の反映、リンク、PCと指定スマホ幅での表示	検証用入力の受信照合、重複・不足時の扱い、受付返信文
完了条件	承認案と一致し、欠けた画像や本文の横はみ出しがない。確認対象と結果を記録	送信したテストIDと受け取った記録が一致。担当が返信文と処理先を説明できる
前提	1.1.2原稿、1.2.1配置、利用可能な画像が確定	1.3.1フォームの設定と、受付条件が確定
含まないもの	フォーム内部の受付処理は1.3で扱う	公開後の毎日の顧客対応。今回確認するのは運用開始の準備まで

1.2.2にも1.3.2にも「フォーム確認」とだけ書くと、同じ仕事を二重に数えるか、どちらかがやると思って抜けます。画面上のフォームへの到達と、送信内容の受付照合のように境界を分けてください。

公開後に必要なものを一つずつ挙げ、番号が付くかを確認します。