【事例解説】WBSとは？システム開発におけるWBSの作業を漏れなく書き出す方法
プロジェクトのWBSってなに？
WBSの作業はどうやって書き出せばいいの？
WBSの書き方を知りたい！
プロジェクトにおいて、WBSの作成はとても重要な作業です。
WBSの作業が漏れるとプロジェクトのコストやスケジュールに大きく影響するため、精度の高いWBSを作成することが大事です。
そのためには、プロジェクトの目的を達成するために具体的な作業に落とし込み、作業を漏れなく書き出す技術が必要です。
ここでは、WBSとは何か、WBSの作業を書き出す方法、ワークパッケージの最適な作業量など、システム開発のWBSの事例を見ながらわかりやすく解説します。
少しでもWBSの理解が深まり、プロジェクトマネジメントの参考になれば幸いです。
マスタースケジュールとは
プロジェクトのスケジュールには、プロジェクト全体の日程を俯瞰した「マスタースケジュール」と、具体的な作業に担当者を割り当てた「WBS」があります。
マスタースケジュールはプロジェクトのベースラインとなるもので、ステークホルダーが共有することで全体の作業やイベントを理解し、混乱せずにプロジェクトを進めるために必要となります。
そのマスタースケジュールをもとに、具体的な作業に分解して担当者を割り当てたものがWBSです。WBSは、主に作業の進捗を管理します。
WBSとは
WBS（Work Breakdown Structure、作業分解図、作業分解構成図）とは、プロジェクトの開始から終了までの作業を漏れなく重複なく書き出して担当者を割り当てたプロジェクト管理資料です。
プロジェクトの目的を達成するために、具体的な作業に落とし込むことが重要です。
WBSには次のような役割があります。
- プロジェクトの開始から完了までの作業が明確になる。
- 作業を実施する担当者が明確になる。
- 作業を行うために必要な期間（所要期間）が明確になる。
- プロジェクト全体の工数（予算）が明確になる。
- 必要なスキルと要員数が明確になる。
- 作業の実施状況が明確になる。
マスタースケジュールとWBSの違い
それぞれ簡単に言うと、マスタースケジュールで全体の作業やイベントを漏れなく見渡し、WBSで作業の進捗を管理していきます。２つのスケジュールを作成するのは面倒ですが、それぞれ役割が異なります。
プロジェクトを確実に進めるには、「いつ、どこに到達すべきか」という大きな流れと、「そのために今、何をするか」という具体的な作業を切り分けて考える必要があります。
| 項目 | マスタースケジュール | WBS |
|---|---|---|
| 例え | 移動の「旅程表」 | 具体的「準備リスト」 |
| 視点 | 鳥の目（全体俯瞰） | 虫の目（細部実行） |
| 主な対象 | 経営層・顧客・ステークホルダー | 現場メンバー・担当者 |
| 管理単位 | フェーズ、マイルストーン | タスク（作業） |
| 目的 | 納期の合意、進捗の把握 | 役割分担の明確化、工数見積もり |
マスタースケジュールとWBSの役割について理解できていない方は、こちらの記事もぜひご覧ください。[マスタースケジュールとWBSの書き方]
WBSの作業を書き出す方法
いきなり具体的な作業を書き出すことは難しく、作業が漏れやすいため、概要レベルから詳細レベルに段階的に作業を分解していきます。
初めは、概要レベルのまとまった作業単位にプロジェクトでやるべきことを洗い出します。プロジェクト全体を鳥瞰できる最上位レベルのものがマスタースケジュールとなります。
概要レベルの作業を全て洗い出したら、それらをさらに詳細な作業に分解し、最終的にワークパッケージと言われる単位まで分解します。ワークパッケージについては後ほど説明します。
下図は分解のイメージです。システム開発プロジェクトのWBSを作成する事例です。
100％ルール
どのように分解するかはプロジェクトの規模や特性によって変わります。
小規模なプロジェクトであれば直接ワークパッケージに分解できるでしょうし、複雑なプロジェクトは組織単位に分解したり、全国規模であれば地区単位に分解することも考えられます。大規模プロジェクトは分解の階層も深くなるでしょう。
いずれにせよ、ワークパッケージを全て実行すればプロジェクトの目的が達成できる状態になっていければいけません。
ワークパッケージから見て上位の階層とは親子関係にあります。下位の階層の作業を全て実行すれば上位の階層の作業の目的が100％満たされている状態かを意識して作業を分解することが大事です。
これを「100％ルール」と言いますが、最上位レベルからワークパッケージまで、100％ルールに外れていないか確認しましょう。
ワークパッケージとは
作業を細分化して書き出した最下位レベルの作業のことを「ワークパッケージ」と言いいます。
ワークパッケージには成果物を完成する作業が割り当てられるため、成果物＝ワークパッケージと考えるとわかり易いと思います。
では、ワークパッケージはどれくらいの作業量にするのが良いのでしょうか？
8/80ルール
ワークパッケージの作業量の判断基準として「8/80ルール」というものがあります。
これは、ワークパッケージの作業量を8時間以上、80時間以内にしましょうというルールです。
8時間は1日の活動時間に当たりますが、1日より少ない作業量に分割したのでは細かすぎるということになります。
また、80時間は10日間、つまり２週間（週休2日として）以上の作業量では大き過ぎるのでもっと分解しましょうということです。
それでも1日から10日（２週間）だと結構な幅があります。
どれくらいを目安にすればいいかは進捗報告のサイクルで決めるのが良いかと思います。
作業量は進捗報告のサイクルで決める
作業の進捗状況を確認するために、進捗を毎週報告する運用を行う場合は、ワークパッケージを5日（１週間）以内にすることで進捗率の簡素化ができます。
例えば、作業量が10日間程度のワークパッケージを週次で進捗報告する場合、作業期間が長いため、進捗率も20%、35％、70％などと細かい値で報告したくなります。
作業量を進捗報告のサイクルに合わせて5日間程度にすると、作業着手したら進捗率は50％、作業完了は100％という具合に簡素化できるため報告側と管理側ともに楽になります。もし、着手後に２週間も完了していないワークパッケージがあれば、それは対策が必要と判断ができます。
ですので、週次で進捗確認する場合はワークパッケージを5日（１週間）以内にするのが妥当な作業量になるというわけです。
マスタースケジュールの書き方
ここでは、下記の想定プロジェクトの事例を紹介します。
注文管理機能と出荷管理機能を持つ販売管理システムを新規構築するプロジェクトです。
まず最初に、どのようなシステムを構築すればいいのかを要件定義フェーズでお客様から聞き出す必要があります。要件定義で必要な機能要件が決まって初めて具体的な作業を書き出す準備ができます。
この事例では、プロジェクト計画で作成したマスタースケジュールをもとにプロジェクトを進め、最初の工程である要件定義が完了後にWBSを作成することを想定しています。
一般的なシステム開発で出てくるであろう作業工程を列挙しています。それぞれの作業内容はここでは説明しませんが、ご自身が担当されるプロジェクトの参考になれば幸いです。
システム開発のマスタースケジュール事例
最上位レベルの作業をまとめたスケジュールです。
マスタースケジュールはプロジェクトのベースラインとなるもので、ステークホルダー全員が共有することで全体の作業やイベントを理解でき、混乱せずにプロジェクトを進めることができます。
※画像をクリックすれば拡大表示されます。
マスタースケジュールを書く時のポイント
繰り返しになりますが、マスタースケジュールはプロジェクトのベースラインとなるものです。ステークホルダーが共有することで全体の作業やイベントを理解でき、混乱せずにプロジェクトを進めることができます。
マスタースケジュールは、以下のポイントに気を付けて作成しましょう。
- スケジュールを俯瞰して全体が見れるように１枚にまとめる。
- マイルストーンに、制約条件になるようなイベント（保守切れ期日、サービス開始や停止日など）や決まっている予定、約束された期限（お客様との会議、契約期限、本稼働日など）を明記する。
- 担当を記述して役割と責任を明確にする。
- それぞれの作業に先行ー後続の繋がり（依存関係）がある場合は、それがわかるように例えば作業間を矢印でつなげて表示する。
- 作業はアプリケーション開発だけでなく、開発環境や本番環境のサーバやネットワーク環境などのインフラ、データ移行、切替の段取り作業も明記する。
- お客様が行う作業（マニュアル作成や教育、マスター設定など）も明記して、お客様自身が主体となって実施いただくことを共有する。
進捗状況を報告する時のポイント
マスタースケジュールは全体が俯瞰できるため、主にプロジェクトのお客様やプロジェクトマネージャーとの進捗確認に利用します。
下図の例を参照してください。
進捗状況を報告する際は、現時点がどこなのか分かるように日付から縦に進捗線を引きます。（図の例では赤線を引いています）
もし予定通りに進捗していない場合は折れ線で現時点の進捗状態を記載します。
この例では、4月の報告1の時点では順調ですが、5月の報告2では出荷管理で進捗線が左側に折れて記載されています。これは、現在の予定に対して進捗率が約50%のため開発が遅れていることを表しています。この折れ線のことをイナズマ線と言います。
6月の報告3の時点では出荷管理の開発遅れが悪化していることがわかります。早急に対策が必要です。
その後、7月の報告4では対策の成果で出荷管理の遅れは解消しつつあり、8月の報告5では出荷処理も完了して、マスター管理は予定よりもイナズマ線が右側に折れていて進捗が進んでいることがわかります。
このように、進捗状況の報告ではイナズマ線で入れることで順調に進んでいるのか、遅れている作業はどれか一目で分かります。
また、この例のように過去のイナズマ線を残すと、前回からの状況変化が分かり、遅延している場合は対策が取りやすくなります。
WBSの書き方
WBSの目的は、作業予定と作業実績を確認して進捗に遅れがないか観察することです。作業状況を日々観察し、遅れが見つかった場合はすぐに対策を検討して軌道修正することが重要です。
そのためには、漏れなく作業を書き出す必要があります。
こちらも、上記の想定プロジェクトの事例に当てはめて紹介します。
システム開発のWBS事例
マスタースケジュールに書き出した作業を分解してWBSを作成します。
マスタースケジュールとの関連がわかるように、マスタースケジュールの作業項目の名称から細分化していきます。
下図の例を参照してください。
上述のシステム開発のマスタースケジュールをベースにWBSを作成するサンプルです。左側が要件定義のWBS、右側が開発工程（設計フェーズ以降）のWBSのイメージです。
要件定義で決定した機能要件（図左側）から、開発工程（設計フェーズ以降）の具体的な作業に分解（図右側）してWBSを作成する事例です。
※画像をクリックすれば拡大表示されます。
WBSを書く時のポイント
要件定義（上図左側）でシステム化する機能を明確にします。規模が大きい場合は機能をサブシステム単位にまとめて整理します。
次の開発工程（上図右側）では、要件定義で確定した機能一覧をもとに作業を細分化します。
サブシステムから機能へ、機能から作業工程へ、作業工程から作成する成果物へという具合にブレイクダウンしていくと簡単に作業分解できます。成果物を作成する作業がワークパッケージとなります。
この時、作業項目に漏れや重複がないかも気を付けて作成しましょう。
WBSはプロジェクトメンバーと一緒に精度を高める
WBSの作成はとても重要な作業ですが、プロジェクトが複雑になれば時間もかかります。プロジェクトマネージャーひとりが作成すると作業の漏れや重複に気づかないこともあるでしょう。
重要な作業の漏れはプロジェクトのコストやスケジュールに大きく影響しますので、決してひとりだけでWBSを作成せず、メンバーに協力を仰ぐことも大事です。
ですから、WBSの作成はプロジェクトメンバーに協力してもらったり、有識者にレビューしてWBSの完成度を高めましょう。
WBSだけでスケジュールは完成しない
WBSを作成する時は、それぞれの作業の依存関係や順序は意識しません。
前述の通り、作業の漏れはスケジュールだけでなくコストにも影響しますので、WBSでは作業が漏れないように取り組む必要があります。まずは、漏れなくダブりなく作業を書き出すことに専念してWBSを完成させましょう。
しかし、無事にWBSが完成しても、スケジュールが完成したわけではありません。
WBSが完成したら、作業の依存関係や順序を検討し、工数と所要期間を見積もって、作業を行う時期と担当者を決めてスケジュールが完成します。
スケジュール完成までの6つのステップを解説していますので、こちらもあわせてお読みください。
少しでもプロジェクト活動のヒントになれば幸いです。
