UAEの建設会社が複数のプロジェクトを管理するには、統合ダッシュボードだけでは不十分です。各プロジェクトの範囲、予算、工程、リソース、契約上のコミットメント、実績を結び付ける共通の業務モデルが必要です。建設ERPは、個々のプロジェクトと法人単位の管理を維持しながら、経営陣にポートフォリオ全体の可視性を提供すべきです。目的は、すべてのプロジェクトに同一の実行体制を強いることなく、購買の調整、リソースの配分、コストエクスポージャーの把握、適時の意思決定を支援することです。
ドバイで住宅開発、アブダビでインフラ工事パッケージ、シャルジャでユーティリティ工事を同時に手掛ける建設会社を考えてみましょう。
各プロジェクトには、それぞれ独自の発注者、工程計画、契約条件、実行上の優先事項があります。しかし、これらのプロジェクトは同じ調達能力、サプライヤー、機材、専門技能労働者、運転資金を奪い合う可能性があります。
ある現場にとって有益な判断が、別の現場で問題を生むことがあります。
掘削機を移動すれば緊急の需要は解決できても、別のプロジェクトが遅れるかもしれません。資材の購買を集約すれば交渉価格は改善しても、保管の必要量が増えるかもしれません。施工を加速すれば出来高は改善しても、当面の資金需要が増えるかもしれません。
私の考えでは、複数プロジェクトの建設管理は、個々のプロジェクト報告の単なる合計ではありません。
それは、プロジェクト間の関係を理解し、統制する能力です。
1. なぜUAEという状況が重要なのか
UAEにおける開発の規模と多様性により、これは重要な経営上の課題となっています。
2026年3月12日に公表された2025年の開発承認に関する発表において、アブダビ市町村・運輸局は、延床面積で約7,500万平方メートルに及ぶ承認を報告しました。これは開発承認であり、完成した工事や建設会社の売上高ではありません。
一方、道路交通局による2025年6月9日付のドバイメトロ・ブルーラインに関する発表では、全長30キロメートル、14駅を新設するプロジェクトが説明されています。これは、複数の拠点、インターフェース、作業パッケージを伴う交通インフラという、異なる実行環境を示しています。
これらの事例を組み合わせて、根拠のない市場規模の推計を作るべきではありません。その意義は業務面にあります。建設会社には、一貫した管理の枠組みの中で異なる種類のプロジェクトを扱えるシステムが必要です。
その枠組みは、労働者への賃金支払いプロセス、夏季の就労制限、電子インボイスの段階的導入など、UAE固有の要件にも対応しなければなりません。
求められているのは、単にUAEで利用できるERPではありません。建設会社がUAEでプロジェクトを遂行する方法に適合した業務モデルです。
2. 「単一の業務プラットフォーム」とは実際に何を意味するのか
単一の業務プラットフォームとは、巨大な一つのプロジェクトファイルを意味するものではありません。
また、すべてのユーザーがすべての子会社の財務情報にアクセスできることを意味するものでもありません。
私は、これを相互に結び付いた三つの層で定義します。
- 共通の全社基盤。リソース分類、サプライヤー情報、コストコードの規約、文書ルール、報告定義を共有します。
- 個別のプロジェクト管理。各プロジェクトは、独自の範囲、予算バージョン、工程、契約、承認限度、見通し、責任分担を保持します。
- ポートフォリオレベルの調整。権限を持つ経営陣は、リソース需要の合計、調達エクスポージャー、資金需要、プロジェクトの例外事項を確認できます。
DANAOS Insightsでは、プロジェクト型企業のためのマルチカンパニーERPにおいてこの違いを論じています。一元的な可視性は、法人単位の業務管理および財務管理と両立しなければなりません。
設計原則はシンプルです。
管理に必要な情報は標準化する。実行に必要な違いは維持する。
例えば、建築プロジェクトと道路プロジェクトは、同じ作業分解構成（WBS）や生産性の前提を用いることなく、機材コストに関する全社共通の分類を共有できます。
共通のコストコードがあるからといって、共通の生産性を当てはめてよいことにはなりません。
3. 各プロジェクトの範囲、工程、コスト構造を結び付ける
情報を統合する前に、建設会社にはプロジェクトレベルの信頼できる基盤が必要です。
DANAOSのアプローチは、次の三つを結び付けます。
BoQ ↔ WBS ↔ コストコード
- 数量明細書（BoQ）、またはそれに相当する数量化された範囲構造は、リソースとコストを分析する基準となる作業項目と数量を提供します。
- 作業分解構成（WBS）はプロジェクトの範囲を体系化します。関連するアクティビティ、依存関係、カレンダーによって実行工程が確立されます。
- コストコードは、プロジェクトコストを集計・分析するための社内分類を提供します。
この関係はBoQ、WBS、コストコード：範囲・工程・コストを結び付ける方法で説明しています。ProjectVIEW ERPは、これらの要素を互いに無関係な報告構造として扱うのではなく、関連付けるように設計されています。
複数のプロジェクトを抱える建設会社には、この原則を統制された全社マッピングによって拡張することをお勧めします。
現場の取引は、グループ報告に必要な分類を保持しつつ、対象となるプロジェクトと作業パッケージを特定すべきです。また、マッピングルールにより、関係が複数のアクティビティや報告区分にまたがる場合に、同じ数量やコストが重複して計上されることを防ぐ必要があります。
これにより建設会社は、両者のつながりを失うことなく、二つの異なる問いを立てることができます。
「この作業パッケージで何が起きているのか」
「同じ種類のエクスポージャーが、社内の他のどこに現れているのか」
詳しくは、統合されたプロジェクトパフォーマンス・ベースラインをご覧ください。
4. プロジェクトの責任を失わずに調達を一元化する
中央調達チームは、複数の現場から要求された数量の合計以上のことを把握する必要があります。
仕様、承認済みの所要量、利用可能な在庫、プロジェクトへの割り当て、必要な納期を把握すべきです。
三つのプロジェクトが類似の資材を要求している場合を考えてみましょう。
新たな発注書を発行する前に、提案される業務プロセスでは、適切な在庫がすでに存在するか、それが引き当て済みか、そして移管によって現在それを保有しているプロジェクトに支障が出ないかを確認すべきです。
そのうえで初めて、調達部門は移管、個別購入、所要量の集約のいずれにするかを判断すべきです。
DANAOS Insightsでは、プロジェクト型調達の課題においてこの手順を説明しています。公開されているワークフローは、現場の要求を予算情報、在庫状況、資材の再配分、購買と結び付けています。
管理上の要件は、プロセス全体を通じて供給先と商務上の責任を維持することです。
集約した見積依頼によってプロジェクトへの割り当てが消えてはなりません。基本契約によって納期管理がなくなってはなりません。在庫移管では、承認と評価の履歴を保持すべきです。
別々の法人間の移管も財務チームと共に設計すべきであり、倉庫間の通常の移動として自動的に処理すべきではありません。
有益な場合は購買の意思決定を一元化する。責任は、リソースを消費するプロジェクトと法人に結び付けておく。
5. 労働力と機材を、共有しつつも制約のあるリソースとして管理する
ポートフォリオのリソース計画では、「利用可能であること」と「適していること」を区別しなければなりません。
機械は物理的には利用可能でも、別のプロジェクトに確保されているかもしれません。作業班は来週空いていても、必要な専門性を持たないかもしれません。移動は技術的には可能でも、動員コストや生産の損失を考慮すると商業的に割に合わないかもしれません。
したがって私は、リソースに関する意思決定において、既存の割り当て、稼働準備状況、必要日、移動に伴う負担、そしてリソースを手放すプロジェクトへの影響を考慮することを求めます。
ProjectVIEWが公開している機械管理機能は、機械の割り当て、稼働可否、稼働率、保守関連のプロセスを対象としています。これらは、調整されたリソースモデルにとって重要なインプットです。
UAEの労働条件は計画に組み込むべきです
UAEの2026年職業性熱ストレス防止方針は、2026年6月15日から9月15日まで、午後12時30分から午後3時までの間、直射日光下および屋外での作業を禁止しています（所定の例外および保護要件があります）。
プロジェクト計画への影響は実務的なものです。カレンダー、シフトの前提、リソースの見通しには、適用される労働条件を反映させるべきです。不適切な稼働前提に基づくポートフォリオのリソース計画は、ダッシュボードがどれほど洗練されて見えても、信頼できないままです。
給与計算とプロジェクトの生産性は、異なる問いに答えます
人的資源・首長国化省（MoHRE）の賃金保護制度に関するガイダンスは、認可された金融機関を通じた賃金の支払いを定めています。
プロジェクト管理の観点からは、承認された労働時間を該当するプロジェクトとアクティビティに配賦し、そのうえで物理的な出来高と照らして評価することも求めます。
労働者に正しく賃金を支払うことと、実施した作業のコストを把握することは関連する責任ですが、同じ管理ではありません。
6. 現時点までの支出だけでなく、最終コストの見通しを比較する
プロジェクトは、予算が十分に残っていても、コスト超過に向かっていることがあります。
欠けている情報は、建設会社がすでに何を契約上確定させているか、そして残りの作業にどれだけのコストがかかると見込まれるかです。
標準的な完成時総コスト見積り（EAC）の関係式は次のとおりです。
最終コストの見通し＝現時点までの実績コスト＋残作業の完了に要する見積りコスト
1億AEDのプロジェクトの例
あるプロジェクトの承認済みコスト予算を1億AEDと仮定します。
報告日時点で、関連する未払計上を含む実績発生コストは3,500万AEDです。
残りの契約済み作業の見込みコストは、実績にすでに含まれている分を除いて4,000万AEDです。残りの未契約作業は3,000万AEDと見積もられています。
したがって、最終コストの見通しは次のとおりです。
3,500万AED＋4,000万AED＋3,000万AED＝1億500万AED
このプロジェクトの発生コストはまだ3,500万AEDにすぎませんが、見通しではすでに500万AEDの超過が示されています。
これは仮想の例であり、ProjectVIEWの顧客の実績ではありません。範囲、評価ルール、報告日が一貫していることを前提としています。
照合は極めて重要です。発注書の一部がすでにコストとして発生している場合に、当初の発注金額を実績コストに加算してはいけません。同じエクスポージャーを二重に計上することになります。
ポートフォリオ全体では、見通しの変化をその原因とあわせて確認します。数量の見直し、生産性、調達単価、追加の共通仮設費、承認済みの範囲変更などです。
予算が残っていることは、残りの作業をその範囲内で完了できる証拠にはなりません。
7. 出来高、査定、資金を区別して管理する
建設会社に必要なのは、つながった情報であり、互換的に使われる定義ではありません。
経営管理の目的では、完了として記録された作業、所定のプロセスで受け入れられた作業、支払いのために査定された作業、発行済みの請求書、回収済みの資金を明確に区別することをお勧めします。
同様に、システムは特定された変更と承認済みの変更（バリエーション）を区別すべきです。
そうしなければ、楽観的な進捗報告が確実な資金状況と誤認されたり、回収の可能性が合意済みの契約上の権利として扱われたりするおそれがあります。
業務モデルは、これらの区別を維持しながら、関連する数量、裏付け書類、契約条件、審査状況、財務取引を結び付けるべきです。
DANAOSの契約上のBoQを超えたコスト管理に関する考察では、契約上の構成が、施工で消費されるリソースを管理するには集約されすぎている場合がある理由を説明しています。
当初のベースライン、承認済みの改訂、現在の見通しを、それぞれ識別可能なビューとして維持することをお勧めします。
承認済み予算を暗黙のうちに書き換えたり、請求額がすべて回収されると想定したりすることなく、変更に伴う潜在的なエクスポージャーを記録してください。
8. PMOに例外ベースのポートフォリオビューを提供する
プロジェクトマネジメントオフィス（PMO）が、介入が必要な箇所を特定するためにすべての取引を確認する必要があってはなりません。
私は、少数の意思決定上の問いを軸にポートフォリオレビューを構成します。
- コストエクスポージャー：見通しが悪化しているプロジェクトはどれか。前回の報告日から何が変わったのか。
- 納期エクスポージャー：必要な資材、承認、リソースのうち、今後のアクティビティを脅かしているものは何か。
- リソースの競合：同じ作業班や機材が、重複する需要に対して約束されているのはどこか。
- 商務・資金エクスポージャー：注意が必要な査定、回収、保留金残高、サプライヤーへの支払いはどれか。
- データの信頼性：現場からの提出の遅れ、未解決のマッピング、未照合の取引があるプロジェクトはどれか。
各例外は、単なる色分けの指標ではなく、責任者、裏付けとなる証拠、必要な対応につながるべきです。
ERPのデモンストレーションでは、ポートフォリオビューからプロジェクト、作業パッケージ、そして基礎となる取引へと掘り下げるよう提供者に依頼してください。
DANAOSのプロジェクト管理・コスト管理の役割概要は、プロジェクトマネージャーが利用できる情報を検討するための有用な出発点です。
統合レポートが役に立つのは、その背後にあるものを経営陣が説明できる場合だけです。
9. UAEの電子インボイスへの対応を業務モデルに組み込む
電子インボイスは、プロジェクトの取引が契約主体の財務プロセスとどのようにつながっているかを検証する実務的な理由になります。
財務省が2026年5月10日に発表した電子インボイスのスケジュール改定では、特定の大企業グループに対する認定サービスプロバイダーの選任期限が2026年10月30日まで延長された一方、義務化の開始日は2027年1月1日のまま据え置かれました。この発表は、年間売上高が5,000万AEDを超える対象事業者に関するものです。
同省のUAE電子インボイスに関するガイダンスは、重要な区別も示しています。電子インボイスとは構造化された電子的な請求データであり、PDF、スキャン文書、電子メールはそれだけでは電子インボイスにはなりません。
複数のプロジェクトを抱える建設会社であれば、基礎となる取引から、請求書の作成、サービスプロバイダーとのデータ交換、ステータス管理、照合までのプロセスを検証します。
評価では、例外処理やクレジットノートを一貫して扱いながら、プロジェクトの参照情報と正しい法人情報が維持されることを確認すべきです。
「UAE対応ERP」と表示された製品が、あらゆる企業構造に対して検証済みのエンドツーエンドのソリューションを備えていると想定しないでください。適用可能性、設定、連携の準備状況を、担当する財務チームおよび導入チームと確認してください。
規制に関する記載は、2026年9月時点で確認した公式情報に基づいています。
10. ProjectVIEW ERPが業務モデルをどのように支えるか
ProjectVIEW ERPが公開しているアプローチは、BoQ ↔ WBS ↔ コストコードのアーキテクチャを通じて、プロジェクトの範囲、施工、コストの情報を結び付けます。
コスト管理モジュールは、予算、プロジェクトの進捗、リソース配分、そしてOracle Primavera P6やMicrosoft Projectを含む工程管理ツールとの連携を示しています。
調達・購買モジュールは、ソーシング、見積り、購買、関連するプロジェクト要件に対応します。
マルチカンパニー機能と組み合わせることで、これらの機能はDANAOSが想定する業務モデル、すなわちプロジェクト固有の取引が調整と管理のための共通の枠組みに集約されるモデルを支えます。
ただし、単一の業務プラットフォームだからといって、すべての専門アプリケーションを置き換える必要があるとは限りません。
DANAOSが公開しているOracleおよびSAPとのERP連携アプローチでは、ProjectVIEWが単独で、または全社ERPと並行して運用される形を説明しています。連携の範囲と責任分担は、引き続き顧客ごとに設計する必要があります。
評価では、各レコードをどのシステムが管理するか、更新をどのように交換するか、失敗した取引をどのように解決するかを明確にすべきです。
「リアルタイムの可視性」も、実際のデータ入力、承認、同期と照らして評価すべきであり、それらの代わりとして扱うべきではありません。
11. 展開を決定する前に、相互に関連する三つのプロジェクトで検証する
私が推奨する受入れシナリオでは、実行条件の異なる代表的な三つのプロジェクトを使用します。
まずプロジェクトの予算と工程から始めます。次に、共通の資材需要、競合する機材の要求、複数のプロジェクトにまたがって作業する協力会社を加えます。
そのうえで、提案されたソリューションが次のことを実行できるかを検証します。
- プロジェクトへの割り当てと納期を維持しながら購買を集約する。
- 承認、評価、責任を失うことなくリソースを移動する。
- 契約済み金額を二重計上することなく実績と見通しを更新する。
- プロジェクト別・法人別の権限を分けて維持する。
- ポートフォリオの例外を、基礎となる取引を通じて説明する。
次に、納入の遅延、数量の改訂、未承認の変更を加えます。
目的は、ソフトウェアが複数のプロジェクト名を表示できることを証明することではありません。
組織がそれぞれのプロジェクトの管理を維持しながら、それらを調整できるかどうかを確認することです。
関連する製品の範囲については、ゼネコン向け建設ERPをご覧ください
。
おわりに
UAEの建設会社のポートフォリオは、同じリソースを奪い合う、つながりのない予算の寄せ集めになってはなりません。
また、一元化によってプロジェクト間の商務上・業務上の違いが消されてもなりません。
DANAOS Projectsの見解は、効果的な複数プロジェクト管理にはプロジェクトレベルの責任を伴う共通のビジネスロジックが必要だというものです。
経営陣は、何が必要か、何が契約済みか、何が消費されたか、何が納入されたか、そして何がリスクにさらされたままかを把握できるべきです。
問うべきは、単に次のことではありません。
「当社のERPは複数のプロジェクトを管理できるか」
問うべきは次のことです。
「一つのプロジェクトについて意思決定を行う際に、それが事業の他の部分に及ぼす影響を理解し、統制できるか」
それこそが、単一の業務プラットフォームの試金石です。
