プロジェクトコントロールには洗練された幻想があふれています。
最も根強いものの一つが、作業期間の超過、つまり実績期間と計画期間の差が、効率や生産性を表すという考え方です。
科学的で精緻に見えます。さらに、TPR（Time Performance Ratio）といった略語まで付いています。
しかし、真実はこうです。これは fugazi、つまり成果の洞察を装った数学上の蜃気楼にすぎません。
1. フィクションを比較するという虚構
要するに、TPRは「実績期間」を「当初期間」で割って、それをパフォーマンスと呼んでいるのです。
しかし、そのロジックは、次の問いを投げた瞬間に崩れます。その数値は実際には何を表しているのか。
- ベースライン期間は、通常は推測です。労務主導または工期制約ありきで、資源前提も恣意的です。
- 一方でチームは、推定進捗や不完全な現場報告をもとに、後から実績期間を再構成することがよくあります。
したがって、一つの仮定を別の仮定で割っても、パフォーマンスを評価していることにはなりません。フィクションをフィクションで比較しているだけです。これは分析ではありません。数秘術です。
2. 進捗という幻想
ほとんどの案件では、進捗は誰も測っていません。チームが見積もっているだけです。
たとえば「60%完了」は、設置数量の60%を意味することはまずありません。実際には、誰かの確信度です。
その主観的な進捗が期間指標に反映されると、結果として見積りの見積りになります。
そのため、TPRの値がダッシュボードに載るころには、いくつもの解釈層を通過しています。もはや現場の実績を反映していません。
その結果は？ 何も現実を示さない、見栄えだけのチャートです。
3. クリティカルパスの蜃気楼
クリティカルパス法（CPM）の分析は、期間が現実的な班編成と生産性率に基づいていることを前提にしています。
しかし、計画担当者が労務主導の作業を実在の資源と結び付けなければ、クリティカルパスはソフトウェア上の幻想にすぎません。
そのため、Primavera上で遅れている項目は示しても、現場で本当にクリティカルなものは示しません。
言い換えれば、スケジュールは数学的には正しくても、物理的には意味を持たないことがあるのです。
4. WBSが崩れるとき
実案件では、Work Breakdown Structure（WBS）は進化します。たとえば、新しいBoQ、設計変更、変更指示によってです。
しかし、WBSの更新が新たな資源計算を引き起こさないなら、先月の前提で昨日の現実をモデル化していることになります。
その結果は？ 期間超過は非効率を示しているのではなく、現場から切り離されたモデルを示しているのです。
5. 欠けている背骨。BoQ主導の資源ロジック
工程分析に理性を取り戻す唯一の方法は、BoQとWBSの連携と現場で検証された生産性データに基づいて工程を組み立てることです。
真実の階層は次のとおりです。
- BoQ → WBSマッピング：すべてのWBS作業は、測定可能なBoQ数量に直接対応していなければなりません。
- 資源 → 数量：各BoQ項目は、実際の生産性ベンチマークに基づく人員、機械、材料のコストレシピに結び付いていなければなりません。
- 原価 → 工期統合：資源を数量に紐づければ、恣意的な推測ではなく、実際の生産率から期間を算出できます。
その結果、本物の原価・工程ベースラインが作られます。Excel上の空想ではありません。計画担当者の楽観でもありません。測定可能な作業に根ざした生きたモデルです。
6. 機能する支払ロジック
BoQ、WBS、資源をつなげると、支払マイルストーンは恣意的な日付ではなくなります。代わりに、実際の進捗に紐づく契約上の確認点になります。
実務では、各支払段階は次のいずれかに対応します。
- 定量化され、検証済みの完了作業。
- BoQ項目に一致した資源投入。
- 監査や紛争にも耐える原価証跡。
これによって、時間、コスト、キャッシュフローを統制できます。ひいては、顧客は進捗の見かけではなく、実際に提供した価値に対して支払うことになります。
7. データの演出から、証拠に基づく統制へ
実際のBoQと資源が統合されると、次の3つが可能になります。
- まず、実績工数と計画工数を比較して、労務生産性を追跡できます。
- 次に、機械時間の実績を比較して、設備稼働率を定量化できます。
- 最後に、実際の消費量と計画を比較して、資材消費を追跡できます。
これらは厳密な指標です。したがって、仮定ではなく証拠に基づいて資源を調整できます。
それが案件回復の方法です。そして、クレームが通る方法でもあります。要するに、Excelではなく現実を管理するということです。
8. なぜこれを実現できるのはProjectVIEW ERPだけなのか
率直に言えば、PrimaveraでもMS Projectでも、この統合を実現できる単体のスケジューリングツールはありません。そうしたツールは、原価と数量の現実ではなく、ロジックと時間の中で動いているのです。
対して、DANAOSはProjectVIEW ERPを別の発想で構築しました。
それは、BoQ主導のWBS構造、資源生産性テンプレート、現場で検証されたコストレシピを軸に設計された、唯一の建設管理システムです。
ProjectVIEW ERPなら、次のことができます。
- BoQ数量をWBS要素に直接リンクする。
- 実際の生産性データから原価と工期のベースラインを生成する。
- スコープ変更時に資源を動的に更新する。
- 進捗、支払、パフォーマンスを一つの連続した統制ループで整合させる。
それはソフトウェアではありません。建設インテリジェンスです。
したがって、工程管理を芸術から科学へ、幻想から証拠へと変えます。
9. 結論
期間超過、TPR、その他の建設工程指標は客観的に見えます。しかし、実際にはしばしば誤ったものを測っています。
精密さの幻想を与えながら、現実性の欠如を覆い隠しています。
対照的に、ProjectVIEW ERPはその幻想を打ち砕きます。
原価、時間、資源を一つの検証可能なモデルに結び付けます。その結果、すべての工程表が、現場で実際に起きていることを生きた形で反映するようになります。
業界がBoQベースの資源ロジックを受け入れるまでは、私たちは比率を現実と取り違え続けるでしょう。
それこそが究極の詭弁です。
10. こうした手法が生き残る本当の理由
最後に、誰も口にしたがらない真実を述べましょう。
実は、期間超過指標やTPR分析が広く使われるのは、それが間違った相手に都合がいいからです。
それらを作った人々は、プロジェクトマネージャー、デベロッパー、コンサルタント向けに作っており、請負業者向けではありませんでした。
コンサルタントが好むのは、客観的に見え、報告書を埋め、責任の所在をずらせるからです。
そしてオチはこうです。
コンサルタントやデベロッパーは、実のところコストをあまり気にしません。ほとんどの場合、そのコストは請負業者の問題だからです。
モデルが失敗しても、損失を吸収するのは工程表を作ったコンサルタントではなく、請負業者です。
だからこそ、こうした欠陥のある手法は残り続けるのです。テーブルの反対側にいる人を守るからです。
だからこそ、請負業者にはProjectVIEW ERPのようなツールが必要です。自らの現実、自らの証拠、自らの支払いを守るために作られたシステムです。
しかし、ここが転換点です。
コンサルタントがついにProjectVIEW ERPの考え方を採り入れれば、真のEarned Value KPI、正確なステータスレポート、信頼できる進捗更新にアクセスできるようになります。
そうなれば、仮想的な比率ではなく、実際の現場条件に基づいて予算と工程を再予測できるようになります。
そのとき、プロジェクトコントロールは学問的なものではなくなり、説明責任を持つものになります。
それまでは、期間超過指標はこれまで通りでしょう。
コンサルタントが賢く見え、請負業者が損をするためのツールです。
