WBSの作り方｜発注側が押さえる5つの手順

はじめに

システム開発の進捗会議で、開発会社から「設計は8割完了」と報告された。ところが、利用部門が画面を確認する日や、社内の承認に必要な期間は予定表に載っていない。開発作業が順調でも、発注側の確認待ちで次の工程へ進めなくなることがあります。

WBSは、プロジェクトに必要な作業を階層的に分解して、全体と個々のつながりを見えるようにする方法です。開発会社の管理表を受け取るだけでなく、現場確認、社内承認、データ準備など発注側の作業も一緒に整理することが大切です。

この記事では、開発の専門家ではない事業部門やDX担当者が、WBSを作り、開発会社と使うための5つの手順を説明します。表の項目や架空の受注システムを使った例も紹介します。

WBSとスケジュール表の違い

WBSは、プロジェクトの対象となる仕事を「何を作り、何をするか」という観点で分けた構造です。ガントチャートは、その作業を時間軸に並べ、開始・終了や前後関係を確認するための表現です。実務ではWBSの一覧に予定日や進捗欄を加え、ガントチャートと併用することが多くあります。

デジタル庁の標準ガイドラインは、政府情報システムの整備・管理について手順や関係組織の役割を整理しています。民間の案件にそのまま適用する規則ではありませんが、作業の範囲や関係者の役割を確認する際の参考になります。

たとえば「受注システムを導入する」を一行にすると、誰が何を終えたら完了か判断できません。「受注画面」「既存データの移行」「利用者向け準備」のように成果物や目的で分け、それぞれに必要な確認と作業を置きます。分解の仕方は案件に応じて調整し、工程名を並べること自体を目的にしないのがポイントです。

発注側がWBSを作る5つの手順

1. 対象範囲と成果物を並べる

最初に、今回の目的と対象範囲を確認し、完了時に必要な成果物を書き出します。画面や機能だけでなく、移行したデータ、テスト結果、操作マニュアル、利用者への周知なども候補です。契約上の納品物と、発注側が社内利用のために用意するものは区別します。

同時に、今回対象外のことも記録します。例えば初回は受注登録と検索を対象とし、在庫システムとの自動連携は別途検討すると決めたなら、境界を書きます。対象外の作業が必要になった場合は、WBSへ黙って追加せず、影響と変更の承認方法を確認します。

NASAのWBSハンドブックの公開資料は、作業範囲を管理可能な単位へ分け、役割分担やスケジュールの基礎とする考え方を示しています。宇宙開発向けの資料ですが、作業全体と担当者をつなぐ考え方は一般的なプロジェクトにも参考になります。

2. 作業を確認できる単位に分ける

成果物ごとに、作る、確認する、直す、承認するという流れを考えます。受注画面なら「画面案を作成」「現場が業務の流れを確認」「指摘を反映」「責任者が仕様を承認」などに分けます。開発側だけで終わる作業と、発注側の判断が必要な作業を混ぜないようにします。

細分化の目安は、担当者が分かり、完了したか証拠を見て判断できることです。一方、数分ごとの操作まで書けば良いわけではありません。期間が長く途中の状態が分からない作業は、レビューや成果物の区切りで分けます。未確定の遠い工程は大きめに残し、情報が揃った段階で詳細化しても構いません。

直近の作業は担当者が見通しを立てられる程度まで分け、遠い工程は検討が進んだ時点で更新します。分解の深さに一律の正解はなく、管理に必要な情報と更新にかかる手間の両方を見て調整してください。

3. 担当と完了条件を付ける

各作業には、実施する人だけでなく、確認する人と完了条件を付けます。「要件を確認」では範囲が広すぎます。「受注担当者が入力項目と例外時の扱いを確認し、未決事項とともにレビュー結果を返す」と書くと、何をもって次に進めるか共有できます。

役割は組織名だけでなく、実際に判断できる担当者まで確認します。代理者が必要な場合もあります。作業の担当と最終的な承認責任は同じとは限りません。例えば現場担当がレビューし、部門責任者が業務ルールを承認し、開発会社が指摘を反映する場合は、それぞれを区別します。

完了条件は「会議を開いた」より「レビュー結果が記録され、未決事項の担当と期限が決まった」のように、後から確かめられる状態を選びましょう。判断が残っているのに資料を提出しただけで完了と扱うと、後工程に未決事項が隠れます。

4. 前後関係と予定を調整する

次に、どの作業が終わらないと別の作業を始められないかを確認します。例えば、画面仕様の承認が遅れれば、開発会社の実装開始やテスト準備に影響するかもしれません。社内の稟議や繁忙期、他部署からデータを受け取る日程も、発注側の予定として明示します。

予定日だけを埋めるのではなく、作業量や担当者の確保状況を開発会社・利用部門とすり合わせます。必要な確認者が同時に別案件を抱えているなら、カレンダー上で空いて見えても実施可能とは限りません。依存関係や前提条件をメモし、遅れたときの影響先をたどれるようにします。

5. 定例会で実績と未決を更新する

WBSは最初に作って終わりではありません。定例会では、予定と実績、完了の根拠、遅延理由、次に必要な判断を確認します。進捗率だけで会話せず、何が終わり、何が残り、誰の返答を待っているかを聞きます。レビュー後の修正が残るなら、提出を「完了」と誤認しないよう状態を分けます。

予定を変更するときは、理由と影響先、承認者を残します。契約条件や納期の変更が必要かは、案件の契約と管理手続きに沿って判断してください。WBSの更新は、契約変更そのものを自動的に成立させるものではありません。

WBSの記入例：受注システムの画面を準備する

次は、発注側と開発会社が役割をすり合わせるための架空の例です。日数や担当は案件の条件によって変わるため、そのまま見積もりとして使わないでください。

予定日や実績日を追加し、先行作業のIDを付ければ、誰の待ちで何が止まるかを共有しやすくなります。進捗率を使う場合も、主観的な「ほぼ完了」だけに頼らず、レビュー提出、指摘対応、承認といった節目を併記しましょう。数字の付け方はチームで統一します。

データ移行を含む案件では、作業の一覧と合わせて、対象範囲や検証、切り戻しの判断を整理する必要があります。移行計画書の作り方も参照し、作業予定と判断条件を混同しないようにしましょう。

よくある失敗と防ぎ方

発注側の作業が載っていない。 現場確認、データ準備、承認、利用者への説明を確認し、担当と必要な時間を追加します。開発会社に任せる範囲と、自社が決める範囲を分けることが出発点です。

作業名が大きすぎる。 「設計」「テスト」だけでは、進行中のまま状況が見えません。成果物のレビューや判定単位で分け、完了の根拠を共有します。逆に細かすぎて更新が続かない場合は、管理に必要な単位へまとめ直します。

予定変更の理由が残らない。 単に期限を後ろへ動かすと、当初予定との差や影響が分からなくなります。変更理由と承認、影響する作業を記録し、関係者へ共有します。課題管理表など別の台帳を使う場合も、対応する項目へたどれるようにします。

要件と作業のつながりを確認する

WBSは作業の構造を共有する道具であり、仕様書そのものではありません。何を作るかが曖昧なまま予定だけ細かくしても、後から作業を追加する可能性があります。業務の流れ、要望、例外、未決事項を先に整理し、関連するレビューや承認をWBSに置くことが重要です。

Kakusillは、散在する仕様書や業務の暗黙知をAIが使える形に整理し、要件定義から仕様管理までの上流工程を支えるワークスペースです。WBS専用の作成機能を前提にするのではなく、関係者が確認すべき業務や仕様を整理する際の選択肢として検討できます。

まずは次の定例会に向けて、現在の予定表から「発注側が確認・判断する作業」を探してみてください。担当者、完了条件、前後関係が分かるだけでも、表を眺める会議から、次の判断を進める会議に変えられます。