ブログに戻る
WBSプロジェクト計画建設

建設プロジェクトにおけるWBS（作業分解構成図）ガイド

·29分で読了·Goodwill of Work

WBS（Work Breakdown Structure：作業分解構成図）は、適切に管理された建設プロジェクトすべての基盤です。WBSはスコープを定義し、作業を整理し、スケジューリング、コスト管理、リソース計画、およびEVM（出来高管理）が依拠するフレームワークを提供します。不十分なWBSは、すべての後続プロセスに問題を波及させます。優れた設計のWBSは、他のすべてを容易にします。

その重要性にもかかわらず、WBSの作成は戦略的な計画活動ではなく、事務的な作業として扱われることが多いのが現状です。チームはガントチャートの作成を急ぐあまりWBS作成を急いで済ませたり、WBSを完全に省略してスケジューリングに直接取りかかったりします。その結果、管理が困難なスケジュール、実際の作業実施方法と一致しないコストレポート、そして意味のある粒度を欠いたEVM測定が生まれます。

本ガイドでは、効果的なWBS設計の原則、建設に特化した分解アプローチ、スケジューリングおよびコスト管理との統合、そしてWBSの品質を損なう一般的な間違いについて解説します。

WBSとは何か（そして何ではないか）

WBSとは、プロジェクトチームが実施すべき作業の全範囲を階層的に分解したものです。各下位レベルは、プロジェクト作業のより詳細な定義を表します。

いくつかの重要な区別があります。

WBSはスコープ指向であり、スケジュール指向ではありません。 WBSはプロジェクトが何を成果物として提供すべきかを定義するものであり、いつ、どの順序で実施するかを定義するものではありません。作業の順序付けはスケジュールの役割です。WBSは成果物を整理します。

WBSの最下位レベルの要素はワークパッケージです。 ワークパッケージとは、計画、見積、スケジューリング、追跡の対象となる最小の作業単位です。単一の責任者に割り当て可能で、合理的な確度で見積可能であり、効果的に管理できる程度に小さいものでなければなりません。

WBSはタスクリストではありません。 アクティビティ（タスク）はワークパッケージ内に存在しますが、WBS自体は成果物を整理するものであり、アクティビティを整理するものではありません。この区別は重要です。なぜなら、WBSが数百もの項目からなる扱いにくいリストになることを防ぐからです。アクティビティはスケジュールに属し、WBSはスケジュールに構造を与える組織階層を提供します。

WBSは100%ルールに従います。 WBSの各レベルは、親要素の作業の100%を網羅しなければなりません。漏れがあってはならず、二重計上もあってはなりません。レベル1の要素が「商業オフィスビル」であれば、レベル2の要素はそのビルを完成させるために必要なすべての作業を総合的に表す必要があります。

建設における分解アプローチ

建設プロジェクトは、いくつかの観点から分解できます。分解アプローチの選択は、プロジェクトの管理、報告、管理方法に影響を与えます。

成果物指向の分解

成果物指向のアプローチは、プロジェクトの物理的な構成要素によって作業を整理します。これは最も一般的であり、建設において一般的に推奨されるアプローチです。

商業ビルプロジェクトの場合、成果物指向のWBSは次のようになります。

1.0 商業オフィスビル
    1.1 敷地工事
        1.1.1 土工事
        1.1.2 ユーティリティ
        1.1.3 舗装・外構
        1.1.4 造園
    1.2 構造システム
        1.2.1 基礎
        1.2.2 鉄骨
        1.2.3 コンクリートスラブ
    1.3 建物外皮
        1.3.1 外壁
        1.3.2 屋根
        1.3.3 窓・ガラス
    1.4 内装工事
        1.4.1 間仕切り・ドライウォール
        1.4.2 天井
        1.4.3 床
        1.4.4 造作家具
    1.5 機械設備
        1.5.1 空調（HVAC）
        1.5.2 給排水
        1.5.3 消防設備
    1.6 電気設備
        1.6.1 電力配電
        1.6.2 照明
        1.6.3 弱電・通信
    1.7 コミッショニングおよび竣工
        1.7.1 システム試験
        1.7.2 パンチリスト
        1.7.3 書類整備・引渡し

成果物指向の分解の利点は、建設作業が物理的にどのように組織されているかを反映していることです。各要素は、検査、測定、追跡できる具体的なものに対応しています。また、下請契約のスコープ設定や見積データベースの構造とも自然に一致します。

場所指向の分解

繰り返し要素のあるプロジェクトや、地理的に異なるセクションを持つプロジェクトでは、場所ベースの分解が大きな管理価値を追加します。このアプローチは以下のような場合に一般的です。

  • 高層建築：フロアまたはゾーンで分解
  • インフラプログラム：区間またはステーションで分解
  • キャンパスプロジェクト：建物ごとに分解
  • パイプラインプロジェクト：スプレッドまたはセクションで分解

10階建てビルの場所指向WBSは、場所と分野を組み合わせることができます。

1.0 オフィスタワー
    1.1 ポディウム（地下2階～2階）
        1.1.1 構造
        1.1.2 MEPシステム
        1.1.3 仕上げ
    1.2 タワー（3～8階）
        1.2.1 基準階パッケージ
            1.2.1.1 構造
            1.2.1.2 MEP荒配管
            1.2.1.3 仕上げ
    1.3 上層階および屋上（9～10階＋屋上）
        1.3.1 構造
        1.3.2 MEPシステム
        1.3.3 仕上げ
        1.3.4 屋根

場所ベースの分解は、フローベースのスケジューリング（LOB：ラインオブバランスやフローライン方式など）を可能にします。これは、繰り返しのある建設においてCPMのみのアプローチよりも優れていると広く認識されつつあります。

フェーズ指向の分解

一部のプロジェクトでは、特にフェーズごとに異なる特性、資金源、または施工チームがある場合、第1レベルのフェーズ別分解が有効です。

1.0 病院増築
    1.1 フェーズ1：準備工事
    1.2 フェーズ2：新棟建設
    1.3 フェーズ3：既存棟改修
    1.4 フェーズ4：内装工事およびコミッショニング

各フェーズは、さらに成果物別または場所別に分解されます。フェーズ指向のWBSは、使用中の施設の改修、段階的なキャンパス開発、および段階的な資金調達を伴うプログラムに特に有用です。

ハイブリッドアプローチ

実際の建設プロジェクトのほとんどは、階層の異なるレベルで2つ以上の分解方法を組み合わせたハイブリッドアプローチを使用します。一般的なパターンは以下の通りです。

  • レベル1：プロジェクト
  • レベル2：フェーズまたは主要エリア（場所）
  • レベル3：分野またはシステム（成果物）
  • レベル4：ワークパッケージ

重要な原則は、各レベル内での一貫性です。レベル2が場所別に整理されている場合、すべてのレベル2要素は場所であるべきです。同じレベルで場所と分野を混在させると混乱を招き、100%ルールに違反します。

適切な詳細レベルの決定

WBS作成における最も一般的な疑問の一つは、どこまで分解すべきかということです。浅すぎると管理の可視性が不十分になります。深すぎると、管理の利点以上に維持管理の負担が大きくなります。

ワークパッケージサイズのガイドライン

分解レベルの調整に役立つ実践的な目安がいくつかあります。

  • 期間：ワークパッケージの期間は、通常1報告期間以上、2～3報告期間以内とすべきです。月次報告の場合は1～3か月、週次報告の場合は1～3週間が目安です。
  • コスト：ワークパッケージは、コスト追跡にとって意味のある大きさであると同時に、管理可能な程度に小さくあるべきです。10億円規模のプロジェクトでは、500万～5,000万円程度のワークパッケージが適切な場合が多いです。
  • 責任：ワークパッケージは、単一の責任者（個人、作業班、または下請業者）に割り当て可能であるべきです。複数の責任者間の調整が必要な場合、さらなる分解が必要かもしれません。
  • 測定可能性：ワークパッケージには、完了の定義が明確でなければなりません。そのワークパッケージ内の進捗測定方法を定義できない場合、それは曖昧すぎるか大きすぎるかのどちらかです。

「8/80ルール」

広く引用されるヒューリスティックとして、ワークパッケージには8時間以上80時間以下の工数を必要とすべきという目安があります。このルールは、労働時間が主要な測定単位であるプロジェクトマネジメントの文脈で生まれました。複数の工種にまたがる数週間の作業を表すワークパッケージが多い建設分野では、このルールはより緩やかに適用されます。ただし、基本的な原則は変わりません。ワークパッケージは些細すぎず、管理不能なほど大きくあるべきではありません。

段階的詳細化

プロジェクト開始時にWBSのすべての部分が同じ詳細レベルである必要はありません。近い将来に実施される作業はワークパッケージレベルまで分解すべきです。後のフェーズに計画されている作業は、より高いレベルに留め、プロジェクトが進行して情報が得られるにつれて段階的に分解できます。

このアプローチは、ローリングウェーブWBSと呼ばれることがあります。建設プロジェクトは不完全な設計情報で開始されることが多く、数か月先まで着手しない作業の詳細な分解を強制することは、無駄であり、やり直しが必要になる可能性が高いことを認識したアプローチです。

番号付けおよびコーディングシステム

一貫した番号付けシステムは、トレーサビリティと他のプロジェクトシステムとの統合に不可欠です。

WBS番号付け

WBS構造を反映した階層的な番号付け体系を使用します。

  • レベル1：1.0
  • レベル2：1.1、1.2、1.3
  • レベル3：1.1.1、1.1.2、1.1.3
  • レベル4：1.1.1.1、1.1.1.2

コストコードとの整合

WBSは、プロジェクトのコストコーディング体系と整合すべきですが、必ずしも同一である必要はありません。多くの建設企業は、CSI MasterFormatやUniFormatなどの標準化されたコストコードシステムを使用しています。WBS要素とコストコードの関係は明示的に定義すべきです。

  • 一対一マッピング：各ワークパッケージが1つのコストコードに対応。シンプルですが、硬直的になることがあります。
  • 一対多マッピング：各ワークパッケージが複数のコストコードにマッピング（例：「基礎」ワークパッケージがコンクリート、鉄筋、型枠の各コストコードを含む）。コスト分析の柔軟性が高まります。
  • クロスリファレンスマトリックス：WBS要素とコストコードの関係を定義する正式なマッピング文書。大規模プロジェクトに不可欠です。

どのアプローチを選択しても、マッピングはWBS作成時に確立すべきであり、コスト収集開始後に後付けすべきではありません。プロジェクト途中でWBSとコストコードの関係を変更すると、過去のデータが損なわれ、トレンド分析が困難になります。

WBSとスケジューリングの統合

WBSはスケジュールの組織階層を提供します。スケジュール内の各アクティビティは、WBSのワークパッケージに属すべきです。このリンケージにより、以下が可能になります。

サマリーレベルの報告

アクティビティがワークパッケージにロールアップし、ワークパッケージがWBS階層を通じてロールアップすることで、スケジュール状況をあらゆるレベルで報告できます。経営ダッシュボードではレベル2（主要プロジェクトエリア）でのスケジュール実績を表示し、週次調整会議ではレベル4（ワークパッケージ）で作業できます。

リソースの集約

アクティビティレベルで行われた作業班の割り当てや機器の配分は、WBSを通じて集約され、エリア別、分野別、フェーズ別の総リソース需要が明らかになります。この集約は、リソースの平準化やボトルネックの特定に不可欠です。

EVM（出来高管理）

WBSは、EVMが測定されるコントロールアカウントとワークパッケージを定義します。適切に構造化されたWBSがなければ、EVMデータは意味のある分析に必要な粒度を欠きます。WBSの構造により、EVMが問題の発生箇所を特定できるか、それとも問題が存在することしかわからないかが決まります。

ベースライン管理

スケジュールベースラインは通常アクティビティレベルで保存されますが、WBSレベルで分析されます。現在の状況をベースラインと比較する際、WBSレベルのロールアップにより、個々のアクティビティの遅延がエリアまたは分野全体のパフォーマンスに影響を与えているかどうかがわかります。

WBSとコスト管理の統合

WBSはコスト管理にとっても同様に重要です。

予算配分

プロジェクト予算はWBS要素全体に配分されます。親要素の下にあるすべてのワークパッケージに配分された予算の合計は、親の予算と等しくなければなりません（コストに適用される100%ルール）。これにより、詳細なコスト追跡とサマリー報告の両方をサポートする階層的なコスト構造が作成されます。

コミットメント追跡

下請契約や発注は、WBS要素を参照すべきです。これにより、プロジェクトチームはWBSの各レベルで、支出額だけでなくコミット額も確認できます。予算の20%を支出し90%をコミットしているワークパッケージと、20%を支出し25%をコミットしているワークパッケージでは、状況が大きく異なります。

変更指示管理

変更指示が承認された場合、対応する予算調整とともに特定のWBS要素に割り当てるべきです。これにより、コストベースラインの整合性が維持され、差異分析がスコープ変更ではなく真のパフォーマンスを反映します。

予測

ワークパッケージレベルでのコスト予測はWBSを通じて集約され、信頼性の高いプロジェクトレベルの完成時見積（EAC）を生み出します。ボトムアップ予測（各ワークパッケージ管理者が残コストを見積もる方式）はトップダウン方式よりも正確であり、WBSはこのボトムアッププロセスの構造を提供します。

WBS作成：ステップバイステッププロセス

ステップ1：適切なチームの編成

WBS作成は一人で行う作業ではありません。プロジェクトマネージャー、リードスケジューラー、コストエンジニア、現場監督、主要な分野リーダーを含めます。作業を管理する人々こそ、その整理方法を定義するのに最も適しています。

ステップ2：上位レベルの定義

プロジェクトをレベル1とし、レベル2の分解戦略（フェーズ別、場所別、または分野別）を決定します。レベル2の要素が相互排他的かつ網羅的であり、プロジェクトスコープの100%をカバーしていることを検証します。

ステップ3：ワークパッケージへの分解

各レベル2要素を段階的に分解し、前述のサイズガイドラインを満たすワークパッケージに到達するまで作業を進めます。測定可能性テストを適用します。各ワークパッケージの完了がどのような状態かを定義できますか。定義できない場合は、ワークパッケージを再定義するか、さらに分解します。

ステップ4：責任の割り当て

各ワークパッケージには、単一の責任者（個人または組織）を特定すべきです。これは、一つの当事者だけが作業を行うという意味ではなく、一つの当事者がワークパッケージの完了、コスト、品質について説明責任を負うという意味です。

ステップ5：コーディング体系の確立

WBSコードを割り当て、コストコードおよびスケジュールアクティビティコードへのマッピングを定義します。このマッピングをWBS辞書に記載します。

ステップ6：WBS辞書の作成

WBS辞書は、各WBS要素の説明を提供する補足文書です。ワークパッケージについて、辞書のエントリには以下を含めるべきです。

  • スコープ説明：含まれる作業と、重要な除外事項
  • 成果物：ワークパッケージの具体的なアウトプット
  • 責任者：説明責任を負う者
  • 予算：配分されたコスト
  • 期間見積：予想される期間
  • 受入基準：完了の検証方法
  • 前提条件と制約条件：主要な計画上の前提

WBS辞書は、各ワークパッケージが何を包含するかについての曖昧さを排除します。辞書がなければ、異なるチームメンバーがワークパッケージの境界について異なる解釈を持ち、ギャップや重複が生じる可能性があります。

ステップ7：レビューと検証

WBSを確定する前に、正式なレビューを実施します。

  • 完全性チェック：WBSはプロジェクトスコープの100%を網羅していますか。契約スコープ文書を確認し、すべての成果物が表現されていることを検証します。
  • 一貫性チェック：各レベル内の分解ロジックは一貫していますか。
  • サイズチェック：ワークパッケージはプロジェクトの報告および管理要件に対して適切なサイズですか。
  • ステークホルダーレビュー：主要なステークホルダー（クライアント、下請業者、設計チーム）は作業の組織化に同意していますか。

建設におけるWBSの一般的な間違い

アクティビティと成果物の混同

最も頻繁なエラーは、スコープ階層ではなくタスクリストのようなWBSを作成することです。「資材発注」「機器搬入」「クライアントとの調整」といった要素はアクティビティであり、成果物ではありません。これらはスケジュールに属し、WBSには属しません。「基礎システム」のような成果物指向の要素が正しく、「コンクリート打設」はそのワークパッケージ内のアクティビティです。

一貫性のない分解

同じWBSレベル内で分解アプローチを混在させると論理的な問題が生じます。レベル2に「構造工事」「電気工事」「フェーズ2改修」が含まれている場合、最初の2つは分野ベースですが、3つ目はフェーズベースです。この不一致により100%ルールを確実に適用することが不可能になり、報告に混乱が生じます。

過度の深さ

一部のチームはWBSを5～6レベルまで分解し、中規模プロジェクトで数千のワークパッケージを作成します。これは管理価値を超える追跡負担を生みます。ワークパッケージが1つの作業班に割り当てられ、1報告期間内に完了できるほど小さい場合、さらなる分解はオーバーヘッドを追加するだけで管理の向上にはつながりません。

不十分な深さ

逆に、一部のWBS構造は高すぎるレベルで停止し、ワークパッケージが数億円と数か月にまたがります。これらのワークパッケージは大きすぎて、意味のある進捗の可視化や問題の早期警告を提供できません。ワークパッケージが大きすぎて、問題に気づいた時にはすでに回復の時間がない場合、さらに分解する必要があります。

WBS辞書の欠如

辞書のないWBSは曖昧です。「内装仕上げ」というワークパッケージを見た2人のプロジェクトマネージャーは、天井グリッドの設置、ドアハードウェア、または最終清掃が含まれるかどうかについて非常に異なる前提を持つかもしれません。辞書はこの曖昧さを排除します。計画段階で時間を節約するために辞書を省略すると、施工段階でより大きな問題が生じます。

固定的なWBS

WBSは、特に段階的詳細化を使用する場合、プロジェクトの進行に伴って進化する「生きた文書」であるべきです。プロジェクト開始時にWBSを作成し、二度と見直さないチームは、より多くの情報が利用可能になるにつれて構造を改善する機会を逃しています。主要なフェーズ移行時の定期レビューにより、WBSを実際のプロジェクト状況に合わせて維持できます。

WBSの規格と参考文献

建設WBS作成のフレームワークを提供するいくつかの業界規格があります。

  • CSI MasterFormat：商業建設で広く使用されている分類システムであり、仕様書、コストデータ、プロジェクト情報を作業結果別に整理するための標準化された構造を提供します。
  • CSI UniFormat：作業結果ではなく、建物システムおよびアセンブリによって情報を整理します。設計の詳細がまだ定義されていない初期プロジェクトフェーズに特に有用です。
  • AACE International Recommended Practice 90R-17：建設アプリケーションを含むプロジェクトコントロールにおけるWBS作成に関する具体的なガイダンスを提供します。
  • PMI Practice Standard for Work Breakdown Structures：建設に適用可能な原則を持つ汎用的な規格です。

これらの規格は出発点と参考構造を提供します。組織の具体的なニーズ、プロジェクトタイプ、および管理プロセスに合わせて適応させるべきです。目標は規格そのものへの準拠ではなく、プロジェクトにとって効果的な管理ツールとなるWBSの開発です。

まとめ

WBSは、作成して保管するだけの計画成果物ではありません。スコープ定義をスケジューリング、コスト管理、リソース管理、パフォーマンス測定に結びつける組織フレームワークです。WBSの品質は、すべての後続管理プロセスの品質を直接的に決定します。

成果物指向、100%ルール、適切な分解深度、およびWBS辞書による正式な文書化という原則に従った、入念なWBS作成への投資は、プロジェクトライフサイクル全体を通じて大きなリターンをもたらします。最も規律あるゼネコンは、WBS作成を事務的なタスクではなく、コアコンピテンシーとして扱っています。

単一のビルプロジェクトを管理する場合でも、数十億円規模のインフラプログラムを管理する場合でも、基本は同じです。スコープを階層的に定義し、管理可能なワークパッケージに分解し、明確な責任を割り当て、その結果として得られた構造をプロジェクト管理のあらゆる側面の骨格として活用することです。

ブログに戻る