プロジェクト型産業では、建設における生産速度（Production Rate）と生産性（Productivity）が同じ意味の言葉として扱われがちです。
しかし、両者は同じではありません。
この違いが重要なのは、次の理由からです。
- 生産速度は作業がどれだけの速さで進んでいるかを示し、
- 生産性はそれを生み出すために資源がどれだけ効率的に消費されているかを示します。
建設労働生産性に関するAACE Internationalのガイダンス AACE International — Estimating Lost Labor Productivity in Construction Claimsによれば、生産性とは本質的に、労働1時間あたりの据付数量のような、アウトプットとインプットの関係です。
Federal Highway Administration（FHWA）による生産速度の定義 FHWA — Guide for Construction Contract Time Determination Proceduresでは、生産速度を一定期間内に生産または施工される数量と定義しています。
この違いにより、2つの異なるプロジェクト管理の軸が生まれます。
- 生産速度：一定期間内にどれだけの物理的な作業を生み出しているか？
例：
• 掘削 m³/日 • 製作トン数/シフト • 配管 m/日 • 型枠 m²/日 • 建方トン数/日 • 溶接完了数/シフト
- 生産性：そのアウトプットを生み出すために、労働力、機械、その他の資源をどれだけ効率的に使っているか？
例：
• m³/労働時間 • トン/班時間 • m/機械時間 • 労働時間/トン • 機械時間/m³
したがって、プロジェクトは計画どおりの日次生産量を達成しながら、見積を大幅に上回る労働力や機械を消費していることがあり得ます。
その場合：
生産量は目標どおりでも、生産性は悪化している可能性があります。
ここから、工程の実績とコストの実績が乖離し始めます。
生産速度が工期を決める
作業量主導型の建設アクティビティ（Work Breakdown Structure – WBS）における基本的な工学的関係は次のとおりです。
アクティビティ期間 ＝ 作業数量 ÷ 生産速度
この原則は、アクティビティ期間の決定に関するAACE Internationalのガイダンス AACE International — Determining Activity Durationsにも反映されています。
AACEは、アクティビティ期間は体系的に設定すべきであり、プロジェクトの見積、過去の実績、利用可能な資源、作業条件、プロジェクト固有の制約を考慮すべきだと強調しています。
同じ原則はFHWAの建設工程計画ガイダンス FHWA — Production Rates and Contract Time Determinationにも見られます。
FHWAは、生産数量、期間、班編成、投入機械、現場条件などを含む実際の過去の施工データから生産速度のベンチマークを構築することを推奨しています。
これは、現場の施工データを継続的に取り込まない単独の見積ツールでは困難です。ProjectVIEWのような統合ERPであれば、実際の施工実績を将来の見積にフィードバックし、生産性の前提を段階的に精緻化することで、このループを閉じることができます。
FHWAは、実際の過去の施工記録から生産速度に関する知見を構築することを推奨しており、その記録には次のものが含まれます。
• 実際の生産数量 • 期間 • 班編成 • 投入機械 • 作業条件 • プロジェクトの特性
重要な点として、FHWAは、生産速度はその作業に投入できる労働力と機械資源の実際的な水準を反映すべきだとしています。
簡単な例で考えてみましょう。
Bill of Quantitiesに次の項目があるとします。
掘削数量 ＝ 20,000 m³
選定した資源構成で、安定して次の量を生産できるとすると：
1,000 m³/日
次のようになります。
20,000 ÷ 1,000 ＝ 約20稼働日
これにより、計画担当者は作業量主導型のWork Breakdown Structure（WBS）アクティビティに工学的な根拠を持てます。
- 班を変える。
- 掘削機を変える。
- トラック編成を変える。
- シフト時間を変える。
- 現場へのアクセスを変える。
- 地質が変わる。
生産速度は変わる可能性があり、したがってWBSの期間も変わるべきです。
生産性が資源消費とコストを決める
生産性は別の問いに答えます。
必要な数量を生み出すために、どれだけの資源投入が必要か？
労働生産性を次のように表すと：
生産性 ＝ アウトプット ÷ 労働時間
次のようになります。
必要労働時間 ＝ 数量 ÷ 生産性
さらに：
労務費 ＝ 必要労働時間 × 時間あたり労務単価
見積基準を逆に単位あたり労働時間で表す場合、計算は次のようになります。
労務費 ＝ 数量 × 単位あたり労働時間 × 労務単価
この考え方は、労働生産性基準の設定に関するAACE Internationalの推奨実務 AACE International — Establishing Labor Productivity Normsによって裏付けられています。
AACEは、労働資源の必要量と生産性基準を、見積だけでなく次の用途にも不可欠なインプットとして位置付けています。
• 計画と工程管理 • 資源計画 • 入札 • ベンチマーキング • プロジェクト管理 • 効率分析 • クレームと変更の評価
同じ原則は機械にも当てはまります。
必要機械時間 ＝ 数量 ÷ 機械の生産性
さらに：
機械費 ＝ 機械時間 × 機械の時間単価
資材は、関連してはいるものの異なる論理に従います。
資材所要量 ＝ 数量 × 消費係数
したがって、Bill of Quantitiesの1行の直接費は、次の組み合わせから生まれます。
労務 ＋ 資材 ＋ 機械 ＋ 下請 ＋ その他の直接資源
これが資源ベース見積の基盤です。
単価とは、実は資源の組み合わせである
建設見積における最も重要な原則の一つは、信頼できる単価はそれを生み出す資源から切り離して存在すべきではない、ということです。
たとえば次の単価は：
12ドル/m³
その単価を生み出した要素を理解しない限り、ほとんど意味を持ちません。
土工事の場合、根底にある資源の組み合わせには次のものが含まれます。
• 掘削機の種類と能力 • トラックの台数と積載能力 • オペレーター • 運転手 • 誘導員 • 燃料 • 残土処分距離 • 補助作業員 • 想定サイクルタイム
コンクリート工事の場合、資源の組み合わせには次のものが含まれます。
• 型枠大工 • 鉄筋工 • コンクリート作業員 • コンクリートポンプ • クレーン • 型枠システム • 生コンクリートの供給 • 補助機械
造船や製作の場合は、次のものが含まれます。
• 溶接工 • 取付工 • 電気工 • 製作機械 • クレーン • 揚重機器 • 消耗品 • 資材搬送資源
だからこそ、現実的な建設生産速度を設定するFHWAのアプローチは、過去の数量を記録するだけでなく、実際の班編成と機械を考慮しています。 FHWA — Production Rate Guidance
組み合わせが重要です。
労働力を2倍にしても、生産量が2倍になるとは限りません。
掘削能力を増やさずにトラックを追加すると、待ち行列が生じる可能性があります。
十分なトラックがないまま掘削能力を増やすと、機械の遊休が生じる可能性があります。
十分な資材がないまま労働力を増やしても、待ち時間が増えるだけかもしれません。
プロジェクトの作業は一つの資源システムであり、その生産性は資源同士がどれだけうまく連携するかにかかっています。
DANAOS Projectsの視点：生産性は数量、資源、時間、コストをつなぐ
ここから、プロジェクト管理における重要な原則が導かれます。
Bill of Quantities（BoQ）が主に示すのは：
何を、どれだけ施工しなければならないか。
Work Breakdown Structure（WBS）が示すのは：
いつ、どのアクティビティを通じてプロジェクトを実行するか。
Cost Codesが分類するのは：
支出と運用コストをどこで管理すべきか。
しかし、これらの次元をつなぐ何かが必要です。
そのつなぎとなる層が、資源の必要量とその生産性です。
実務的には次のようになります。
- BoQ数量 ↓
- 資源の組み合わせ ↓
- 生産速度／生産性 ↓
- WBS期間 ↓
- 資源コスト ↓
- プロジェクトベースライン
これがProjectVIEW ERPのプロジェクト中心アーキテクチャの背後にある論理です。
資源の組み合わせからCost Recipeへ
ProjectVIEW ERPでは、再利用可能な資源の組み合わせをCost Recipes／生産性テンプレートとして設定できます。
ProjectVIEWの現行製品資料では、次の機能が示されています。
• BoQの取り込みと構造化 • BoQの各行への資源の関連付け • 資源配分へのCost Recipesの活用 • BoQ ↔ WBS ↔ Cost Codesの関連付け • 資源の配分とスケジューリング • 現場の労務、機械、進捗の実績データの取得 • 実績コストと予算コストの比較
したがって、Cost Recipeは、保存された単価よりもはるかに深い意味を持つものとして理解すべきです。
概念的には、次の要素を表します。
範囲
- 資源の組み合わせ
- 資源数量
- 生産性の前提
- 生産速度
- 資源コスト ＝ 見積単価と期間の根拠
つまり、単に次のように保存するのではなく：
掘削 ＝ 12ドル/m³
組織は、その12ドルの背後にある工学的な前提を保持できます。
- どの掘削機か？
- トラックは何台か？
- どの職種の労働力か？
- 機械時間はどれだけか？
- 生産速度はどれだけか？
- 燃料や消費についての前提は何か？
- どのような過去の条件がその結果を生んだのか？
これにより、単なる過去の価格ではなく、再利用可能な組織の知見が生まれます。
過去の生産性は文脈とともに扱う必要がある
過去のデータは非常に価値があります。
しかし、あるプロジェクトから別のプロジェクトへ機械的にコピーすべきではありません。
AACEは、生産性基準は文脈の中で理解し、次のような要因に応じて調整しなければならないと明確に警告しています。
• 作業員の技能 • 組織 • 作業環境 • プロジェクトの所在地 • 条件 • モチベーション • リスク • その他の生産性への影響要因
労働生産性基準に関するAACEのガイダンス AACE International — Establishing Labor Productivity Normsをご参照ください。
FHWAも過去の生産速度 FHWA — Historical Construction Production Ratesについて同様の結論に達しています。過去の情報は見積の基礎とすべきですが、その速度は新しいプロジェクトの条件に合わせて調整する必要があります。
この違いは重要です。
Cost Recipeは、次のようなものになるべきではありません。
「これが当社の恒久的な標準生産性である。」
次のようなものになるべきです。
「これは、この条件とこの資源の組み合わせのもとで検証された、当社のベンチマークである。」
そのほうがはるかに有用です。
見積 → 計画 → 実行 → 測定 → 学習
真の価値は、生産性情報が見積部門の中に閉じ込められないときに生まれます。
ProjectVIEW ERPは、次の関係を軸に設計されています。
BoQ ↔ WBS ↔ Cost Codes
公開されているProjectVIEW ERPのアーキテクチャ ProjectVIEW ERP — BoQ, WBS and Cost Code Integrationは、BoQが表す商務上の数量構造を、WBSの時間構造および社内のCost Codesと明確に結び付けています。
したがって、ワークフローは次のようになります。
1. 見積
定義する項目：
• 数量 • 資源の組み合わせ • 資源コスト • 想定生産性 • 想定生産速度
2. 予算
設定する項目：
• 計画資源消費量 • 単価 • 総コストベースライン
3. 計画
次の要素を：
• 数量 • 生産能力 • 資源の可用性
関連するWBSアクティビティの想定期間に落とし込みます。
4. 実行
取得する実績：
• 出来高 • 労働時間 • 機械時間 • 資材消費量 • 下請の進捗
ProjectVIEWの資料では、Cost Controlの中で進捗、労務、機械に関する現場の実データを取得することが明記されています。 ProjectVIEW ERP Modules and Cost Control
5. 管理
比較する項目：
実績アウトプットと計画アウトプット
そして同時に：
実績資源消費量と計画資源消費量
6. 学習
十分に比較可能な実行データを活用し、将来のCost Recipesの前提を改善します。
その結果、次のようなフィードバックループが生まれます。
見積 → 予算 → 工程 → 実行 → 測定 → 改善 → 再見積
こうして、組織の見積知見は時間とともに蓄積されていくべきです。
これがコスト管理を変える理由
あるBoQ項目の出来高が50%に達しているとします。
一見すると、進捗は順調に見えるかもしれません。
しかし、プロジェクトがすでに次の量を消費していたとしたらどうでしょうか。
見積労働時間の75%。
これは単なる会計上の問題ではありません。
これは運用上の生産性差異です。
同じことは機械にも当てはまります。
生産された数量に対して想定を大幅に上回る機械時間を消費している場合、経営陣は次のように問うべきです。
- 機械の生産性が想定より低いのか？
- 機械の遊休時間が過剰なのか？
- 機械編成のバランスが悪いのか？
- 機械が実際の条件に適していないのか？
- 生産が労務や資材によって制約されているのか？
- 範囲が変わったのか？
- 当初の見積の前提が誤っていたのか？
だからこそ、ProjectVIEWの実績対予算のコスト管理 ProjectVIEW ERP Cost Control Architectureは、財務取引だけにとどまらない仕組みとして構築されています。
プロジェクト管理は、支出を次の要素とあわせて解釈できるときに、より有用になります。
数量 ＋ 進捗 ＋ 労務 ＋ 機械 ＋ 資材 ＋ 時間
生産と生産性は工程差異も説明する
この区別は、有用な診断の枠組みにもなります。
基本的な状態は4つあります。生産が計画どおり ＋ 生産性が計画どおり
作業はおおむね見積どおりに進んでいます。生産が計画未達 ＋ 生産性が計画どおり
資源は効率的に働いているかもしれませんが、能力、作業時間、アクセス、資源の不足が工程を脅かしている可能性があります。
生産が計画どおり ＋ 生産性が計画未達
これは特に危険です。
プロジェクトは工程どおりに見えるかもしれませんが、予算を上回る労務や機械を消費することで生産を維持しています。
利益率を犠牲にして工程を守っている状態です。
生産が計画未達 ＋ 生産性が計画未達
工程とコストの両方の実績が悪化しています。
だからこそ、経営幹部は進捗、生産、生産性という言葉を、同じKPIを表すかのように使うべきではありません。
機械の稼働率は機械の生産性ではない
同じ区別は、建設機械と車両の管理にも欠かせません。
通常は、4つの異なる指標を考慮すべきです。
可用性
その機械は技術的に稼働可能な状態だったか？
稼働率
利用可能な時間のうち、実際に投入されていた時間はどれだけか？
生産速度
一定期間にどれだけの作業を生み出したか？
機械の生産性
消費した機械時間1時間あたり、どれだけのアウトプットが得られたか？
稼働率が高いからといって、生産性が高いとは限りません。
機械がシフトの間ずっと稼働していても、アウトプットが乏しいことはあり得ます。
その原因として、次のようなものが考えられます。
- 待ち行列
- 機械編成のバランスの悪さ
- 不適切な機械能力
- オペレーターのパフォーマンス
- アクセスの制約
- 資材不足
- 過大な運搬距離
- 生産チェーンの他の箇所での故障
ProjectVIEWの機械管理・稼働管理機能は、見積、工程管理、Cost Controlと同じプロジェクト資源環境の一部です。ProjectVIEWの資料では、機械の要求、配置、取引、コスト監視、資源管理を、現場の労務・進捗の取得とあわせて示しています。 DANAOS ProjectVIEW ERP Brochure
したがって機械は、固定資産台帳に記録された資産にとどまらず、プロジェクトの生産的な資源となります。
生産性データはプロジェクトの変更（バリエーション）にも不可欠
信頼できるベースラインが重要であるもう一つの大きな理由があります。
変更です。
- 建設プロジェクトは絶えず変化します。
- 設計変更。
- 数量の変更。
- 作業順序の違い。
- アクセスの制限。
- 情報の遅れ。
- 手戻り。
- 工程の加速。
- 手待ち時間
- 追加工事。
変更が発生したとき、総コストが増えたことを知るだけでは、運用上の影響を十分に説明できない場合があります。
より本質的な問いは次のとおりです。
変更された条件は、当初想定していた資源の生産性にどのような影響を与えたのか？
建設における生産性損失とクレームに関するAACEの研究 AACE International — Lost Labor Productivity in Construction Claimsは、詳細な同時記録の重要性を強調しています。信頼できる過去のプロジェクトデータがなければ、生産性の損失とその因果関係を立証することが難しくなるためです。
これは、すべての変更が自動的に生産性損失を生むという意味ではありません。
請負業者には、変更された作業条件を評価するための信頼できるベースラインが必要だという意味です。
ProjectVIEWのCost Control機能は、プロジェクト構造の中で複数のBoQ/WBSバージョン、クレーム、変更をサポートします。 ProjectVIEW ERP Modules — Claims and Variations
ソフトウェアそのものが契約上の権利を確定するわけではありません。
しかし、次の事項の構造化された記録は：
- ベースラインの生産性
- 実際の数量
- 消費した労務
- 消費した機械
- 出来高
- 変更された数量
- 改訂されたBoQとWBSのバージョン
運用面で何が変わったのかを理解するための、はるかに強固な事実の基盤となり得ます。
真のプロジェクトベースラインは予算総額以上のもの
従来、プロジェクトベースラインは次のように考えられてきました。
予算 ＋ 工程
しかし、これでは不十分です。
DANAOS Projectsでは、より有用なベースラインとは、その予算と工程を生み出した運用上の前提の集合であると考えています。
その前提には次のものが含まれます。
- BoQ数量
- 資源の組み合わせ
- 労働力の職種
- 機械の種類
- 資材
- 生産速度
- 生産性基準
- 資材消費量
- 資源コスト
- 想定アクティビティ期間
なぜでしょうか？
予算総額は経営陣にどれだけの支出が想定されていたかを示すからです。
資源ベースのベースラインは、なぜその金額の支出が想定されていたのかを説明します。
その違いは、プロジェクトの実態が計画から乖離し始めた瞬間に決定的な意味を持ちます。
ProjectVIEW ERP：生産、生産性、時間、コストをつなぐ
ここで、ProjectVIEW ERPの根底にあるビジネスロジックが重要になります。
ProjectVIEW ERPは次を関連付けます。
BoQ ↔ WBS ↔ Cost Codes
ProjectVIEW ERPのコスト・時間・資源アーキテクチャ DANAOS ProjectVIEW ERP Brochureをご覧ください。
その共通のプロジェクト構造を中心に、ProjectVIEWは次をつなぎます。
- 見積・入札
- 予算・コスト管理
- 労務管理（HRMS ＋ 給与）
- 機械・工具管理
- 資材・生産／製作管理
- 調達
- 倉庫管理
- 下請業者
- 現場進捗・施工管理
- 工程計画（Oracle P6およびMS Projectとの連携）
- 会計・財務
目的は、単に取引を記録することではありません。
運用の実態を、プロジェクトベースラインを生み出した前提と継続的に比較することです。
したがって、作業の見積に使った資源の論理を、そのまま施工中の管理の基準として使うことができます。
過去のデータから組織の知見へ
これが最終的に最も重要なメリットかもしれません。
経験豊富な請負業者の多くは、すでに膨大な生産性の知見を持っています。
問題は、その多くが次のような場所に散在していることです。
- スプレッドシート
- 過去の入札資料
- 計画担当者の個人データベース
- 見積担当者の経験
- 現場日誌
- 機械報告書
- 分断されたシステム
- 個々の従業員の知識
それはまだ企業としてのインテリジェンスではありません。
本当の機会は、その経験を構造化することにあります。
あるプロジェクトで検証された資源の組み合わせは、別のプロジェクトの出発点となるベンチマークになり得ます。
実行データは当初の前提を検証できます。
Cost Recipesは進化できます。
生産性の前提は改善できます。
生産速度はより現実的になり得ます。
計画は実際の施工能力により強く根差したものになり得ます。
そうなれば、見積は契約締結前に行う孤立した作業ではなくなります。
継続的な組織学習プロセスの一部となるのです。
生産は作業が進んでいるかを示し、生産性は利益率が守られているかを示す
プロジェクトの物理的な実行は資源を消費します。
労働時間。
機械時間。
資材。
下請の作業。
時間。
生産速度は、利用可能な時間内に十分な物理的作業が完了しているかを経営陣に示します。
生産性は、組織がそのアウトプットを達成するために資源を効率的に使っているかを経営陣に示します。
どちらも見積段階で設定すべきです。
どちらも計画に反映すべきです。
どちらも施工中に測定すべきです。
そして、どちらも次の見積にフィードバックすべきです。
次の流れが：
BoQ数量 → 資源の組み合わせ → 生産／生産性 → WBS期間 → コストベースライン → 実際の施工
一つのつながった情報モデルの一部として維持されれば、見積、計画、プロジェクト管理が、プロジェクトの異なるバージョンを語ることはなくなります。
それらは同じプロジェクトの実態を語り始めます。
それがProjectVIEW ERP DANAOS Projects — ProjectVIEW ERPの背後にある原則です。
入札から最終引き渡しまで、コスト、時間、資源、物理的な施工をつなぐよう設計された、プロジェクト中心のERPです。
