建設契約の種類は、請負者への支払い方法だけでなく、コスト管理のあり方そのものを大きく左右します。
契約は、誰が設計リスクを負うのか、誰がコストリスクを負うのか、変更をどのように管理するのか、出来高をどのように認定するのか、そして最終的に請負者がコスト超過にどれだけさらされるのかを定めます。
これは特に、大規模なEPC、ランプサム、ターンキー、BOT、PPPプロジェクトで重要になります。発注者が提示する商務上の構成には、実際の建設コストを管理するのに十分な詳細が含まれていない場合があるためです。
重要な原則はシンプルです。
請負者が支払いを受ける単位は、必ずしも請負者がコストを管理すべき単位ではありません。
したがって大手請負者にとって、契約上の数量明細書（Bill of Quantities：BoQ）はプロジェクト管理の一つの側面にすぎません。
真の建設コスト管理には、BoQ、作業分解構成（WBS）、Cost Codes、そして実際の現場実行を結び付けることが必要です。
そこで建設業に特化したERPが決定的な役割を果たします。
まず、FIDIC・EPC・ランプサム・BOT・PPPは同じものではありません
これらの用語はしばしば一緒に使われますが、プロジェクト遂行の異なる側面を表しています。
- FIDICは、建設・エンジニアリング契約の標準約款を提供しています。
- EPC（Engineering, Procurement and Construction：設計・調達・建設）は、請負者が設計、調達、建設の責任を負うプロジェクト遂行モデルです。
- ランプサム（Lump Sum：LS）は主に価格の取り決めを指し、請負者は合意した価格で定められた範囲の業務を完了することに同意します。ただし、変更やその他の調整に関する契約条項が適用されます。
- BOT（Build-Operate-Transfer：建設・運営・譲渡）は、建設と、民間事業者が資産を運営した後に譲渡するまでのコンセッション期間を組み合わせたものです。
- PPP（Public-Private Partnership：官民連携）はさらに広い概念で、通常は設計、建設、資金調達、運営、維持管理の組み合わせを対象とした、公共部門と民間部門の長期的な契約関係を伴います。
これらの構成は重なり合うことがあります。
たとえばEPCプロジェクトは、FIDICシルバーブックを用いたランプサム・ターンキー契約として実施されることがあります。
コスト管理の観点から重要なのは、商務、設計、建設、性能に関するリスクがどれだけ請負者に移転されるかです。
リスクが大きいほど、社内でのコストの粒度を細かくする必要性が高まります。
FIDICのレッド、イエロー、シルバー：異なるリスク配分
FIDICレッドブックでは、従来、発注者が設計の大部分を担い、請負者が建設工事を実施します。
これにより、一般に設計、数量、計測、出来高、支払いの間に比較的直接的な関係が生まれます。
- FIDICイエローブックでは、より多くの設計責任が請負者に移ります。請負者は、設計、調達、建設、工期、コストを相互に関連するプロセスとして管理することがますます求められます。
- EPC／ターンキー方式と結び付けられることの多いFIDICシルバーブックでは、請負者にはるかに大きな責任が移転されます。
発注者は事実上、成果を購入しているのです。
合意した要求事項、価格、完成義務に従って、必要な施設、プラント、インフラ資産を引き渡すこと。
しかし請負者にとって、その成果を実現するには、数万件に及ぶ作業、リソース、発注書、資材の移動、労務取引、機械稼働時間、協力会社の作業が関わる場合があります。
これがコスト管理上の大きな課題を生みます。
EPCのパラドックス：シンプルな契約価格の裏に膨大な施工の複雑さが隠れている
次のような項目を含む、簡略化されたEPCのBoQを考えてみましょう。
構造工事 — 1,200万ドル
発注者の商務的な観点からは、これで十分かもしれません。
しかし請負者のコスト管理の観点からは、ほとんど意味をなしません。
その1,200万ドルには、次のようなものが含まれている可能性があります。
掘削、排水、鉄筋、コンクリート、型枠、鉄骨、労務、クレーン、ポンプ、仮設工事、消耗品、物流、資材ロス、専門協力会社、間接リソース。
元のBoQがこのレベルのエンジニアリング分析を提供していない場合でも、請負者は詳細の欠如をそのまま受け入れるわけにはいきません。
請負者は、その粒度を社内で作り出さなければなりません。
ここでCost Codesが戦略的に重要になります。
Cost Codesは第一段階の概算予算になり得ます
ProjectVIEW ERPは、相互に結び付いた3つのプロジェクト軸を通じて建設コスト管理に取り組みます。
BoQ ↔ WBS ↔ Cost Codes
- BoQは商務の軸を表します。発注者が何を購入し、請負者が最終的に何を販売するのかです。
- WBSは実行と時間の軸を表します。作業をどこで、いつ、どの順序で行うべきかです。
- Cost Code（コスト管理勘定）は社内のコスト管理の軸を表します。請負者が支出をどのように分類し、監視するかです。
ProjectVIEWは、BoQ予算へのCost Codesの割り当てと、BoQ予算とプロジェクト工程計画の構造との関連付けをサポートします。
そのため、EPCのBoQに十分なエンジニアリングの詳細がない場合でも、Cost Codesによってプロジェクト予算の最初の社内概算分解を行うことができます。
「構造工事」のような上位レベルのBoQ項目は、社内で土工、コンクリート、鉄筋、型枠、鉄骨、労務、機械、協力会社といったコスト区分に配分できます。
請負者は、プロジェクトを社内でどう管理するかを決める際に、もはや発注者の商務構成に依存する必要はありません。
WBSはBoQにない軸、すなわち「時間」を加えます
Cost Codesが答えるのは、
どのような種類のコストが発生しているのか？
WBSが答えるのは、
どこで、いつ作業を行っているのか？
ProjectVIEWの入札・予算編成の手法では、リソース、生産性の前提、期間をBoQの構造やプロジェクト計画と関連付けることができます。
これにより、同じプロジェクトについて、異なるが相互に結び付いた3つのビューが生まれます。
BoQ ＝ 商務
WBS ＝ 時間と実行
Cost Codes ＝ コスト分類
これら3つの軸を結び付けることで、プロジェクトの初期コスト管理の枠組みが確立されます。
しかし、本当のインテリジェンスは施工が始まったときに生まれます。
現場の実行が、不足していたエンジニアリングの詳細を生み出します
予算は仮定です。
施工は現実です。
建設現場では毎日、当初の予算を段階的に充実させる情報が生まれています。
どれだけの作業が完了したか？
何時間の労務が必要だったか？
どれだけの資材が消費されたか？
クレーン、掘削機、その他の機械は何時間稼働したか？
協力会社の作業はどれだけ実施され、認定されたか？
その物理的な出来高には本来いくらかかるはずだったか？
そして実際にはいくらかかったか？
ProjectVIEWのコスト管理手法は、プロジェクトの出来高、従業員の取引、機械の取引を含む日々の取引を取り込み、それらを用いてプロジェクトの実際のコスト像を構築します。
さらに広い建設管理モデルでは、資材、協力会社の出来高認定、労務生産性、機械稼働率をBoQ–WBS–Cost Codeの関係と結び付けます。
ここで、比較的概算的なEPC予算が詳細なエンジニアリング・コストモデルへと変わり始めます。
概算予算から下位レベルのコスト分析へ
入札段階では、請負者は次のような構成から始めることがあります。
BoQ → Cost Code
プロジェクト計画の段階では、これが次のようになります。
BoQ → Cost Code → WBS
施工中には、さらに発展します。
BoQ → Cost Code → WBS → リソース → 日々の取引
当初の上位レベルの予算は、段階的に下位レベルの業務上の詳細を獲得していきます。
構造工事の予算は、最終的には特定のWBS作業、コスト区分、作業班、資材消費、機械稼働、協力会社の出来高認定、物理的出来高の取引まで分析できるようになります。
構造工事が予算超過していると知るだけでなく、経営陣は次のような問いを立てられるようになります。
どの作業か？
どのCost Codeか？
どのリソースか？
どの作業班か？
どの協力会社か？
どの資材か？
どの機械か？
どの日か？
これは根本的に異なるレベルのコスト管理です。
日々の作業指示：建設コストの外科的な解剖
プロジェクトは、実際には月次の財務報告によってつくられるわけではありません。
日々の作業によってつくられます。
したがって、建設コスト管理の究極のレベルとは、業務上の取引をプロジェクトの商務、工程、コストの各構造と関連付けられる能力です。
日々の作業取引は、次の問いに答えるべきです。
何をつくっているのか？ — BoQ
どこでつくっているのか？ — WBS
どの支出区分に該当するのか？ — Cost Code
誰が作業を行ったのか？ — 労務または協力会社
何を消費したのか？ — 資材
どの機械が必要だったのか？ — 機械
どれだけの出来高を達成したのか？ — 物理的出来高
その出来高には本来いくらかかるはずだったのか？ — 予算
実際にはいくらかかったのか？ — 実績コスト
これが、私たちの言う建設プロジェクトの外科的な解剖です。
ProjectVIEWは同じ考え方を調達にも広げています。資材調達や倉庫のプロセスをBoQ、WBS、Cost Codesと関連付けることで、購買要求から発注、現場での消費に至るまで、支出をプロジェクト上の目的と結び付けたまま管理できます。
協力会社の契約や出来高認定にもCost Codesを付与でき、外注作業を同じコスト管理構造に取り込むことができます。
BoQは「生きた」コスト構造になるべきです
入札時に受け取ったBoQを、実行から切り離された静的なExcel文書のままにしておくべきではありません。
ProjectVIEWはExcelのBoQを取り込み、BoQコード行の階層構造に変換できます。その後、積算の過程で資材、労務、機械、協力会社をそれらの行に関連付けることができます。
施工が始まると、現実が当初のモデルを充実させていきます。
デジタルの進化は次のようになります。
入札時のBoQ
→ Cost Code付き予算
→ WBSと連動したプロジェクト・ベースライン
→ リソース予算
→ 日々の現場取引
→ 実績コストと予算の比較
→ 生産性とリソースの差異
→ 経営による対応
これにより、建設業で最も根強い情報ギャップの一つが解消されます。
それは、施工に本来いくらかかるべきかを見積もることと、実際にいくらかかっているかを把握することとのギャップです。
EPCやランプサムのプロジェクトで、これがさらに重要になる理由
財務上の影響は、EPC契約やランプサム契約のもとで特に大きくなります。
ある請負者が次のような状況にあると想定してください。
契約収益：5億ドル
予算コスト：4億5,000万ドル
見込み利益：5,000万ドル
実行コストが最終的に4億8,500万ドルになった場合、追加の3,500万ドルは、発注者のBoQに十分な詳細がなかったからといって消えるわけではありません。
それは請負者の利益から直接差し引かれます。
したがって、建設コスト管理の目的は、超過を事後に報告することだけであってはなりません。
目的は、経営陣がまだ介入できるうちに差異を特定することでなければなりません。
つまり、次の項目を継続的に比較することです。
労務生産性の予算と実績
資材消費の予算と実績
機械稼働の計画と実績
協力会社コストの予算と認定額
物理的出来高の計画と実績
プロジェクトコストの予算と実績
ProjectVIEWのコスト管理モデルは、会計が問題発生の最初のシグナルになるのを待つのではなく、現場の取引を取り込み、実行状況をプロジェクトのベースラインと比較します。
従来のコスト報告から「量子的」コスト管理へ
従来の財務ERPは、次の問いに答えることを得意としています。
いくら使ったのか？
建設のコストエンジニアリングは、それよりはるかに踏み込む必要があります。
いくら使ったのか、どこで使ったのか、どのリソースが消費したのか、どのような物理的出来高を生んだのか、その出来高には本来いくらかかるべきだったのか、なぜ差異があるのか、そしてまだ何ができるのか？
次の軸を結び付け、
BoQ ↔ WBS ↔ Cost Codes
その構造に次の情報を継続的に取り込むことで、
労務 ↔ 資材 ↔ 機械 ↔ 協力会社 ↔ 出来高
ProjectVIEW ERPはプロジェクトの実績を、より小さな測定可能な単位へと段階的に分解します。
これが、私たちが「量子的」コスト管理と呼ぶものです。プロジェクトのコストと実績を、ますます細かな業務要素へと継続的に分解し、差異が発生した場所と時点により近いところで特定できるようにします。
月末になってコンクリート工事の予算超過に気づくのではなく、経営陣はその根本にある業務上の原因まで掘り下げられるべきです。
それが、コスト超過を報告することと、それを管理することの違いです。
本当のデジタルスレッド：入札から施工まで
多くの大手請負者は、いまだに分断されたテクノロジー層で業務を行っています。
あるシステムが積算を担当します。
Primaveraが工程計画を担当します。
別のプラットフォームが現場の作業を管理します。
調達は全社ERPで運用されます。
協力会社の情報は別の場所にあります。
会計は財務取引を記録します。
そしてExcelがすべてを突き合わせようとします。
その結果はデジタルトランスフォーメーションではありません。
デジタルの分断です。
ProjectVIEW ERPは異なるアプローチを取り、次のプロセスをつなぐ建設業特化の統合基盤を構築します。
入札 → 予算編成 → 計画 → 調達 → 現場実行 → 協力会社 → コスト管理
発注者のBoQは商務上の出発点になります。
Cost Codesは請負者の社内コスト構造を提供します。
WBSは工程と実行を加えます。
調達は予算を消化します。
現場の取引は現実を記録します。
協力会社の出来高認定は外部の生産を記録します。
出来高は実際に何がつくられたかを測定します。
そして得られた情報が、プロジェクトのコスト管理に継続的に反映されます。
ProjectVIEWのアーキテクチャは、BoQ、WBS、Cost Codesという共通の軸を中心に、積算、調達、協力会社、現場業務、コスト管理をつなぐよう特別に設計されています。
目的は、ダッシュボードをもう一つ増やすことではありません。
建設業のためのデジタルなコスト管理基盤です。
EPCでは、契約価格は始まりにすぎません
FIDIC、EPC、ランプサム、BOT、PPPの各方式は、責任とリスクをそれぞれ異なる形で配分します。
しかし、より多くのリスクが請負者に移るにつれて、ある原則がますます重要になります。
商務上の単純さを、業務上の単純さと決して混同してはなりません。
EPC請負者は、比較的上位レベルの契約BoQを受け取ることがあります。
だからといって、きめ細かなコスト管理が不可能になるわけではありません。
むしろ、きめ細かなコスト管理がより重要になるのです。
ProjectVIEW ERPは、Cost Codesを第一段階の概算予算要素として用い、それを契約上のBoQ項目および時間軸を持つWBS作業と結び付け、さらにこの構造を実際の施工データで段階的に充実させることで、この課題に対応します。
労務生産性。
資材の活用。
機械稼働。
調達。
協力会社の出来高認定。
物理的出来高。
日々の現場取引。
プロジェクトは、次のように段階的に進化させることができます。
契約 → BoQ → Cost Code → WBS → リソース → 日々の実行 → 実績コスト
そしてここに、建設業特化型ERPが汎用の財務ERPと根本的に異なる点があります。
会計は、お金がどこへ行ったかを教えてくれます。
建設のコストエンジニアリングは、なぜそこへ行ったのかを、手を打てるだけの早い段階で教えてくれなければなりません。
大きな実行リスクを負うEPC請負者やランプサム請負者にとって、この違いが最終的にプロジェクト利益を守れるか、それとも利益が消えた理由を説明する羽目になるかを左右し得るのです。
