作業分解構成図（Work Breakdown Structure、WBS）はプロジェクト管理に不可欠ですが、それだけでプロジェクトのコスト管理モデルが完成するわけではありません。
建設、インフラ、造船・船舶修繕、海洋・オフショア建設、鉱業・採石、プロジェクト型製造業において信頼性の高い管理を行うには、数量化されたスコープ、Cost Codes（コストコード）、リソース、コミットメント、実際の施工・実行実績、そして財務記録も必要です。
目的はWBSを置き換えることではありません。何が計画され、何が引き渡され、何が消費され、そしてプロジェクトの最終コストが現時点でいくらと予測されるのかを説明する各要素と、WBSを結び付けることです。
WBSにできること、できないことは何ですか？
WBSは、プロジェクトを成果物、ワークパッケージ、管理可能な構成要素に分解します。計画、スケジューリング、責任分担、進捗測定、経営報告のための共通の構造を提供します。
AACE Internationalのコストエンジニアリングに関するガイダンス は、WBSをより広範なプロジェクト管理構造の一要素として位置付けています。AACEはまた、作業構造とリソース構造がどのように交差してコストセンターやCost Codesを形成するかについても説明しています。
作業分解構成図（WBS）とコスト分解構成図（CBS）の統合に関する査読付き研究 も同様に、コスト構造とスケジュール構造を単一の階層に無理に押し込むのではなく、相互に結び付けるべき理由を示しています。
これは、WBSにコストを割り当てられないという意味ではありません。割り当てることは可能です。
つまり、WBSだけでは本質的に次の事項を定義できないということです。
- 引き渡される物理的または商業的な数量
- アウトプット1単位あたりに必要なリソース
- コストを集計するために用いる社内分類
- 調達および下請契約のコミットメント
- 実際のリソース消費量と生産性
- 変更がコスト、収益、スケジュールに及ぼす影響
WBSが経営陣に示すのは、その作業がどこに属するかです。
完全なプロジェクトのコスト管理では、さらにどれだけのアウトプットが対象となるのか、そのアウトプットが何を消費すべきか、実際に何を消費したか、そして何が残っているかを説明する必要があります。
どのプロジェクト管理の要素を結び付ける必要がありますか？
DANAOS Projectsは以前、統合されたプロジェクト・パフォーマンス・ベースラインが建設においてスコープ、時間、リソース、コストをどのように整合させるかを考察しました。
同じ管理原則は、複雑なプロジェクト主導型の業界全般に当てはまります。
主な要素は次のとおりです。
- 数量化されたスコープまたは商業構造：何を、どれだけの測定可能な数量で、どのような契約構造または生産構造のもとで引き渡すのか？
- WBSとスケジュール：どの作業を実施する必要があり、それはどこに属し、いつ行うべきか？
- Cost Codesまたはコスト分解構成図：労務、資材、機械、下請業者、間接費をどのように分類し、管理すべきか？
- リソースモデル：各単位またはワークパッケージは何を消費すべきか？
- コミットメントと実績：何が発注、契約、受領、使用、完了され、財務上計上されたか？
これらの構造は競合すべきものではありません。同じプロジェクトの実態について、それぞれ異なる問いに答えるものです。
なぜ物理的な数量が重要なのですか？
あるワークパッケージが進捗率60%と報告しているとします。
ベースライン数量が10,000単位であれば、報告された進捗はおよそ6,000単位の完了に相当するはずです。
しかし、プロジェクトがすでに7,500単位を生産するために予算化された労務、資材、機械、または下請作業量を消費しているとします。
スケジュール上は依然として進捗率60%と表示されているかもしれません。
元帳は支出を正しく示しているかもしれません。
しかし、いずれの記録も単独では、7,500単位相当のリソースでなぜ6,000単位しか生産できなかったのかを説明できません。
これは生産性とプロジェクトのコスト管理に関する問題です。
この問いに答えるには、物理的なアウトプット、リソース投入量、時間、コストが結び付いた状態を保つ必要があります。
だからこそ、建設プロジェクトやEPC（設計・調達・建設）プロジェクトではBoQ中心の積算が重要になります。積算は、契約締結後に静的な入札用スプレッドシートになってしまうのではなく、測定可能な各項目の背後にあるリソースの前提条件を保持し続けるべきです。
他のプロジェクト型業界では、数量化された構造はJob List、ワークパッケージ、部品表、製造指図、あるいはその他のスコープモデルと呼ばれることがあります。
用語は変わります。
しかし、測定可能なアウトプットが必要であることは変わりません。
この原則は建設以外にも当てはまりますか？
はい。プロジェクト主導型の各業界は、アウトプット、手法、運用環境が異なっていても、共通の管理の中核を共有しています。
建設・インフラでは、アウトプットはコンクリートの立方メートル、鉄筋のトン数、配管のメートル数、または完成したシステムなどです。コスト要因には、労務、資材、建設機械、下請業者、現場の間接費が含まれます。
造船・船舶修繕では、アウトプットは船体ブロック、システム、Job Listの項目、修繕パッケージ、艤装作業などです。プロジェクトのコスト管理では、造船所の労務、資材、工場、ドック、機械、下請業者を船舶の引渡計画と関連付ける必要があります。
海洋・オフショア建設では、実行には浚渫数量、海底設置、製作パッケージ、作業船、乗組員、特殊機材、燃料、そして天候に左右される作業区画などが関わります。
鉱業・採石では、経営陣は運搬トン数、掘削メートル数、生産量、機械稼働時間、労務、燃料、保守、資材、請負業者のコストを関連付ける必要があるかもしれません。
プロジェクト型製造業では、管理モデルがプロジェクトのスコープを部品表、工程手順、製造指図、機械稼働時間、工場の労務、納期マイルストーンと結び付けることがあります。
物理的な単位は変わります。
しかし、管理における根本的な問いは変わりません。
プロジェクトは何を生み出したのか、そのアウトプットは何を消費すべきだったのか、実際に何を消費したのか、そして残りの作業にはいくらかかるのか？
なぜ会計だけでは不十分なのですか？
会計は不可欠ですが、財務上の計上と現場レベルのプロジェクト管理は異なる問いに答えるものです。
発注書は、請求書が届く前にコミットメントコストを発生させます。
資材は受領済みでも、まだ消費されていない場合があります。
労務の生産性は、給与計算の締めより前に低下することがあります。
作業がスケジュールより遅れている間に、機械や作業船の待機時間が積み重なることがあります。
下請業者は、出来高の査定や財務上の計上より前に、測定可能な作業を完了していることがあります。
したがって、現場レベルのプロジェクト管理では、財務記録を進捗、リソース消費、コミットメント、そして完成までの予測コストと併せて解釈する必要があります。
DANAOS Projectsによる統合型コスト管理モジュールアーキテクチャの分析では、積算、調達、資材、労務、機械、下請業者、プロジェクト実行、財務が、それぞれ異なる根拠を同じコストの全体像にどのように提供するかを説明しています。
会計は、財務上すでに認識されたものを説明します。
現場レベルのプロジェクト管理は、さらに今何が起きているのか、そして次に何が起こりそうかを明らかにしなければなりません。
ProjectVIEW ERPはこの課題にどのように取り組んでいますか？
ProjectVIEW ERPは、次の関連付けを中心に設計されています。
BoQまたは数量化されたスコープ ↔ WBS ↔ Cost Codes
- 数量化されたプロジェクト予算が、作業が何を消費すべきかを定めます。
- WBSが実行と時間を体系化します。
- Cost Codesが社内のコスト管理構造を提供します。
- 調達がコミットメントを確定します。
- 現場、造船所、船舶、鉱山、または生産の各トランザクションが実際の実行データを提供します。
- 会計が財務上の結果を記録します。
ProjectVIEW ERPのコスト管理モジュールは、プロジェクトのベースラインを、労務、資材、機械・建設機械、下請業者、プロジェクトのトランザクションを含む実際の進捗およびリソース情報と結び付けます。
ProjectVIEW ERP 予算積算・入札モジュールは、プロジェクト管理の出発点となるリソースベースの予算を策定します。
目的は、すべての業界に同一の用語や運用構造を使わせることではありません。
スコープ、時間、リソース、コミットメント、実際の実行、コスト、収益を、統制された単一のプロジェクトモデルの中で関連付けられるようにすることです。
これは、プロジェクト型業界における25年以上のERPの教訓を反映したものです。プロジェクト主導型の組織は、リソースを物理的な進捗へ、そして物理的な進捗を商業的価値へと絶えず変換しています。
その業務システムは、この両方の変換を追跡できるものでなければなりません。
プロジェクトリーダーは何を問うべきですか？
「WBSはあるか？」と問うだけでなく、プロジェクトリーダーは次のように問うべきです。
- 測定可能なスコープを、WBSのワークパッケージやスケジュール上のアクティビティと関連付けられるか？
- 予算化されたリソースとCost Codesを、該当するスコープまで追跡できるか？
- 実際のアウトプットを実際のリソース消費量と比較できるか？
- コミットメントコストを、請求済みコストになる前に把握できるか？
- 変更（バリエーション）が発生しても、スコープ、数量、リソース、スケジュール、コスト、収益の関係を維持できるか？
- 経営陣がポートフォリオのKPIから、その基となる個々の業務トランザクションまでドリルダウンできるか？
- プロジェクトの業務データを全社の財務環境と照合できるか？
いくつかの答えが「いいえ」である場合、弱点はWBSそのものではないかもしれません。
それを取り巻くアーキテクチャにある可能性があります。
WBSは不可欠。統合が管理を生み出す。
作業分解構成図は、プロジェクトの作業を体系化するための骨格となります。
しかし、複雑なプロジェクトは、物理的、時間的、リソース主導、商業的、そして財務的なシステムを同時に兼ね備えています。
単一の階層で、すべての要素を完全に表現することはできません。
実践的な原則はシンプルです。
WBSを置き換えるのではなく、結び付けてください。
作業を数量化されたスコープと結び付ける。
スコープを予算化されたリソースと結び付ける。
リソースをCost Codesと結び付ける。
調達のコミットメントをプロジェクトのニーズと結び付ける。
実際の実行をベースラインと結び付ける。
業務の実態を財務報告と結び付ける。
こうしてプロジェクト主導型の組織は、作業がどこに属するかを知る段階から、その作業が何を生み出し、何を消費し、最終的にいくらのコストになるのかを理解する段階へと進むことができます。
