プロジェクトマネジメントのWBSってなに？
WBSの作業はどうやって書き出せばいいの？
WBSの書き方を知りたい！
プロジェクトマネジメントにおいて、WBSの作成はとても重要な作業です。WBSの作業が漏れるとプロジェクトのコストやスケジュールに大きく影響するため、精度の高いWBSを作成する方法を知ることが大事です。
ここでは、WBSとは何か、WBSの作業を書き出す方法、ワークパッケージの最適な作業量など、システム開発のWBSの事例を見ながらわかりやすく解説します。少しでもWBSの理解が深まり、プロジェクトマネジメントの参考になれば幸いです。
WBSとは
WBS（Work Breakdown Structure、作業分解図、作業分解構成図）とは、プロジェクトの開始から終了までの作業を漏れなく重複なく書き出して担当者を割り当てたプロジェクト管理資料です。プロジェクトの目的を達成するために、具体的な作業に落とし込むことが重要です。
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を書き出す事例
ここでは、下記の想定にあるようプロジェクトの事例を紹介します。
注文管理機能と出荷管理機能を持ったシステムを構築するプロジェクトです。まず最初に、どのようなシステムを構築すればいいのかを要件定義フェーズでお客様から聞き出す必要があります。要件定義で必要な機能要件が決まって初めて具体的な作業を書き出す準備ができるわけです。
この事例では、プロジェクト計画で作成したマスタースケジュールをもとにプロジェクトを進め、最初の工程である要件定義が完了後にWBSを作成することを想定しています。
一般的なシステム開発で出てくるであろう作業工程を列挙しています。それぞれの作業内容はここでは説明しませんが、ご自身が担当されるプロジェクトの参考になれば幸いです。
マスタースケジュールの事例
最上位レベルの作業をまとめたスケジュールです。マスタースケジュールはプロジェクトのベースとなるもので、ステークホルダー全員が共有することで全体の作業やイベントを理解でき、混乱せずにプロジェクトを進めることができます。
※画像をクリックすれば拡大表示されます。
参考に、マスタースケジュールのポイントを列挙します。
- スケジュールを俯瞰して全体が見れるように１枚にまとめる。
- マイルストーンに、制約条件になるようなイベント（保守切れ期日、サービス開始や停止日など）や決まっている予定、約束された期限（お客様との会議、契約期限、本稼働日など）を明記する。
- それぞれの作業に先行ー後続の繋がり（依存関係）がある場合は、それがわかるように例えば作業間を矢印でつなげて表示する。
- 作業はアプリケーション開発だけでなく、開発環境や本番環境のサーバやネットワーク環境などのインフラ、データ移行、切替の段取り作業も明記する。
- お客様が行う作業（マニュアル作成や教育、マスター設定など）も明記して、お客様自身が主体となって実施いただくことを共有する。
WBSの事例
マスタースケジュールに書き出した作業を分解してWBSを作成します。マスタースケジュールの作業はシステム開発の工程に分解して記述（表の左端の工程欄）していますので、WBSの作成は作業工程を分割することから始まります。
下図は、要件定義で決定した機能要件（図の左側）から、具体的な作業に分解（図の右側）してWBSを作成する事例です。
※画像をクリックすれば拡大表示されます。
要件定義を行った結果、サブシステム単位にまとめて整理することになりました。サブシステム単位に必要な機能が列挙されています。（図の左側）
次の開発工程では、要件定義で確定した機能一覧をもとに作業を細分化します。サブシステムから機能へ、機能から作業工程へ、作業工程から作成する成果物へという具合に作業を分解しています。（図の右側）
なお、成果物を作成する作業がワークパッケージとなります。
プロジェクトメンバーと一緒に精度を高める
WBSの作成はとても重要な作業ですが、プロジェクトが複雑になれば時間もかかります。プロジェクトマネージャーひとりが作成すると作業の漏れや重複に気づかないこともあるでしょう。
重要な作業の漏れはプロジェクトのコストやスケジュールに大きく影響しますので、決してひとりだけでWBSを作成せず、メンバーに協力を仰ぐことも大事です。
ですから、WBSの作成はプロジェクトメンバーに協力してもらったり、有識者にレビューしてWBSの完成度を高めましょう。
WBSだけでスケジュールは完成しない
WBSを作成する時は、それぞれの作業の依存関係や順序は意識しません。
前述の通り、作業の漏れはスケジュールだけでなくコストにも影響しますので、WBSでは作業が漏れないように取り組む必要があります。まずは、漏れなくダブりなく作業を書き出すことに専念してWBSを完成させましょう。
しかし、無事にWBSが完成しても、スケジュールが完成したわけではありません。
WBSが完成したら、次は作業の依存関係や順序を検討し、工数と所要期間を見積もって、作業を行う時期と担当者を決めてスケジュールが完成します。
そのスケジュールの立て方について解説していますので、こちらもあわせてお読みください。少しでもプロジェクト活動のヒントになれば幸いです。
