WBS (Work Breakdown Structure) とは
WBS (Work Breakdown Structure) とは、プロジェクトを細分化して、その構成要素をツリー形式の階層構造として整理したものである [1] [2] [3] 。
プロジェクトを細分化したツリー
プロジェクト全体をいくつかの大項目に分け、それぞれの大項目をさらにいくつかの中項目、小項目へと細分化する。充分に細分化した後は、それぞれの小項目（ワーク・パッケージ）に対する具体的な作業（アクティビティまたはタスク。以降、本稿ではタスクと称する）を列挙する。
プロジェクト管理ソフトウェアとして広く使われているMS-Projectでは、ワーク・パッケージとアクティビティを区別せずに、タスクと称している。タスクを細分化したものを、サブタスクと称している。
なお、実際にWBSを作成する際は、ブレーンストーミングによって最下層の作業項目を洗い出し、それらを分類しながら積み上げていく、ボトムアップ・アプローチも有効である。
一通りの細分化を終えたら、WBSを表形式に整理する。一般的なプロジェクトでは、細分化された項目の数が数十から数百にも及ぶ、大きな表が作成される。
表形式のWBS
こうして作られたWBSは、プロジェクトの構成要素が重複も漏れも無くリストアップされており(※)、プロジェクトの目的や成果物、作業範囲が明確に定義された、プロジェクトの詳細な設計図となる。このWBSが、作業工数の見積もり、納期の契約、各工程の終了条件の設定、作業分担の計画など、その後のあらゆるプロジェクト管理の基盤となる。
※これをMECE（ミッシー：Mutually Exclusive, Collectively Exhaustive）と呼ぶ。
ソフトウェア開発におけるWBSの書き方
WBSでは原則として、成果物を中心に細分化を行う。
ソフトウェア開発における物理的な成果物は、仕様書、設計書、モジュール、テスト計画書などになる。だが筆者は、ソフトウェア開発においては、目に見えない成果物、即ち、機能を中心に細分化していく方法も有効だと考えている。
機能を中心としたアプローチでは、細分化された各機能の配下に、設計、実装、テストなどの作業がタスクとして並ぶ。この場合は、一部の機能を外したりすることも簡単なので、見積もりをした後で機能の選別を行う場合や、反復型の開発などでは有効であろう。
機能を中心に細分化したWBS
WBSによって見積もりが改善する
WBSを使った見積もりでは、細分化された個々の項目について工数を見積もった上で、それらを積み上げることで、全体の工数を求める。必要な作業項目が漏れなく、充分に詳細なレベルまで洗い出されているため、得られる見積もりも、充分に正確なものとなる。
これまでのソフトウェア開発の現場では、仕様策定に何日、設計に何日、実装に何日、テストに何日、という具合に、工程に沿った大まかな計画しか立てずに作業を始めることも多かった。WBSを使うことで、こうしたただの思いつきや希望的観測ではなく、根拠のある数値に基づいた、現実的な計画を立てることができる。
WBSはまた、見積もりの妥当性を示す、有力な資料となる。 WBSを作成することで、顧客に対して、正確でかつ説得力のある見積もりを提示することができる。実際、一部の省庁や地方自治体では、入札の際に見積もりが妥当かどうかを判断するために、WBSの提出を求めるところもあり [2] 、見積もりにおいて、WBSはますます重要となってくる。
成果物指向で細分化されたWBSでは、見積もり工数は、作業に要する時間としてだけでなく、その成果物の商品的価値として見ることもできる。開発者は現実的な作業時間を見積もり、それにかかる費用を算出する。一方の顧客は、成果物にそれだけの対価を払う価値があるかどうかで見積もりを判断する。双方がそれぞれの観点から、見積もりの妥当性を検証できる。
WBSでは進捗管理は改善しない
WBSは、開発プロジェクトを始める前に作成する、予定を立てるための道具である。見積もり工数は記入されるが、実際にプロジェクトがスタートした後の実績は、通常は記入しない。
開発プロジェクトがスタートすると、さまざまな要因で、次第に見積もりとのずれが生じることはすでに述べた。見積もりと実績のずれを把握し、必要な対策を取ることが、進捗管理である。だが、実績を記入しないWBSでは、ずれを把握することはできない。即ち、進捗管理には利用できない。
納期までに余裕のない短期開発では、WBSに記載されている詳細な作業項目の単位でずれを把握し、細かい進捗管理を行う必要がある。そのためには、見積もり段階で作成したWBSを、その後の進捗管理にも活用することが望ましい。