システム開発のWBSの作り方｜成果物から作業を分解する

システム開発のWBSは、必要な仕事を階層的に分け、範囲を見えるようにするものです。「設計・実装・テスト」と大きく並べた段階から、担当者が何を終えれば次へ渡せるか分かる単位へ具体化します。

最初から日付を埋めるより、成果物と完了条件をそろえる方を先に進めましょう。ここでは、小さなCSV出力機能を説明用の例にして、分解の粒度と漏れの見方を整理します。例の工数や納期は設定しません。

WBSと日程表は役割が違う

NASAのソフトウェア開発ハンドブックは、WBSをプロジェクトに必要な仕事の階層的分解として説明し、成果物を軸にする型とプロセスを軸にする型を挙げています。また、補足する辞書に目的、成果物、依存関係などを記述するとしています。NASA「Work Breakdown Structures That Include Software」

WBSで「何をするか」を整理したうえで、作業の順序、必要な人、見積もった時間、利用できる日程を組み合わせます。WBSの項目がそろっただけでは、実行可能な納期が確定したわけではありません。

この記事では、成果物から始め、その下を設計・実装・確認などの作業へ分ける方法を提案します。全案件で唯一の正解となる分け方ではありません。

1. 作るものと対象外を短く書く

架空の業務システムに「一覧の検索結果をCSVで出力する機能」を追加するとします。対象を次のように置きます。

• 作るもの：画面で絞り込んだ結果を、合意した列のCSVで出力する機能
• 今回含めるもの：出力条件の仕様、実装、確認結果、利用案内
• 今回含めないもの：定期的な自動配信、別システムへの自動取込み

ここで「CSV出力」とだけ書かず、列、文字の扱い、出力対象、権限の条件を確認事項にします。分からない点は仮の工数で隠さず、調査や合意の作業として残します。

2. 成果物を下位の作業へ分ける

次は上の仮例に対するWBSの一部です。すべてのCSV実装に必須の項目ではなく、担当と確認内容が分かる粒度を示しています。

「テストする」だけで作業が大きすぎるなら、出力内容、画面との連携、利用者権限など、確認対象が分かれる場所で分解します。担当や環境が異なるなら、別の作業にする理由も明確です。

3. 二重計上と、どこにもない仕事を探す

上位の成果物ごとに担当者へ確認しても、共通の環境準備や全体のリリース作業が抜けることがあります。一方、画面側と出力側の両方に同じ連携テストを置くと、誰が実施するか曖昧になります。

見直す際は、次の問いを使ってください。

• 下位の作業を合わせると、上位で約束した範囲を満たすか。
• 同じ成果物や確認を、別の枝に重ねていないか。
• 環境、権限、テスト用データ、レビュー、利用案内を用意する仕事があるか。
• 対象外の作業が、説明なく下位に紛れ込んでいないか。

共通作業を独立させる場合は、各機能から参照する形にすると担当を一つに決められます。これは管理方法の提案であり、特定ツールの利用を前提にしません。

4. 細かすぎる作業はまとめ直す

「ファイルを開く」「一行入力する」のような操作まで管理すると、成果を確認するためのWBSから離れてしまいます。反対に「出力機能を完成させる」だけでは、未完了の理由が見えません。

粒度に迷ったら、「担当が決まるか」「終わった証拠を示せるか」「遅れや詰まりを説明できるか」で確かめます。この三つを同じ担当と同じ確認で扱える小作業は、まとめる候補です。作業時間を全件同じ長さへそろえる必要はありません。

分解して初めて調査不足が分かった場合は、先に調査する作業を置きます。未知の処理を細分化しただけで、見積もりが正確になったとは扱わないでください。

5. 担当・依存・予定を加え、変更を反映する

範囲が見えたら、担当と前提となる作業を加えます。仮例では、出力列が未確定なら、その影響を受ける設計や期待値の作成を特定します。並行して進められる作業があるかは、担当者と確認します。

見積もりへ進む際は、システム見積もりの前提条件のように、確定事項と仮定を分けてください。利用部門の確認待ちを開発作業の時間へ混ぜないことも、予定を説明する際に役立ちます。

変更要求が来たら、追加する行だけでなく、既存の設計・実装・テストへの影響を見直します。元のWBSと変更理由を残せば、何が増えたかを説明できます。

まず一つの機能で、成果物、作業、完了条件を対応させてみましょう。開発体制や担当範囲の相談については、テクノヴァースのSES事業をご覧ください。