数量明細書（BoQ）、作業分解構成（WBS）、コストコードは、同じものを表しているわけではありません。
- BoQは、計測可能で商業的なスコープを表します。
- WBSは、作業をどのように、いつ実行するかを表します。
- コストコードは、請負業者が資源と支出をどのように分類し、管理するかを表します。
複雑な請負業者にとって、目的はこれらの次元を一つの階層に押し込めることではありません。むしろ、それらの間にガバナンスされた関係を確立することです。その結果、経営は物理的スコープ、スケジュール、資源、コスト、コミットメント、進捗、財務成果を同じプロジェクト・ベースラインに遡って追跡できます。
要するに、それが統合プロジェクト管理の基盤です。
なぜプロジェクトには3つの構造が必要なのか？
実務では、人はプロジェクトをいくつかの正当な視点から見ます。
- 顧客はこう尋ねます。どれだけの数量を納品し、いくら請求できますか？
- 計画担当者はこう尋ねます。今、どの作業が実行されているべきですか？
- 原価管理担当者はこう尋ねます。どの予算とコストコードで支出を計上すべきですか？
- 現場責任者はこう尋ねます。本日の進捗を達成するために、どれだけの資源を消費しましたか？
- 最後に、財務はこう尋ねます。この結果生じた仕訳はどこに計上すべきですか？
もちろん、これらの質問のどれも間違ってはいません。
問題は、1つの構造でそれらすべてに答えられると考えることです。
私たちは皆、次の点では一致しています。WBSだけではプロジェクトの原価管理には不十分です
したがって、次の問いはこうなります。WBSは何と接続されるべきか？
多くの請負業者環境では、その答えは3つの次元から始まります。
BoQ ↔ WBS ↔ 原価コード
BoQは何を管理するのか？
数量明細書（BoQ）は、何よりもまず、スコープを数量化し商業的に表現したものです。
それは次の問いに答えます。
- 何を納品するのか？
- どれだけ納品するのか？
- その作業はどのように計測され、評価されるのか？
BoQの1行には次のような内容が含まれます。
- 記述;
- 計量単位;
- 数量;
- 単価;
- 金額;
- 商業上または契約上の分類。
ただし、見積段階ではBoQははるかに強力になります。それは、見積担当者が各計測項目を、それを生み出すために必要な資源へと分解するときに起こります。
たとえば:
1 m³の鉄筋コンクリート
には、次のものが必要になる場合があります。
- 定義された職種にまたがるX時間の労務;
- Yトンの鉄筋;
- Z m³のレディーミクストコンクリート;
- 定義された型枠数量;
- 機械稼働時間;
- 下請け資源。
DANAOS Projects には、BoQ中心の見積モデルがあり、現場で検証されたコストレシピと生産性テンプレートを、実際の建設現場データに基づいて活用しています。
したがってBoQは、スケジュールだけでは答えられない経済的な問いに答えます。
これらの資源は、どの計測可能な成果を生み出すべきなのか？
WBSは何を管理するのか？
作業分解構成（WBS）は、プロジェクトの実行を組織化します。
プロジェクトを、段階的に管理可能な、時間制約のある作業パッケージへと分解します。さらに、チームが作業、責任、スケジュールを整理するための構造を提供します。
それは次の問いに答えます。
- 作業はどこに属するのか？
- 実行はどのように分解されるのか？
- いつ実施されるべきか？
米国GAOはWBSを、プロジェクト作業を定義し、スケジュール、コスト、アーンド・バリュー・マネジメントの統合フレームワークを確立するための礎石と位置付けています。
米国GAO コスト見積りおよび評価ガイド
ただし、WBSとBoQは代替可能ではありません。
- 1つのBoQ項目が、複数のWBSアクティビティに寄与することがあります。
- 逆に、1つのWBSアクティビティが、複数のBoQ項目または資源タイプを消費することもあります。
したがって、関係性は次のいずれかになります。
1対1
1対多
または
多対多
プロジェクトの商業上および実行上の構造によって異なります。
このため、構造を同一にするよう無理に押し込むよりも、マッピングするほうが有効です。
コストコードは何を管理するのか？
コストコード、すなわち コスト管理勘定は、コスト分解構成（CBS）機能を構成し、社内管理の視点を提供します。
それらは次の問いに答えます。
- これはどの種類のコストか？
- どこに累積すべきか？
- 誰が責任を負うのか？
たとえば、請負業者は次のものを区別したいと考える場合があります。
- 労務;
- コンクリート;
- 鉄筋;
- 燃料;
- 重機;
- 下請;
- 仮設工事;
- 間接現場費;
- 立上げ費用;
- 間接費。
もちろん、顧客が必ずしもその構造でプロジェクトを見なければならないわけではありません。
同様に、スケジューラが必ずしもそれを使って計画しなければならないわけでもありません。
しかし、原価管理担当者とCFOはそうします。
これが、独立したプロジェクト管理システムが、実行構造とコスト構造の間の関係も維持する理由です。
独立したエンタープライズ・プロジェクト管理システムも、複数のプロジェクト構造が必要であることを認識しています。
たとえば Oracle Primavera Unifier は、WBSとCBSの両コードを含むプロジェクトコスト取引をサポートしています。その結果、同じ取引をWBSシートとコストシートの両方に集約できます。
これは、多次元のプロジェクト管理が DANAOS Projects に固有のものではないことを示す重要な証拠です。
BoQ ↔ WBS ↔ コストコード は WBS + CBS とどう違うのか？
ただし、重要なアーキテクチャ上の違いもあります。
WBS + CBS は、実行構造とコスト分類を結び付けます。それだけでは、BoQや数量化された商業スコープを第3の管理次元として導入するものではありません。
請負業者にとって、その違いは重要です。
- コスト分解構成は、管理者にコストがどこに属するかを示せます。
- 同様に、WBSは、管理者にチームがどこで、いつ作業を実行するかを示せます。
しかし、BoQまたは同等の数量化されたスコープは、別の重要な問いに答えます。
どの計測可能な成果が、どの数量で、どの商業価値で納品されるのか？
ここが、ProjectVIEW ERP のBoQ ↔ WBS ↔ コストコード アーキテクチャが異なる点です。
言い換えれば、BoQは、コストとスケジュールを計測可能な物理的成果に結び付けるために必要な数量および商業的次元を追加します。
これにより、次のような問いに答えられます。
- このWBSアクティビティは、どれだけの数量を納品すべきか？
- 見積は、成果1単位あたりにどの資源を予算化したか？
- 実際には、どれだけの数量が完了したか？
- それを達成するために、作業班はどの資源を消費したか？
- その結果の実際の単価はいくらか？
- 残りの材料を、調達はどれだけ確保する必要があるか？
- では、請負業者はどれだけの数量を証明または請求できるのか？
- 残数量は、完工までのコストにどう影響するのか？
要するに、違いは次のとおりです。
WBS + CBS = 作業はどこにあり、コストはどこに属するのか？
BoQ + WBS + コストコード = 何を納品し、どこでいつ納品し、それはいくらかかるのか？
物理数量、商業評価、資源生産性が管理の中核となるプロジェクト型産業では、BoQ次元がプロジェクト管理モデルを大きく拡張します。
BoQ × WBS × コストコード：同じプロジェクト実態の3つの次元
要約すると、DANAOS Projects のモデルは次のとおりです。
- BoQ = スコープ / 数量 / 商業次元
- WBS = 実行 / 時間次元
- コストコード = コスト分類 / 管理次元
DANAOSはこのモデルを、統合プロジェクト・パフォーマンス・ベースラインと表現しています。
ただし、価値は3つの構造を持っていることだけから生まれるのではありません。
価値はむしろ、それらの関係を維持することから生まれます。
コンクリート工種のパッケージを考えてみましょう。
- BoQにはこうあります。10,000 m³の鉄筋コンクリート
- WBSにはこうあります。Pier P05 → 基礎 → Concrete Pour 03 → 第27週
- コストコードにはこうあります。労務 / コンクリート / 鉄筋 / 型枠 / 機械
その結果、組織は次のものを結び付けられるようになります。
何が納品されているのか
と
それがどこで、いつ実行されているのか
と
それにどれだけのコストがかかるべきか
そして最終的には、
実際にどの資源が消費されたのか
3つの構造をつなぐと、何が可能になるのか？
1. コスト配賦付きスケジューリング
まず、計画担当者は、関連するWBSアクティビティを通じて、計測可能なスコープの資源と予算を時間軸に展開できます。
その結果、組織は単にプロジェクトのコストだけでなく、いつ経済的なエクスポージャーが発生する可能性が高いかを把握できます。
2. 調達計画
たとえば、あるBoQ項目に500トンの鉄筋が必要で、対応するWBSアクティビティが第30週に開始するとします。その場合、調達は必要材料量を算出し、必要日から逆算できます。
これにより、購買は次のような認識から変わります。
「現場が材料を要求した。」
から、
「プロジェクト・ベースラインが、この材料需要を予測している。」
3. 生産性測定
同様に、見積が成果1単位あたりに必要な資源を定義していれば、実行時には次の比較が可能です。
- 予算数量 vs 実績数量
- 労務：予算 vs 実績
- 予算機械 vs 実績機械
- 予算単価 vs 実際単価
生産性は、単に稼働時間ではなく、成果と労力の関係になります。
4. アーンド・バリュー・マネジメント
さらに、チームは物理的進捗を、完了作業の予算価値と関連付けられます。
DANAOS Projects は、アーンド・バリューと建設パフォーマンス管理の解説で、この点をさらに検討しています。
5. 完工までの予測コスト
最後に、実際の生産性、確定コスト、残数量を同時に把握できれば、予測は過去の会計支出を単純に外挿するのではなく、実行の現実に対応できます。
構造が分断されると何が起こるのか？
実務では、その結果は通常、突合せ作業として現れます。
- 計画部門は Primavera P6 を管理します。
- 一方で、見積担当者は元のBoQと予算をExcelまたは別の見積プラットフォームに保持します。
- 調達部門は資材マスターに対して購買を管理します。
- 会計部門は財務勘定に対して支出を計上します。
- 最後に、現場チームは進捗を別個に報告します。
その結果、組織は技術的にはすべてのデータを持っています。
しかし、データ間の因果関係は弱いままです。
そのため、経営層は次のような問いへの対応に時間を費やします。
- このコストを生んだのはどのアクティビティか？
- この購買発注は、どのBoQ数量を支えるのか？
- これらの労務時間は、どの物理的成果を生み出したのか？
- どの変更が予測増加を引き起こしたのか？
- スケジュールは70%完了なのに、資源消費はすでに85%なのはなぜか？
DANAOS Projects は、このより広範な問題を The Failure of Generalist ERPs in Capital Projectsで検討しています。
言い換えれば、問題は各個別システムが正しく機能しているかどうかではありません。
むしろ、問題はそれらが同じプロジェクト実態を記述しているかどうかです。
複数の請負業者が関与するメガプロジェクトでは、これはどのように機能するのか？
これは、オーナーまたはプログラムレベルではさらに重要になります。
たとえば、メガプロジェクトには複数の請負業者が関与し、それぞれが次のようなものを持つ場合があります。
- 独自のWBS;
- 異なる物理エリア階層;
- 独自のコストコード;
- 異なる下請構成;
- 何千もの資産と引渡し対象物;
- 物理進捗を測定するための異なる方法。
すべての請負業者が同一の実行階層を使用すると仮定するのは現実的ではありません。
したがって、解決策は必ずしも一つの巨大な共通WBSを強制することではありません。
むしろ、より強力なアプローチは、請負業者ごとの構造の上位または横断に共通の正規化次元を作ることです。
これには以下が含まれます:
- プロジェクトフェーズ;
- 専門分野;
- 作業区分;
- 物理エリア;
- システム;
- 資産;
- 成果物;
- 請負業者;
- 重み付けされた作業ステップ。
その後、オーナーは各請負業者のそれぞれのWBSに資産または成果物を関連付けられます。同時に、それらを共通のオーナー次元で分類し続けることができます。
その結果、オーナーは進捗を次の観点で分析できます。
- 請負業者
- エリア
- 専門分野
- プロジェクトフェーズ
- 作業区分
- 資産/システム
各請負業者の詳細な実行構造を維持しながら。
その結果、正規化されたSカーブ、請負業者間の進捗比較、進捗申告の監査可能な検証のための、より強固な基盤が生まれます。
要するに、原則は同じです。
あらゆる管理上の問いを単一の階層に押し込めてはならない。ガバナンスされた次元間の関係を維持せよ。
ProjectVIEW ERP はこのモデルをどのように適用するのか？
ProjectVIEW ERP は、次の明示的な関連付けを中心に構築されています。
BoQ ↔ WBS ↔ 原価コード
ProjectVIEW ERP コスト管理モジュールは、Oracle Primavera P6/MS Project 連携、資源配分、複数のBoQ/WBSバージョン、実際の現場進捗、労務、機材、下請業者活動、実績対予算コストとともに、この関係を記録します。
ProjectVIEW ERP 予算見積・入札モジュールは、数量化された資源ベースのベースラインを確立します。そのベースラインに対して、請負業者は実行を管理します。
さらに、ProjectVIEW OS for the BUILD World 全体は、この原則を構造化されたプロジェクトデータモデルへと拡張し、建設、海洋・オフショア、鉱業、造船、その他のプロジェクト主導型環境を支援することを目的としています。
ただし、目的は単に同じ取引に3つのコードを表示することではありません。
むしろ、調達、資源、下請業者、現場進捗、コミットメント、コスト、財務取引が同じプロジェクト・コンテキストを継承できるようにすることです。
このモデルは建設以外にも適用できる
用語は業界によって変わります。
- 造船所では、ジョブリスト、船舶システム、ブロック、生産作業パッケージ、修繕項目を使う場合があります。
- 同様に、海洋請負業者は、船舶、オフショア地点、浚渫数量、据付パッケージを中心に作業を整理する場合があります。
- 鉱業請負業者は、エリア、生産数量、開発作業、機材フリートを中心に実行を整理する場合があります。
- 最後に、プロジェクト型製造業では、部品表、生産指図、エンジニアリング済みアセンブリを使うことがあります。
ProjectVIEW ERP は、このモデルをこれらの異なる運用構造に適応させます。
普遍的な原則は次のとおりです。
数量化されたスコープ ↔ 実行構造 ↔ コスト構造
名称は変わるかもしれません。
しかし、それらを結び付ける必要性は変わりません。
エンタープライズ請負業者は何を検証すべきか？
実用的なプロジェクト管理アーキテクチャは、次の問いに答えられるべきです。
- すべての重要なプロジェクトコストを、スコープと実行に遡って追跡できますか？
- 必要に応じて、1つのBoQ項目を複数のWBSアクティビティにマッピングできますか？
- 同様に、1つのWBSアクティビティが複数のコストカテゴリを消費できますか？
- 実際の物理進捗を、計測可能な数量と関連付けられますか？
- 調達は、プロジェクト・ベースラインとWBSの必要日から要求を導き出せますか？
- 同様に、労務と機械の消費を、それによって生み出された成果と関連付けられますか？
- 請求書が発行される前に、コミット済みコストをスコープに紐付けて追跡できますか？
- 変更事項は、BoQ、WBS、コストコード、収益の関係を維持できますか？
- また、管理者はデータを重複させずに複数の次元でプロジェクトを分析できますか？
- 運用取引は最終的にコーポレートファイナンスと整合できますか？
システムがこれらの問いに一貫して答えられないなら、別のダッシュボードを追加しても根本問題は解決しない可能性があります。
むしろ、問題は構造的なものである可能性が高いです。
結論：階層よりも統合が重要
BoQ、WBS、コストコードは、それぞれ異なる役割を果たします。
その結果、それらを単一構造に押し込めようとすると、有用なコンテキストが失われる可能性があります。
それらを完全に分離すると、整合性の突き合わせが発生します。
したがって、より適切なアプローチはリレーショナルです。
BoQは、何をどれだけかを示します。
WBSは、どこで、いつ、どの順序で行うかを示します。
Cost Codesは、プロジェクトがどのリソースとコスト区分を消費しているかを示します。
これらの次元がつながったままであれば、請負業者は全体の流れを追跡できます。
見積 → 予算 → スケジュール → 調達 → 実行 → 進捗 → 原価 → 予測 → 財務結果
それが、BoQ ↔ WBS ↔ Cost Codesの真の価値です。
単なる3つのコードではありません。
同じプロジェクトの現実を、3つの連動した視点で捉えるものです。
