)){kind=icon}
)){kind=icon}
)){kind=icon}
)){kind=icon}
)){kind=icon}
)){kind=icon}
)){kind=icon}
)){kind=icon}
「プロジェクトは50%完了しています。」
一見、正確な表現に聞こえます。
しかし、建設、インフラ、EPC、造船、オフショア工事、鉱山開発、プロジェクト型製造の分野では、これは経営陣が耳にする最も曖昧な言葉の一つかもしれません。
建設分野には、単に「進捗率」と呼ばれる普遍的なパーセンテージは存在しません。
誰にとっての50%なのでしょうか？
なぜなら、一つのプロジェクトが同時に次のような状態になり得るからです。
| 測定項目 | 報告値 |
|---|---|
| 工程表上の進捗 | 50% |
| 施工済み数量に基づく進捗 | 44% |
| 労務予算の消化率 | 62% |
| 機械予算の消化率 | 57% |
| 下請業者が申告した進捗 | 48% |
| コンサルタントが認定した進捗 | 43% |
| 発注者への請求割合 | 38% |
| 現金回収の割合 | 30% |
これらの数字はすべて正しい可能性があります。
それぞれが異なる現実を測っているにすぎないのです。
だからこそ、進捗報告を建設マネジメントと混同してはなりません。
本当の問いは、次のことだけではありません。
どれだけの作業を完了したのか？
そうではなく、次のとおりです。
どれだけの作業を完了したのか、それにどれだけの時間がかかったのか、それを達成するためにどの資源を消費したのか、そして結果として生じたコストは達成された進捗に見合っていたのか？
ここで進捗測定はコスト管理になります。
そして、ここでアーンドバリューが意味を持つのです。
「50%完了」とは実際に何を意味するのか？
Oracle Primavera P6でさえ、Duration Percent Complete、Units Percent Complete、Physical Percent Complete、Performance Percent Completeなど、異なる完了指標を区別しています。そのうちPerformance Percent Completeがアーンドバリューの計算に使用されます。Oracle Primavera P6のアクティビティおよび進捗率の定義
この区別は極めて重要です。
スケジューリングアプリケーションは、選択した進捗算定方法に基づき、あるアクティビティが50%完了していると正当に報告することができます。
しかし、それによって次のことが自動的に確定するわけではありません。
- 契約数量の50%が施工されたこと
- 必要な資源の50%が消費されたこと
- 予算の50%が出来高として獲得されたこと
- 作業が計画どおりの生産性で進んでいること
- あるいは、プロジェクトが経済的に健全であること
時間は数量ではありません。
数量はコストではありません。
コストは進捗ではありません。
建設マネジメントは、これらの次元が相互に関連付けられたときに始まります。
進捗は実際に進捗が生じる場所、すなわち現場で記録すべきです
実際の建設進捗は施工から生まれます。
それは建設現場、製作ヤード、造船所、工場、鉱山、オフショア施設など、物理的な作業が行われているあらゆる場所で発生します。
したがって、進捗は実際の作業範囲に対して記録すべきです。
アクティビティの性質に応じて、次のように登録できます。
- BoQ項目に対する実際の完了数量
- WBSアクティビティに対する完了率
- BoQと関連するWBSの両方に対する測定可能な出来高
- または、数量だけでは不十分な場合にあらかじめ定めた加重完了算定方法
例はシンプルです。
- パイプライン1,000 mのうち500 m敷設済み = 物理的数量進捗50%
- コンクリート1,000 m³のうち600 m³打設済み = 60%
- 構造用鋼材500トンのうち250トン建方済み = 50%
- 機器50台のうち25台が据付・検収済み = 50%
連続した数量として合理的に測定できない作業については、あらかじめ定めた進捗マイルストーンや出来高認定ルール（Rules of Credit）によって、完了がどのように認められるかを定めることができます。
たとえばInEightは、Rules of Creditを、進捗報告が主観的な判断ではなく検証された達成内容を反映するよう、測定可能なマイルストーンに進捗を割り当てる手法として説明しています。InEight — Rules of Credit Drive Reliable Construction Budgeting
ここから第一の原則が導かれます。
進捗は、単なる経過時間ではなく、実施された測定可能な作業に基づくべきです。
しかし、正確な物理的進捗でさえ、方程式の半分にすぎません。
欠けている問い：その進捗を生み出すために何が必要だったのか？
あるパイプラインのアクティビティに次の内容が含まれているとします。
BoQ数量： 1,000メートル 実際の敷設数量： 500メートル
現場は正当に次のように報告します。
50%完了。
しかし、経営陣が知る必要があるのは、はるかに重要なことです。
その500メートルを生み出すために、私たちは何を消費したのでしょうか？
どれだけの
- 労務時間
- 機械稼働時間
- 資材
- 協力会社の資源
- 消耗品
- 間接資源
が必要だったのでしょうか？
そして、それは当初の予算と比べてどうなのでしょうか？
これが進捗の記録とプロジェクト管理の違いです。
シンプルな例が問題を示します
パイプライン1,000メートルの予算が、次の前提に基づいていたとします。
労務800時間
機械80時間
パイプ1,000メートル
さらに、関連する協力会社費用および間接費。
物理的進捗がちょうど50%の時点では、比例的な計画前提からすると、おおよそ次の量が消費されているはずです。
労務400時間
機械40時間
資材500メートル
もちろん、実際の資源投入計画と生産プロファイルによって異なります。
しかし、現場の取引記録からは次のことが分かります。
労務560時間
機械55時間
資材540メートル
が実際に消費されています。
- プロジェクトは確かに物理的には50%完了しています。
- しかし、資源面のパフォーマンスは50%ではありません。
- 労務はすでに計画労務時間の70%を消費しています。
- 機械は計画機械時間の約69%を消費しています。
- 資材消費は54%です。
こうなると「50%完了」はまったく別の意味を持ちます。数量は正しく、プロジェクトは進んでいます。
しかし、その進捗を生み出すために必要な資源が予算の前提から乖離しつつあるのです。
この乖離こそが、真のマネジメント上の問題の始まりです。
数量＋時間＋コスト：建設における現実の検証
したがって、建設における本質的な関係は、単に次のものではありません。
計画進捗 vs 実績進捗
そうではなく、次のとおりです。
達成数量 ↔ 消費時間 ↔ 消費資源 ↔ 発生コスト
それぞれが他を検証します。
数量が答えるのは：
実際に何を施工したのか？
時間が答えるのは：
どれだけの速さで生産しているのか（工数に基づく生産）？
資源が答えるのは：
それを生み出すために何を消費したのか？
コストが答えるのは：
その資源消費にどれだけの費用がかかったのか？
健全な事業運営には、これらの次元がプロジェクトの予算と工程の前提と合理的に整合し続けていることが必要です。
それが現実の検証です。
生産性は進捗と同じくらい重要です
当初予算が次の前提だったとします。
- 労務800時間で1,000メートルの作業。
したがって、予算上の生産性は次のとおりです。
- 労務1時間あたり1.25メートル。
しかし、500メートルが完了した時点で、労務時間は560時間消費されています。
実際の生産性は現在、次のとおりです。
- 労務1時間あたり0.89メートル。
- 物理的進捗は依然として50%と正確に報告されています。
しかし、労務生産性は予算の前提に対して大幅に悪化しています。
単に次のように報告する進捗ダッシュボードでは、
パイプライン敷設 — 50%完了
これを明らかにすることはできません。
パーセンテージは正しいのです。
しかし、そのパーセンテージが業務上の文脈を欠いているため、マネジメント上の結論は誤ったものになります。
だからこそ、実際の労務生産性は、資源消費を実際に生み出された作業と関連付けて算出しなければなりません。
ProjectVIEW ERPは労務生産性をBoQ/WBS構造に結び付け、実際の労務消費をそれが生み出したプロジェクト作業と比較できるようにします。DANAOSのSaaSアーキテクチャでも同様に、労務生産性はBoQ/WBSと関連付けられ、日々の機械稼働はBoQに関連付けられるものとして説明されています。
これこそがアーンドバリューが経営陣に伝えようとしていることです
プロジェクト管理のレベルでは、アーンドバリュー分析が、次の三つの基本的な次元を比較することでこの関係を体系化します。
- プランドバリュー（PV）：現時点までにどれだけの価値が完了しているべきか？
- アーンドバリュー（EV）：実際に完了した作業の予算上の価値はいくらか？
- 実コスト（AC）：完了した作業に実際にいくらかかったのか？
パイプラインのワークパッケージの完成時総予算（BAC）が$100,000だとします。
報告日時点で：
計画進捗 = 60%
したがって：
PV = $60,000
しかし、検証済みの物理的進捗は次のとおりにすぎません。
50%
したがって：
EV = $50,000
そして、実際に消費された資源によって次のコストが発生しています。
AC = $65,000
したがって、このプロジェクトは計画より遅れており、獲得した価値に対して不釣り合いに支出しています。
スケジュール効率指数（SPI）は次のとおりです。
SPI = EV / PV = 0.83
コスト効率指数（CPI）は次のとおりです。
CPI = EV / AC = 0.77
Oracle Primaveraの現行API定義でも同様に、アーンドバリューはベースライン予算にPerformance Percent Completeを乗じたもの、SPIはアーンドバリューをプランドバリューで除したものとして説明されています。Oracle Primavera P6のアーンドバリューおよびスケジュール効率の定義
だからこそ、アーンドバリューは強力なのです。
それは単に次のように問うのではありません。
「いくら支出したのか？」
こう問うのです。
「支出した金額に対して、実際にどれだけの価値を獲得したのか？」
そしてそれは、本質的に建設マネジメントの問いです。
アーンドバリューは実際の建設の現実に根ざしていなければなりません
アーンドバリューの信頼性は、それを支える進捗測定の信頼性で決まります。
もし誰かが単に次のように入力し、
50%完了
それが物理的な達成との妥当な関係を持たないままWBSアクティビティに対して記録されたなら、結果として得られるアーンドバリューの計算は、数学的には完璧でも業務上は無意味なものになり得ます。
これは重要な区別です。
システムは、何が獲得された進捗に当たるのかを把握していなければなりません。
それは次のものから得られます。
- 施工済み数量
- 完了したBoQ数量
- 検証済みのWBS進捗
- 加重ステップ
- 出来高認定ルール（Rules of Credit）
- 検収済みの生産アウトプット
- 検査済みの作業
- あるいは、その他の客観的に定義された測定方法
目的は常に同じです。
アーンドバリューは、実際に達成された作業を表していなければなりません。
楽観的な見込みではなく。
支出額でもなく。
単なる経過時間でもありません。
なぜWBSだけの進捗では不十分なのか
WBSは不可欠です。
WBSは次のものを構造化します。
- アクティビティ
- 順序
- 依存関係
- マイルストーン
- 所要期間
- プロジェクトの時間
しかし、WBSだけでは建設の経済的な現実全体を表すことはできません。
次のアクティビティを考えてみましょう。
冷水配管の敷設 — 3階
工程表で把握できるのは次のような情報です。
- 開始日
- 終了日
- 所要期間
- ロジック
- 資源割り当て
- 進捗率
しかし、商業面・業務面の管理には、はるかに多くの情報が必要です。
- そのアクティビティにはどれだけの配管数量が含まれているのか？
- どのBoQ明細行か？
- どの口径か？
- どの資材か？
- どの職種の労務か？
- どの機械か？
- どの協力会社か？
- どの予算か？
- どのコストか？
- 何が調達されたのか？
- 何が到着したのか？
- 何が消費されたのか？
- 何が検査されたのか？
- 何が認定されたのか？
- 何が支払われたのか？
WBSアクティビティが表すのは時間の実行構造です。
それはプロジェクトの商業的・財務的構造全体を自動的に表すものではありません。
だからこそ、ProjectVIEW ERPは次の関係を用いています。
BoQ ↔ WBS ↔ Cost Codes
- BoQは、測定可能かつ商業的な範囲を定めます。
- WBSは、実行と時間を定めます。
- Cost Codes（コストコード）は、資源消費に対する企業としての経済的分類を定めます。
そしてProjectVIEWは、実際のプロジェクト取引をこれらの構造に結び付けます。
DANAOSは、このアプローチを、数量化されたプロジェクト予算、WBS、調達、現場施工、会計を一つの統制されたプロジェクトモデルの中で結び付けるものとして説明しています。DANAOS — プロジェクトのコスト管理にWBSだけでは不十分な理由
WBSの進捗更新は報告です。まだコスト管理ではありません。
この区別は明確にしておく必要があります。
誰かがアクティビティを次のように更新したとき、
40% → 50%
組織は進捗を記録したことになります。
有用でしょうか？もちろんです。
必要でしょうか？はい。
建設マネジメントでしょうか？まだそうではありません。
経営陣は、同じ作業に関連する資源の投入がその進捗に見合っているかどうかを、なお判断する必要があります。
追加の10%の進捗に必要だったのが、
- 想定労務の10%、
- 想定機材の10%、
- 想定資材の10%、
そしてほぼ想定どおりの時間であれば、
業務は順調に推移していると言えるかもしれません。
しかし、同じ追加の10%の進捗に、
- 22%の追加労務、
- 18%の追加機械コスト、
- 15%の資材の過剰消費、
そして想定の2倍の期間が必要だったとすれば、
経営陣は深刻なパフォーマンス上の問題を発見したことになります。
- 工程表だけではそれを説明できません。
- 進捗率だけではそれを説明できません。
- 会計元帳だけではそれを説明できません。
それを説明できるのは、達成された作業と消費された資源との関係だけです。
これが報告と建設マネジメントの違いです
スケジューリングシステムは経営陣に次のように伝えることができます。
「このアクティビティは50%完了しています。」
建設マネジメントおよびコスト管理のシステムは、次の問いに答えなければなりません。
「その50%はどれだけの数量に相当するのか？」
「それを生み出すのにどれだけの時間がかかったのか？」
「どれだけの労務を消費したのか？」
「どれだけの機械を消費したのか？」
「どれだけの資材を消費したのか？」
「どれだけの協力会社作業を消費したのか？」
「それらの資源すべてにいくらかかったのか？」
「結果は予算と比べてどうなのか？」
「これは残りの作業にとって何を意味するのか？」
これは根本的に異なるレベルの管理です。
単独のパーセンテージは報告にすぎません。
時間、資源、コストと照合された完了作業の数量こそが建設マネジメントです。
労務時間は進捗と同じではありません
二つのプロジェクトを考えてみましょう。
どちらも次のように報告しています。
- 物理的進捗50%。
プロジェクトAが消費したのは：
- 予算労務時間の48%。
プロジェクトBが消費したのは：
- 72%.
どちらも50%完了しているからといって、経営陣は両者を同じように健全だとみなすべきでしょうか？
明らかに違います。
プロジェクトAは、おおむね計画どおりの労務生産性で推移しています。
プロジェクトBは、同じ物理的アウトプットを得るために大幅に多くの労務を投入しています。
その差は次のような要因から生じている可能性があります。
- 劣悪な現場条件
- 習熟曲線
- 作業の輻輳
- 手戻り
- 不十分な監督
- 資材の供給不足
- 設計変更
- アクセス制限
- 時間外労働
- 不適切な班編成
- あるいは、誤った見積前提
原因が何であれ、問題が見えるようになるのは、労務消費と物理的達成が同じプロジェクト参照を共有している場合に限られます。
だからこそ、ProjectVIEWは労務生産性を単なる人事管理ではなく、プロジェクト管理の一部として扱います。
機械稼働時間も進捗と同じではありません
同じ論理が建設機械にも当てはまります。
10時間予約されたクレーンが、必ずしも10時間分の価値を生み出したとは限りません。
現場にある掘削機は、次のような状態にあるかもしれません。
- 稼働中、
- 待機中、
- 遊休、
- 整備中、
- 移動・段取り中、
- あるいは他のアクティビティによって作業できない状態。
問題は単に次のことではありません。
「何時間の機械稼働時間が記録されたのか？」
そうではなく、次のとおりです。
「その機械稼働時間は、どのような測定可能なアウトプットを生み出したのか？」
ProjectVIEWの機械管理モデルには、稼働コストと遊休コスト、スケジューリングと稼働可能性、ロジスティクス、整備、BoQに関連する日々の機械稼働が含まれます。
したがって、機械は単なる保有機材台帳上の資産としてではなく、実際のプロジェクト生産に関連付けられた経済的資源として扱うことができます。
現場に到着した資材は進捗ではありません
資材は、よくあるもう一つの歪みをもたらします。
次のような状況を考えてみましょう。
資材の70%が購入済み。
作業は70%完了しているのでしょうか？
もちろん違います。
では、次の場合はどうでしょうか。
- 70%が発注済み、
- 60%が納品済み、
- 55%が在庫に受入済み、
- 45%が倉庫から払出済み、
- 40%が据付済み、
- そして、検査・検収済みはわずか35%。
どのパーセンテージが進捗を表しているのでしょうか？
それぞれの取引は、経営陣に有益な情報を伝えます。
しかし、どれも他と混同されるべきではありません。
ProjectVIEWの資材および生産プロセスは、次のものを区別します。
- 調達
- 入荷受領書（Goods Receipt Notes）
- 在庫
- 倉庫内の移動
- 払出
- 生産工程
- 資源消費
- そして実際の生産コスト
この区別は、次の分野で極めて重要です。
- 建設、
- MEP製作、
- 構造用鋼材、
- モジュール建設、
- 造船、
- 船舶修繕、
- オフショア製作、
- 産業製造、
その他のプロジェクト型生産環境。
- 発注済みは受領済みではありません。
- 受領済みは消費済みではありません。
- 消費済みは据付済みではありません。
- 据付済みは必ずしも検収済みではありません。
そして、これらのパーセンテージのいずれも、無条件に「プロジェクト進捗」とされるべきではありません。
ヤードの進捗は自動的に現場の進捗になるわけではありません
プロジェクトが製造と建設を組み合わせる場合、このことはさらに重要になります。
あるモジュールユニットが次の状態だとします。
- ヤードで80%製作済み。
関連するプロジェクト作業は80%完了しているのでしょうか？
- そうとは限りません。
そのモジュールには、まだ次の作業が必要かもしれません。
- 試験
- 検査
- 塗装
- 出荷承認
- 輸送
- 吊り上げ
- 据付・建方
- 接続
- 試運転
- そして発注者による検収
したがって、プロジェクト型製造には、複数の物理的環境にまたがる進捗管理が必要です。
オフィス ↔ 工場 ↔ ヤード ↔ 倉庫 ↔ 現場 ↔ 船舶
物理的な製品が移動する間も、経済的なつながりは途切れずに維持されなければなりません。
そうでなければ、各部門がそれぞれ独自の「完了」を報告することになります。
協力会社が主張する進捗は、もう一つの現実です
協力会社は次のように提出するかもしれません。
55%完了。
それは、元請会社が認めるべきパーセンテージとは限りません。
実際の進捗は、次のものと照らして検証する必要があるかもしれません。
- 実測数量
- 検査記録
- 契約単価
- 過去の出来高認定
- 承認済みの変更
- 保留金
- 控除
- 不適合
- そして裏付け書類
したがって：
主張された進捗 ≠ 検証済みの進捗
そして：
検証済みの進捗 ≠ 認定済みの進捗
ProjectVIEWの協力会社管理プロセスは、協力会社との契約、現場の進捗、出来高認定、控除、財務上の影響を、プロジェクト管理の構造の中で結び付けるよう設計されています。DANAOSは、ProjectVIEWの統合環境について、協力会社の進捗、出来高認定、債務をプロジェクトのコスト管理と併せて扱うものと説明しています。
認定済みの進捗は物理的進捗と同じではありません
施工会社が実際に完了しているのは：
物理的作業の50%。
しかし、もしかすると：
- 47%が検査済み、
- 43%が正式に認定済み、
- 38%が請求済み、
- そして30%が実際に支払済み。
ここでも、これらのパーセンテージのどれも必ずしも誤りではありません。
それらは、作業が商業的価値へと転換されていく過程の異なる段階に属しています。
ここから、重要な流れが見えてきます。
物理的進捗 → 検証済み進捗 → 認定済み進捗 → 請求済み進捗 → 回収済み収益
建設ERPは、これらの区別を維持しながら、それらの間の関係も保持すべきです。
なぜなら、現場の実行は最終的に財務上の現実にならなければならないからです。
ここでプロジェクト会計と財務会計が交わらなければなりません
財務会計は次のものを正確に報告できます。
- 請求書
- 買掛金
- 売掛金
- 仕訳
- 支払
- 収益
- 費用
しかし、会計が財務上の結果を把握するのは、通常取引が財務的に認識された後です。
建設マネジメントは、すべての財務書類が揃う前に、業務面で何が起きているかも把握しなければなりません。
- サプライヤーが資材を納品していても、その請求書はまだ計上されていないかもしれません。
- 協力会社が作業を完了していても、まだ出来高認定されていないかもしれません。
- 給与の締め前に、労務はすでに消費されているかもしれません。
- 月次のコスト配賦が確定する前に、機械はすでに稼働しているかもしれません。
- したがって、物理的進捗は、そのコストの一部が総勘定元帳に反映される前に存在しています。
だからこそ、プロジェクト会計をプロジェクトの実行から切り離すことはできません。財務取引は、最終的にそれを生み出したのと同じ作業まで追跡可能でなければなりません。
改めて：
BoQ ↔ WBS ↔ Cost Codes
ここで財務会計とプロジェクト会計が収束します。
資源消費が進捗に見合うとき、コスト管理が成立します
ここで、コスト管理をより正確に定義することができます。
コスト管理とは、単に次のことを把握することではありません。
- 実コスト vs 予算。
それは、達成された作業との関係において、なぜその実コストが発生しているのかを理解することです。
二つのワークパッケージがそれぞれ次の金額を支出したとします。
- $500,000.
パッケージAが獲得したのは：
- 予算価値で$550,000。
パッケージBが獲得したのは：
- $350,000.
会計上の取引は、どちらの場合も同じように正確かもしれません。
しかし、業務上のパフォーマンスはまったく異なります。
だからこそ、資源のコストは、進捗を測定するのと同じプロジェクト構造に関連付けられなければなりません。
そうでなければ、経営陣はお金を見ることはできます。
そして、経営陣は進捗を見ることもできます。
しかし、両者の関係を確実に説明することはできません。
それはコスト管理ではありません。
それは二つの別々の報告書にすぎません。
数量、生産性、コストが整合するとき
最も強力な状態は、経営陣が次の項目を継続的に比較できるときに生まれます。
数量
実際にどれだけの作業が達成されたのか？
生産性
その数量は、時間の経過とともにどれだけ効率的に生み出されているのか？
コスト
それを達成するために、どれだけの資源支出が必要だったのか？
これら三つがベースラインと整合している限り、プロジェクトは計画した経済モデルに近い形で運営されています。
いずれかが乖離し始めると、経営陣は早期警告を受け取ります。
例えば：
- 数量が遅れ＋コストは計画どおり
工程／生産性の問題を示している可能性があります。
- 数量は計画どおり＋コストが高い
資源の非効率を示している可能性があります。
- 数量が先行＋コストも比例して先行
単に施工が加速していることを反映しているだけかもしれません。
- 数量が先行＋コストは計画を下回る
生産性の向上を示している可能性があります。
- 時間が経過＋獲得数量はわずか
工程の悪化を示すシグナルです。
だからこそ、進捗を単独で解釈することはできません。
進捗は生産とコストを通じて説明されなければなりません。
進捗報告から継続的な現実の検証へ
従来の報告は、定期的に次のように行われる傾向があります。
- 進捗を収集する。
- P6を更新する。
- 実コストを収集する。
- 請求書を待つ。
- 財務を締める。
- スプレッドシートを照合する。
- 月次報告書を作成する。
- 差異を説明する。
経営陣が全体像を把握する頃には、差異を生んだ事象は数週間前に起きていたかもしれません。
プロジェクト中心のERPは、この順序を変えます。
現場のユーザーは、次の情報を継続的に登録します。
- 物理的進捗
- 労務取引
- 機械稼働
- 資材の移動
- 生産
- 協力会社の進捗
- 検査
- 出来高認定
- その他の業務イベント
これらの取引は、同じプロジェクト構造に紐付けられています。
したがって、システムは継続的に次のように問うことができます。
何を達成しているべきだったのか？
実際に何を達成したのか？
その達成にはどれだけの資源を消費すべきだったのか？
実際にはどれだけの資源を消費したのか？
それらの資源にいくらかかったのか？
その差異は、プロジェクトの残りの部分にとって何を意味するのか？
それこそが、真のプロジェクトの現実の検証です。
そして、これは信頼できるAIの基盤でもあります
AIによって、このアーキテクチャはさらに重要になります。
企業向けAIエージェントに次のように尋ねることを想像してください。
「なぜプロジェクトAは利益率を失っているのか？」
進捗はP6に、
資材はスプレッドシートに、
労務は給与システムに、
機械は別のシステムに、
協力会社の進捗はPDFに、
調達はERPに、
そして実際の財務データは総勘定元帳にあるとすれば、
AIはまず、それらのデータセット間の関係を推測しようとしなければなりません。
それは、実際のビジネス上の問いに取り組む前の段階で、すでに確率的な問題です。
しかし、もし
BoQ、WBS、Cost Codes、資源、進捗、財務取引がすでに確定的に関連付けられていれば、
AIは構造化されたビジネスコンテキストに基づいて動作します。
そうすれば、AIはプロジェクトを再構築するのではなく、プロジェクトを問いただすことができます。
それがProjectVIEW ERP + ProjectVIEW AIアーキテクチャの目的です。
ProjectVIEW ERPは、確定的な業務上の現実を確立します。
ProjectVIEW AIは、その現実を問いただします。
企業自身が確立できなかった関係を、AIに創作させるべきではありません。
では、「50%完了」のプロジェクトは実際にどこまで完了しているのか？
正しい答えは次のとおりです。
- その50%が何を測っているかによります。
しかし、建設マネジメントはさらに踏み込まなければなりません。
その50%が検証済みの物理的達成を表しているのであれば、経営陣は次に次のことを問うべきです。
- 現時点までに何を達成する計画だったのか？
- 実際にどれだけの数量を達成したのか？
- どれだけの時間がかかったのか？
- どれだけの労務を消費したのか？
- どれだけの機械を消費したのか？
- どれだけの資材を消費したのか？
- どれだけの協力会社の価値を消費したのか？
- 実際のコストはいくらだったのか？
- どれだけの価値を獲得したのか？
- 何が認定されたのか？
- 何が請求されたのか？
- 何が回収されたのか？
そうして初めて、「50%完了」はダッシュボード上の数字ではなく、マネジメント情報になります。
よくある質問
建設における実際の進捗とは何ですか？
実際の進捗とは、報告日時点で実際に完了したプロジェクト作業の、測定可能な数量または客観的に検証されたパーセンテージです。通常は、BoQ項目、WBSアクティビティ、またはその両者の管理された関係によって表されるプロジェクト範囲に対して記録すべきものです。
建設進捗はどのように測定すべきですか？
可能な限り、建設進捗は、敷設メートル数、打設立方メートル数、建方トン数など、実際の完了数量によって測定すべきです。物理的数量だけでは不十分な場合は、あらかじめ定めた加重マイルストーンや出来高認定ルール（Rules of Credit）を用いて、進捗を客観的に判断できます。
WBSの進捗率だけで建設プロジェクトを管理できますか？
いいえ。
WBSの進捗率は工程管理には有用ですが、プロジェクト管理には、物理的数量、資源消費、コストとの比較も必要です。
労務、資材、機械、協力会社、財務取引から切り離されたWBSの進捗率が提供するのは進捗報告であり、包括的な建設マネジメントではありません。
進捗とコスト管理の関係は何ですか？
進捗は、どの作業が達成されたかを明らかにします。
コスト管理は、その作業を達成するために消費された資源とコストが、プロジェクト予算と整合しているかどうかを判断します。
したがって、労務、機械、資材、協力会社、その他の資源の実コストは、進捗を測定するのと同じBoQおよび／またはWBSに関連付けるべきです。
建設におけるアーンドバリューとは何ですか？
アーンドバリューとは、実際に完了した作業の予算上の価値です。
これにより経営陣は、計画した内容、達成した内容、そしてその達成した作業に実際にかかったコストを比較できます。
Oracle Primaveraは、Performance Percent Completeを用いてアーンドバリューを計算します。Oracle Primavera P6のアーンドバリューの定義
物理的進捗とアーンドバリューの違いは何ですか？
物理的進捗は、完了した作業の量を表します。
アーンドバリューは、その完了した作業に予算上の経済的価値を割り当てます。
したがって、物理的進捗は達成内容を明らかにし、アーンドバリューは経営陣がその達成内容をプロジェクト予算および実コストと比較するのに役立ちます。
なぜプロジェクトは50%完了の時点ですでに予算超過になり得るのですか？
物理的進捗と資源消費が乖離している可能性があるからです。
プロジェクトは、労務予算の70%、機械予算の65%、総コストの60%を消費した後に、作業の50%を達成している場合があります。
進捗率が正しくても、プロジェクトの経済的パフォーマンスが悪化していることがあります。
労務生産性は建設進捗とどのように関係していますか？
労務生産性は、消費された労務と生み出された作業との関係を測定します。
例えば：
敷設メートル数 / 労務時間
または：
製作トン数 / 労務時間
労務時間を測定可能なアウトプットと関連付けずに追跡しても、消費は分かりますが、生産性は分かりません。
資材の納品は建設進捗とみなされますか？
必ずしもそうではありません。
資材は、発注、納品、保管、払出、製作、据付、検収がそれぞれ異なる時点で行われることがあります。
資材の到着はロジスティクスや契約上の確約にとって重要ですが、自動的に物理的な建設進捗と解釈すべきではありません。
協力会社が主張する進捗はプロジェクトの進捗と同じですか？
いいえ。
協力会社の請求は、認定済み進捗となる前に、測定可能な作業、検査記録、契約条件、変更、過去の出来高認定、控除、保留金と照らして検証すべきです。
なぜBoQ、WBS、Cost Codesを結び付けるのですか？
それらは同じプロジェクトの、異なるが相互に依存する三つの次元を表しているからです。
BoQ — 測定可能／商業的な範囲
WBS — 実行と時間
Cost Codes — 経済的分類
これらを結び付けることで、物理的進捗、資源の投入、財務コストを、同じプロジェクトの現実に対して分析できるようになります。
このアーキテクチャの背景については、WBSとプロジェクトのコスト管理に関するDANAOSの解説をご覧ください。プロジェクトのコスト管理にWBSだけでは不十分な理由
まとめ
プロジェクトが「50%完了」しているというだけでは、それを管理するには情報が不十分です。
私たちが知る必要があるのは：
何の50%なのか？
そして次に：
どれだけのコストで？
どの資源を使って？
どれだけの期間で？
計画された数量と生産性に対してどうなのか？
どれだけのアーンドバリューを生み出しているのか？
なぜなら：
WBSアクティビティに対して入力されたパーセンテージは、進捗報告です。
時間、資源、コストと照合された作業数量こそが、建設マネジメントです。
そして、達成された作業の価値を、計画内容および実際にかかったコストと継続的に比較するとき、私たちは単にプロジェクトを報告する段階から、プロジェクトを管理する段階へと移行します。
それこそが、作業が行われていることを知っているのか、それともプロジェクトが成果を上げているかどうかを知っているのか、という違いなのです。
