プロジェクトを完遂させるのに必要なすべての作業を分割可能な単位に細分化していき、ツリー構造で表す手法。プロジェクト全体の規模や完成に必要な工数、コストを正確に把握するために使う。Work Breakdown Structureの略。
WBSの最大の特徴は、プロジェクトにおける成果物をまず規定することだ。成果物を作成するにはどのような作業が必要かといった観点で、作業の詳細を洗い出す。洗い出した作業をするのに必要な事前作業をさらに分析する。こうして、作業をもうこれ以上分けられないレベルまで細分化していく。この仕事の最小単位を「ワークパッケージ」と呼ぶ。WBSでは、ツリー構造の最上位にプロジェクト全体の成果物が、最下位にワークパッケージが、それぞれ位置付けられる。
続いて、ツリー構造にしたがいプロジェクトの作業スケジュールを作成。それぞれのワークパッケージの作業責任者や担当者を決める。ここまでやると、プロジェクトの体制図が完成する。これをOBS（Organization Breakdown Structure）という。
WBSとともに用いるものとして、WBSディクショナリがある。WBSディクショナリは成果物の作成開始日や作成完了日、予想作成個数、予想平均工数、作成責任者などを記述する。成果物の作成個数と平均工数の積を算出することで、プロジェクトの総工数とコストを算出できる。
WBSは特にここ最近、プロジェクトマネジメントにおける作業工数の見積もりで利用される機会が増えてきた。例えば、モダン・プロジェクトマネジメント体系の標準である「PMBOK（ピンボック）」では、全作業項目を洗い出すための手法としてWBSを使う。
WBSが注目される背景には、システム開発プロジェクトにおいて開発工数の正確な見積もりがより求められるようになってきたことがある。作業工数の実績が事前の見積もりを大幅に超えてしまっては、プロジェクトは完了時期が延びたり、費用が超過したりする。失敗プロジェクトと言われるものは、こうした工数の見積もりの誤りに端を発することが多い。WBSはプロジェクトの規模のあいまい性をできる限り排除するための手法として有益と言える。
それだけに、WBSの内容は慎重なチェックが必要だ。WBSの分解方法は妥当か、あるレベルのWBSをすべて達成したら、上位のWBSの目標を達成できるか、WBSで規定した成果物に漏れや重複、矛盾がないか、投下する人員やコスト、設備、技術などは妥当か、関連する他のプロジェクトとの整合性はあるか、などの精査が欠かせない。こうした点に誤りがあると、結局WBSの精度は下がってしまう。ひいてはプロジェクトの失敗につながる。
最近では、システム開発プロジェクト以外でもWBSを利用する動きがある。例えば、運用サービス全体のコスト構造を明確にするためにWBSを導入するといったケースがそれだ。
