サウジアラビアのギガプロジェクト環境は、プロジェクト管理に求められる水準を一段と引き上げています。
大手コントラクターにとって、会計ERP、Oracle Primavera P6、スプレッドシート、個別の建設アプリケーションを揃えているだけでは、リアルタイムの管理は自動的には実現しません。エンタープライズ規模のコントラクターには、スコープ、工程、コスト、調達、協力会社、リソース、変更、そして実際の現場施工を結び付けるプロジェクト運営モデルが必要です。
目的は、起きたことを単に記録することではありません。
対応が間に合う段階で乖離を見つけることです。
DANAOS Projectsでは、まずプロジェクトの主要な管理軸を結び付けることから始めます。
BoQ ↔ WBS ↔ コストコード
そして、プロジェクトのベースラインと現場の実態を継続的に比較します。
なぜサウジアラビアではリアルタイムのプロジェクト管理が特に重要なのでしょうか？
サウジアラビアは、経済変革の新たな段階に入りつつあります。
公共投資基金（PIF）の2026〜2030年戦略は、急速な成長から持続的な価値創出への転換を掲げています。その戦略目標の中で、PIFはコスト効率の高い運営、効果的な管理、機敏な実行、そして強固なデータ基盤に支えられた高度なAIを明確に挙げています。
これはコントラクターにとって重要な意味を持ちます。
サウジアラビアのプロジェクト環境には、非常に複雑な開発案件、インフラ、産業プロジェクト、そしてPIFが支援する大規模プログラムが含まれ、多数のコントラクター、協力会社、サプライヤーが関与しています。
そのため、経営上の問いはもはや次のようなものではありません。
「必要なソフトウェアは揃っているか？」
問うべきは次の点です。
「まだ対応できるうちに、プロジェクトがどこで計画から外れているかをシステムが示してくれるか？」
そのためには、月末の財務報告をはるかに超えるものが必要です。
必要なのは、現場レベルのプロジェクト管理です。
1. コスト管理はプロジェクトのベースラインから始める
リアルタイム管理の第一の要件はダッシュボードではありません。
信頼できるベースラインです。
コントラクターにとって、プロジェクトのベースラインは次の点を明確にする必要があります。
- 何を引き渡すのか
- どれだけの数量か
- いつ施工するのか
- どのリソースを消費するのか
- それらのリソースをどう原価計算するのか
- その作業にどのような収益または商業的価値が対応するのか
DANAOS Projectsは、統合型プロジェクト・パフォーマンス・ベースラインに関する記事でこの点を取り上げています。そこではコストと工程を孤立した管理構造としてではなく、相互に結び付いたものとして扱う必要性を論じています。
ProjectVIEW ERPにおける中核的な関係は次のとおりです。
- BoQ ＝ スコープ、数量、商業的側面
- WBS ＝ 施工と時間の側面
- コストコード ＝ 社内のコスト管理の側面
ProjectVIEW ERP コスト管理モジュールは、次の関連付けを軸に設計されています。
BoQ ↔ WBS ↔ コストコード
重要なのは、すべての組織が同じ用語を使うことではありません。
重要なのは、スコープ、施工、コストが同じプロジェクトの実態を指していることです。
2. 調達はプロジェクト工程に連動させる
ギガプロジェクトにおける調達は、個々の購買依頼にその都度対応する独立した購買部門として機能すべきではありません。
調達を動かすのはプロジェクトであるべきです。
つまり、次のような問いに答えられる必要があります。
- その資材やサービスを必要とするのはどの作業パッケージか？
- 予算上の数量はいくらか？
- 工程上、いつ必要になるのか？
- 購買依頼は承認されたか？
- 見積依頼（RFQ）は発行されたか？
- サプライヤーは選定されたか？
- すでにいくら発注済みか？
- 納品はいつの予定か？
- 対応する作業の開始前に資材は到着するか？
ここでDANAOS ProjectsのBoQ中心の積算アプローチが重要になります。調達需要は最終的に、プロジェクトで見積もられ予算化された消費量から生じるべきだからです。
サウジアラビアには、さらに別の側面があります。
政府調達政策は現地調達比率（ローカルコンテント）と国内産業を重視しており、2026年8月に承認された新しい政府入札・調達法について、財務省はガバナンス、透明性、計画、実施効率を強化するものと説明しています。
したがって、サウジアラビアの大規模プログラムに携わるコントラクターにとって、調達はプロジェクト主導であり、かつ監査可能であることが求められます。
3. 請求書が届く前に発注済みコストを把握する
会計は不可欠です。
しかし、プロジェクト管理の観点から見ると、請求書は多くの場合、遅れて届くシグナルです。
請求書が届く前に何が起きているかを考えてみてください。
資材の購買依頼が承認される。
見積依頼（RFQ）が発行される。
サプライヤーが選定される。
発注書が作成される。
下請契約が締結される。
この時点で、サプライヤーの請求書がまだ経理に届いていなくても、コントラクターはすでに経済的に支払義務を負っている可能性があります。
したがって、リアルタイムのコスト管理では次を区別する必要があります。
- 予算コスト
- 発注済みコスト
- 実績コスト
- 未払計上コスト
- 完成までの予測コスト
- 完成時総コスト見込み（EAC）
そのため、DANAOS Projectsの統合型コスト管理アーキテクチャに関する記事も、本稿のサウジアラビアに特化した議論と併せてお読みください。
より適切なプロジェクト管理上の問いは、次のようなものではありません。
「いくら支出したか？」
問うべきは次の点です。
「完了済みの作業、すでに発注済みのもの、これから施工するものを踏まえると、最終的なプロジェクトコストはどこに向かっているか？」
4. 協力会社の進捗は物理的実態と商業的実態を整合させる
サウジアラビアのギガプロジェクトには、大規模な協力会社ネットワークが関与することがあります。
これは難しい管理上の課題を生みます。
協力会社は完成率を報告するかもしれません。
計画チームはWBSの作業項目に対して進捗を算出するかもしれません。
現場チームは別の物理数量を計測するかもしれません。
商務部門は異なる金額を査定するかもしれません。
経理は、出来高証明が支払対象になって初めて取引を把握するかもしれません。
これらの異なる見方は、最終的に整合しなければなりません。
各下請パッケージについて、エンタープライズのプロジェクト管理は次を関連付ける必要があります。
下請スコープ
→ WBS／作業パッケージ
→ 物理的進捗
→ 査定数量
→ 商業的価値
→ 保留金／控除
→ コスト
→ 支払
ProjectVIEW ERPの現行SaaSフレームワークには、下請契約のライフサイクル管理、進捗測定と出来高査定、変更、クレーム、保留金の追跡が含まれています。
複数のギガプロジェクト・パッケージにまたがって事業を行うコントラクターにとって、このトレーサビリティは単なる事務上の利便性ではありません。
コスト管理上の要件です。
5. 生産性は物理的出来高、リソース、時間、コストを結び付ける
プロジェクトが順調に進んでいるように見えても、利益率が静かに悪化していることがあります。
ある施工作業について、積算で1単位あたり次が必要と想定しているとします。
- X 労務時間
- Y 資材数量
- Z 機械稼働時間
同じ数量を生み出すのにプロジェクトがより多くの労務や機械を消費し始めたなら、生産性は低下しています。
それは、会計が財務上の影響を明らかにするはるか前に、現場の運営面で見えてくることがあります。
だからこそ、生産性を次だけで測るべきではありません。
作業時間
あるいは次だけで測るべきでもありません。
完成率
結び付けるべきは次のものです。
物理的出来高 ↔ 工数 ↔ リソース ↔ 時間 ↔ コスト
同じ考え方は重機にも当てはまります。
コントラクターに必要なのは、掘削機、クレーン、コンクリートポンプが8時間稼働したという事実だけではありません。
経営陣が知る必要があるのは次の点です。
- どこに配置されたか？
- どの作業を支援したか？
- どれだけの数量を生み出したか？
- 予算はいくらだったか？
- 機械は稼働していたか、遊休だったか？
これにより、リソース管理はプロジェクトのパフォーマンス管理へと変わります。
6. 変更はスコープ、工程、コスト、収益を同時に更新する
大規模プロジェクトでは変更は避けられません。
管理上の問題は、変更が発生することではありません。
問題は、同じ変更が互いに切り離された複数の「現実」を生み出すときに生じます。
設計部門がスコープを修正するかもしれません。
計画部門が工程を更新するかもしれません。
調達部門が追加資材を発注するかもしれません。
商務チームがクレームを準備するかもしれません。
コスト管理部門が予測を見直すかもしれません。
財務部門は契約上の正式な承認を待つかもしれません。
これらの事象はすべて同じ変更に関係しています。
したがって、管理された変更では次の関係を維持する必要があります。
当初スコープ
→ 変更後スコープ
→ BoQ／数量への影響
→ WBS／工程への影響
→ 必要リソース
→ コストへの影響
→ 収益／クレーム
→ 予測
ProjectVIEWのアーキテクチャは、プロジェクトのコスト管理の中で、複数のBoQおよびWBSのバージョン、クレーム、変更をサポートしています。
経営上の目標は次のとおりであるべきです。
ベースライン → 変更 → 承認 → 予測の改訂 → 商業的回収
—同じ事象を記述する5つのばらばらなスプレッドシートではなく。
7. 現場の実態を企業財務と結び付ける
サウジアラビアの大手コントラクターの多くは、すでにOracle、SAP、またはその他の全社財務ERPを運用しています。
だからといって、全社ERPを置き換える必要があるとは限りません。
より重要なのはアーキテクチャの問題です。
詳細な現場のプロジェクト実態を、プロジェクトの文脈を失わずにどう企業財務へ届けるか？
ProjectVIEW ERPは、プロジェクト中心のレイヤーとして機能し、企業内の他のシステムと連携するよう設計されています。
ProjectVIEW OS for the BUILD Worldは、このより広いコンセプトを説明しています。構造化されたプロジェクトプロセスが、経営分析、そしてますますAIに必要となる運用データ基盤を生み出すという考え方です。
したがって、実践的なエンタープライズ・アーキテクチャには次が含まれ得ます。
ProjectVIEW ERP — 詳細なプロジェクト施工とコスト管理のプロセス
Oracle Primavera P6／Microsoft Project — 詳細な計画と工程管理
BIM／IFC環境 — 物理的資産のデジタル表現
Oracle／SAP／全社ERP — 連結財務と全社プロセス
目的は、新たなソフトウェアのサイロを持ち込むことではありません。
システム間で情報が流れる際に、プロジェクトの文脈を保つことです。
なぜAIによって構造化されたプロジェクトデータがさらに重要になるのでしょうか？
サウジアラビアのPIF戦略は、高度なAIと強固なデータ基盤を明確に結び付けています。
これは建設業のデジタル化にとって重要です。
AIはパターンを特定し、情報を要約し、起こり得る結果を予測し、特定のプロセスを自動化できます。
しかし、その出力の信頼性は、基盤となるデータの品質と構造に大きく左右されます。
DANAOS Projectsはこの点を「Walk Before You Run：なぜAIの前にERPなのか」で論じています。
原則はシンプルです。
調達、コスト、工程、進捗、リソースのデータがプロジェクトごとに不統一な構造で管理されていれば、AIを追加しても根本的な管理上の問題は自動的には解決しません。
まずプロセスを構造化します。
次にプロジェクトの各軸を結び付けます。
そのうえでAIを使って、そこから知見を引き出します。
サウジアラビアのギガプロジェクトのコントラクターはERPベンダーに何を問うべきでしょうか？
エンタープライズ規模のコントラクターにとって、ERPの選定プロセスは機能チェックリストを超えるものであるべきです。
アーキテクチャが次の問いに答えられるかを確認してください。
- BoQ、WBS、コストコードはプロジェクトのライフサイクル全体を通じて関連付けられたままか？
- 実績数量を予算数量と比較できるか？
- 労務と機械の生産性を物理的出来高に対して測定できるか？
- サプライヤーの請求書が届く前に発注済みコストを把握できるか？
- 調達要件をプロジェクト工程上の必要日から導き出せるか？
- 協力会社の進捗を物理的進捗および出来高査定と整合させられるか？
- 変更によってスコープ、工程、リソース、コスト、収益を一貫して更新できるか？
- 経営陣は完成までのコストと完成時総コスト見込み（EAC）を予測できるか？
- 経営層はポートフォリオレベルのKPIから、その基となるプロジェクト取引までドリルダウンできるか？
- プロジェクトプラットフォームはPrimavera P6、BIM、全社ERPと連携できるか？
- 運用データは、信頼できる分析とAIを支えられるほど十分に構造化されているか？
複数の答えが「いいえ」であれば、問題はダッシュボードの欠如ではないかもしれません。
問題は、根本にあるプロジェクト管理のアーキテクチャかもしれません。
結論：リアルタイム管理とはプロジェクトの実態を結び付けること
サウジアラビアの建設市場の機会は非常に大きなものです。
しかし規模が大きいほど、分断された情報がもたらすコストも大きくなります。
DANAOS Projectsの考えでは、リアルタイムのプロジェクト管理は、より多くの報告書を作成することから生まれるものではありません。
それは次の要素の関係を維持することから生まれます。
- スコープ
- 数量
- WBS
- 工程
- コストコード
- リソース
- 調達
- 協力会社
- 変更
- 実際の施工
- 財務
—そして、その実態をプロジェクトのベースラインと継続的に比較することです。
サウジアラビアのギガプロジェクトのコントラクターにとって、これこそが建設ERPのより有用な定義です。
起きたことを記録するだけのソフトウェアではなく、今何が起きているのか、なぜ起きているのか、そしてそれが最終的なプロジェクトの成果に何を意味するのかを経営陣が理解するのを助けるプロジェクト運営環境。
