定義 プロジェクト時間管理とは、 定義 順序付け リソース配分 スケジューリング 監視 管理 を通じて、動員開始から引渡し・プロジェクト完了まで、契約上の工期内に資本プロジェクトを遂行するために必要なアクティビティを管理する手法です。 これは、プロジェクト遂行における時間に関するあらゆる側面を含みます。 作業の論理的な実施順序を確立すること リソースの利用可能性と生産性に基づいてアクティビティの所要期間を見積もること 実際の施工環境の制約を反映した工程表を作成すること 基準工程に対する進捗を監視すること 差異が連鎖的に拡大する前に特定すること 遅延を回復または軽減するための是正措置を講じること プロジェクト型産業におけるプロジェクト時間管理は、単なる日程管理ではありません。これは、原価管理、調達管理、リソース管理、およびリスク管理と直接統合して機能する管理手法です。原価管理システム、調達計画、およびリソース管理と切り離されて存在する工程表は、単なる図表であり、マネジメントツールではありません。効果的なプロジェクト時間管理では、すべての工程アクティビティが予算項目、リソース配分、およびスコープ項目と関連付けられ、ある領域で発生した遅延が他のすべての領域への影響として直ちに把握できるようになっています。 プロジェクトベース産業における位置付け 資本プロジェクトにおけるプロジェクト時間管理は、製造業、ソフトウェア開発、サービス業におけるスケジューリングとは本質的に異なる制約の下で行われます。これらの分野では、スケジュールは概ね繰り返し可能であり、リソースは相互に代替可能で、ある作業の遅延が業務全体へ連鎖的な影響を及ぼすことはほとんどありません。 一方、プロジェクト型産業では、すべての工程が固有であり、リソースには現場固有の制約があり、遅延は依存関係の連鎖を通じて拡大していきます。そして、その影響は、取り返しがつかなくなるまで見えないことが少なくありません。 建設業では、 病院建設を担当するゼネコンは、機械設備、電気設備、構造、仕上げなど、数十社に及ぶ下請業者を調整しなければなりません。それぞれが相互に依存関係を持ち、現場へのアクセス、資材の納入、行政や法令に基づく検査による制約を受けます。例えば、鉄骨建方が2週間遅れた場合、プロジェクト全体が単純に2週間遅れるわけではありません。その遅れは機械設備工事の着手を遅らせ、さらに電気工事、防災設備工事、検査、仕上げ工事へと連鎖し、最終的には1つの遅延が数か月規模の遅延へと拡大することがあります。 海洋・オフショア分野では、 海洋プラットフォームを建設するEPCコントラクターは、変更できない**気象作業可能期間（ウェザーウィンドウ）**の中で作業を行います。大型揚重作業、パイプライン敷設、海底接続工事は、特定の季節にしか実施できません。製作の遅延によって作業船がその気象期間を逃した場合、それは2週間の遅延ではなく、次の作業可能期間まで約6か月の遅延を意味します。このような環境では、時間管理とは生産性を最適化することではなく、二度と取り戻せない作業機会を守ることなのです。 造船業では、 新造船を建造する造船所が、鋼材加工、ブロック組立、艤装、塗装、試運転といった複数の生産工程を並行して管理し、それらは決められた統合ポイントで合流します。工程表は、工場の生産能力、クレーンの利用可能性、ドック占有計画、そして支給品（Owner-Furnished Equipment）の納入順序を同時に調整しなければなりません。1つのブロック組立の遅延は、建方工程全体を混乱させ、その後のすべてのマイルストーン――海上試運転や引渡しを含めて――を遅らせることになります。 鉱業・採石業では、 請負業者は採掘インフラを整備する中で、土木工事、機械設備据付、電気設備の試運転、環境適合確認を、遠隔地という特殊な条件下で重複して実施します。重機の動員、気象条件、行政許認可は、それぞれの現場固有の工程上の制約を生み出し、過去のプロジェクトからそのまま流用できるものではありません。 これらすべての業界に共通しているのは 、時間は購入することも、蓄えることも、取り戻すこともできない資源だということです。資本プロジェクトで1日失われれば、その1日は永遠に失われます。残された選択肢は、工程短縮（追加コストを伴う）、作業順序の変更（新たなリスクを伴う）、あるいは遅延を受け入れる（契約上の影響を受ける）のいずれかです。プロジェクト時間管理は、体系的な計画、監視、管理を通じて、こうした状況の発生頻度と影響を最小限に抑えるために存在します この概念が存在する理由 プロジェクト時間管理が正式な管理手法として確立されたのは、資本プロジェクトにおける工程遅延の影響が極めて深刻であり、急速に連鎖的に拡大し、一度蓄積し始めると、その多くが取り返しのつかないものとなるためです。 遅延の累積効果 資本プロジェクトにおける遅延は、直線的には進行しません。クリティカルパス上のアクティビティが1週間遅れたとしても、それが依存関係にある作業の連鎖的な遅延を引き起こす場合、プロジェクト全体の遅延が単純に1週間で済むとは限りません。例えば、鉄骨資材の納入が1週間遅れると、建方作業班の着手が遅れ、それによってクレーンを次の施工区画へ移動できず、その結果、機械設備工事業者の作業開始が遅れ、さらに検査工程にも遅延が波及します。この連鎖をすべて追跡すると、1週間の資材遅延が4週間のプロジェクト遅延へと拡大し、さらに3社の下請業者から工期延長請求（Extension of Time Claims）が提出される可能性があります。 このような連鎖的な遅延により、遅延コストは常に、遅延したアクティビティ自体の直接コストを上回ります。現場監督費、仮設設備費、機械レンタル費、警備費などの現場間接費は、工事が進捗しているかどうかに関係なく発生し続けます。さらに、下請業者は工事中断や生産性低下に対するクレームを提出し、発注者はマイルストーン支払いを保留したり、遅延損害金（Liquidated Damages）を課したりする場合があります。その結果、工程遅延による財務リスクは、原価超過によるリスクを上回ることが少なくありません。なぜなら、遅延は原価を増加させるだけでなく、収益を減少させ、さらに契約上のペナルティまで引き起こすからです。 計画と実行の乖離 多くのプロジェクト組織は、入札段階や着工前段階で詳細な工程表を作成するために多大な労力を費やします。しかし、プロジェクト開始時点の工程表は、工事がどのように進行するかについての仮説にすぎません。施工が始まった瞬間から、現実はその計画と乖離し始めます。資材の納入遅延、下請業者の生産性低下、悪天候による屋外作業の中断、設計変更によるスコープ変更、行政承認の遅れなどが次々と発生します。 基準工程に対する進捗を継続的に監視し、差異をリアルタイムで特定し、是正措置を講じる時間管理プロセスが存在しなければ、工程表は施工開始からわずか数週間で過去の記録となってしまいます。工程表を月次、あるいは四半期ごとにしか更新しないプロジェクトマネージャーは、すでに古くなった情報をもとに意思決定を行っていることになります。工程表と実際の状況との乖離は拡大し続け、やがて回復は不可能になります。 契約上の側面 資本プロジェクトにおいて、時間は単なる運営上の課題ではなく、契約上の義務です。建設契約では、完成期限、マイルストーン、そして遅延に対する**遅延損害金（Liquidated Damages）**が定められています。また、工期延長（Extension of Time）に関する条項では、施工者が追加工期を請求できる条件と手続きが規定されています。さらに、遅延分析の手法によって、遅延の責任がどの当事者に帰属するかが判断されます。 プロジェクト時間管理は、このような契約上の請求や反論を支える証拠を提供します。発注者に起因する遅延がクリティカルパスへ与えた影響を証明できなければ、施工者は工期延長を請求する根拠を持つことができません。同様に、施工者に起因する遅延がプロジェクト完成日に影響したことを発注者が証明できなければ、遅延損害金を請求する根拠もありません。工程表は、業務管理ツールであると同時に法的文書でもあり、その両方の整合性を維持するのがプロジェクト時間管理という管理手法です。 リソースと時間の相互依存性 プロジェクト遂行において、時間とリソースは切り離すことができません。すべてのアクティビティには、職種別の労務、種類別の設備機械、仕様ごとの資材など、特定のリソースが必要です。工程が変更されれば、必要となるリソースも変化します。工程を短縮すれば、より短期間に多くのリソースが必要となり、工程が遅延すれば、リソースの拘束期間が延び、他プロジェクトへ割り当てられているリソースとの競合が発生する可能性があります。 効果的なプロジェクト時間管理では、工程管理とリソース管理を統合し、工程表が論理的に正しいだけでなく、利用可能なリソースを前提として実際に実行可能であることを保証します。作業の順序が正しく示されていても、リソース制約を考慮していない工程表は、単なるロジック図であり、実行可能な計画ではありません。 計画工程と実行工程の乖離 プロジェクト時間管理において最も根深い問題は、計画された工程と実際に実行された工程との間に生じる乖離です。この乖離は、計画が不十分であることによって生じるのではなく、工程表をリアルタイムで実際の業務運営と結び付けるシステムが存在しないことによって生じます。 計画工程と実行工程の乖離は、予測可能な形で現れます。 第一に、進捗データの到着が遅すぎることです。 多くのプロジェクト組織では、進捗は週次または月次で報告されますが、それが集計され、検証され、工程管理ツールへ入力される頃には、その情報はすでに数日から数週間前のものになっています。その結果、意思決定はプロジェクトが現在どのような状況にあるかではなく、過去にどのような状況であったかに基づいて行われることになります。 第二に、進捗データが工程ロジックと切り離されていることです。 コンクリート打設量（立方メートル）、鉄骨建方量（トン）、配管・ケーブルなどの施工延長（メートル）といった実際の出来高は、工程管理ツールのアクティビティネットワークとは連携していない現場日報や進捗報告書に記録されます。そのため、スケジューラーは進捗報告を手作業で解釈し、該当するアクティビティを更新しなければならず、その過程で解釈の誤りや更新の遅れが生じます。 第三に、工程表が実際のリソース状況を反映していないことです。 クリティカルパスでは、あるアクティビティが翌週月曜日に開始される予定になっていても、必要な作業班はまだ別の作業に従事しているかもしれませんし、資材がまだ到着していない、あるいは先行作業の検査が完了していない場合もあります。このようなリソースの制約や着手前提条件は、調達システム、リソース配分システム、および検査記録と独立して管理されている工程表では把握することができません。 第四に、工程変更が原価管理や調達管理へ反映されないことです。 あるアクティビティが遅延した場合、その影響による原価――現場間接費の増加、工程短縮に伴う追加費用、クレームリスク――は、直ちに原価予測へ反映されるべきです。また、調達への影響――納品の前倒し、製作工程の順序変更――も、直ちに調達計画へ反映されるべきです。しかし、工程表が原価管理システムや調達システムと連携していない独立したツール上で管理されている場合、これらの影響は誰かが手作業で関連性を追跡するまで把握することができません。 統合プロジェクト管理システムは、設計段階から計画工程と実行工程の乖離を解消します。 進捗は、原価管理、調達管理、およびリソース管理を行う同一システム内で、工程表のアクティビティに対して記録されます。工程表に遅延が入力されると、その情報は自動的に原価予測へ反映され、調達への影響を通知するとともに、リソースの競合を特定します。こうして工程表は、週を追うごとに現実との乖離が広がる静的な計画書ではなく、実際の業務状況を反映し続ける生きた管理ツールとなります。 プロジェクト開始時だけでなく、施工期間全体を通じて工程の整合性を維持できる組織こそが、プロジェクトを予定どおりに完了させます。計画工程と実行工程の乖離は避けられないものではなく、分断されたシステムによって生じる結果であり、システム統合によって解消することができます。 概念的な仕組み プロジェクト時間管理は、契約締結前から始まり、プロジェクト完了まで継続する継続的な管理サイクルとして機能します。着工前に完了する一度限りの計画作業ではありません。 作業分解構造（WBS）とアクティビティ定義： プロジェクトのスコープは、すべての成果物と作業パッケージを定義する作業分解構造（WBS）へと分解されます。各作業パッケージはさらに、開始条件、必要なリソース、および完了基準が明確に定義されたアクティビティへと細分化されます。アクティビティの定義は工程管理の粒度を決定します。粒度が粗すぎると差異を把握できず、細かすぎると維持管理が困難になります。 順序設定とロジックの構築： アクティビティは、終了開始、開始開始、終了終了 といった論理関係によって結び付けられ、作業の物理的および契約上の制約を反映します。このロジックネットワークは、どのアクティビティが他の作業に先行しなければならないか、どの作業を並行して実施できるか、そしてどこにフロート（余裕時間）が存在するかを定義します。クリティカルパスは、相互に依存するアクティビティの中で最も長い連鎖であり、プロジェクトの最短工期を決定するとともに、遅延が一切許されないアクティビティを特定します。 所要期間の見積りとリソース割当て： 各アクティビティには、作業量、割り当てられたリソース、および想定される生産性に基づいて所要期間が設定されます。期間の見積りには、類似プロジェクトの実績データ、リソースの利用可能性評価、さらに天候、アクセス制限、作業時間の制約といった現場固有の条件が活用されます。リソース割当てでは、各アクティビティを特定の作業班、設備機械、および資材納入計画と関連付けることで、工程表が単に論理的に正しいだけでなく、実際に実行可能なものとなることを保証します。 基準工程の設定： 承認された工程表は、すべての進捗を評価する基準となる基準工程となります。この基準工程には、計画された開始日・完了日、クリティカルパス、総フロートの配分、およびリソース計画が記録されます。これは、プロジェクトの工期に関する契約上の約束を定義するとともに、遅延分析の基準となる契約文書です。 進捗監視と工程更新： 実行段階では、定められた間隔で実際の進捗を基準工程と比較します。完成した数量、達成したマイルストーン、完了した検査などの実際の進捗を把握し、それを工程表上のアクティビティへ反映します。工程表は、実際の開始日、実績工期、残存工期、および計画から逸脱した場合のロジック変更を反映するよう更新されます。さらに、アーンド・バリュー管理の指標である**スケジュール・パフォーマンス・インデックス（SPI）およびスケジュール差異（SV）により、工程の実績を客観的に評価します。 差異分析と是正措置： 工程上の差異が確認された場合、その影響がクリティカルパスおよびプロジェクト全体の完成日に与える影響を分析します。その上で、非クリティカル作業の順序変更、追加リソースによるクリティカル作業の工程短縮、順次作業を重複させるファストトラッキング、あるいは実際の施工方法に合わせたロジックの見直しなどの是正措置を策定します。それぞれの是正措置にはコスト、リスク、および他のプロジェクト要素への影響が伴うため、統合プロジェクト管理システムを通じて総合的に評価されます。 遅延分析とクレーム対応： 遅延が発生した場合、プロジェクト時間管理は、その原因、責任、および影響を明確にするための分析フレームワークを提供します。計画工程と実績工程の比較分析、影響を反映した計画工程分析、およびタイムインパクト分析 などの手法を用いて、工期延長請求、遅延損害金の評価、ならびに紛争解決のための客観的な根拠を確立します。 なぜ工程表は実務において機能しなくなるのか 資本プロジェクトにおける工程管理は、組織が工程表を作成し、維持し、活用する方法に起因する、体系的かつ予測可能なパターンによって失敗します。これは、プロジェクト業務そのものに内在する不確実性によるものではありません。 前倒し計画の誤謬： 組織は着工前に詳細な工程表を作成するために多大な労力を費やしますが、施工段階ではそれを適切に維持できません。作成に数週間を要した工程表が更新されるのは月次あるいは四半期ごとであり、その時点ではすでに現実を反映していません。その結果、工程表は意思決定のための管理ツールではなく、報告のための過去の記録となってしまいます。 独立した工程表の問題： 多くの工程管理ツールは、原価管理、調達管理、およびリソース管理システムと切り離された独立したアプリケーションとして運用されています。スケジューラーは他の管理情報と連携することなく工程表を作成・維持します。そのため、工程変更による原価への影響は誰かが手作業で計算するまで分からず、遅延による調達への影響も誰かが手作業で追跡するまで把握できません。工程表は、実際に業務上の意思決定が行われるシステムとは別世界で存在しているのです。 リソースを考慮しない工程表： リソースの利用可能性を検証せず、作業の論理的な順序だけを示す工程表は、論理的には正しくても現実には実行不可能な計画を生み出します。例えば、同時に予定された3つの作業がすべて同じクレーンを必要としていても、リソース制約がモデル化されていなければ工程表上では競合は発生しません。その結果、現場でクレーンが3か所同時に必要となり、2つの作業が待機を余儀なくされて初めて問題が明らかになります。 進捗報告の遅れ： 現場の進捗は通常、週次で文章や表形式により報告されますが、それらは工程表と直接連携していません。スケジューラーは報告内容を解釈し、どのアクティビティに影響するかを判断し、手作業で工程表を更新する必要があります。この解釈の工程が、遅延、主観的判断、そして誤りを生み出します。工程表が更新された時点では、そのデータはすでに古くなっています。 基準工程の劣化： 厳格な変更管理が行われなければ、遅延を差異として記録する代わりに、基準工程が静かに修正されてしまいます。作業順序が変更され、工期が延長され、現在の工程が「現実に合う」ように論理関係が書き換えられます。その結果、遅延分析、アーンド・バリュー管理、契約上のクレーム分析に必要な基準が失われます。工程表は最新のように見えても、管理基準としての機能を失っています。 クリティカルパスへの視野不足： 数千ものアクティビティを含む複雑なプロジェクトでは、クリティカルパスは単一の経路ではなく、施工の進行とともに変化する複数の準クリティカルパスのネットワークです。特定されたクリティカルパスだけに注目する組織は、余裕時間（フロート）を使い果たした準クリティカルなアクティビティを見落としてしまいます。十分な頻度と深度で工程分析が行われないため、それらのアクティビティがいつの間にかクリティカルになっていても誰も気付かないのです。 適用される分野 建設： ゼネコン、専門工事業者、デザインビルド企業が管理するプロジェクトでは、工種間の施工順序、検査マイルストーン、資材納入、下請業者間の調整によって、重要な依存関係を持つ複雑なアクティビティネットワークが形成され、それらを継続的に監視・管理する必要があります。 海洋・オフショア： プラットフォーム、パイプライン、海底インフラを建設するEPCコントラクターや施工会社では、気象条件による作業可能期間、作業船の利用可能性、製作工程の順序が厳しいスケジュール制約となります。これらのタイミングを逃した場合の影響は非常に大きく、その遅れは数週間ではなく数か月に及ぶこともあります。 造船・修繕： 新造船、改造工事、ドライドック修繕を行う造船所では、鋼構造、艤装、塗装、試運転といった並行する生産工程が統合ポイントで合流し、それがプロジェクト全体の工程およびドック占有スケジュールを決定します。 鉱業・採石： 採掘インフラを整備する鉱業会社や請負業者では、土木工事、機械設備据付、環境関連の試運転が重複して進行します。遠隔地という特殊な条件の下で、重機の動員、気象条件、規制要件など、各プロジェクト固有の制約を管理する必要があります。 プロジェクト型製造業： 受注設計型の設備やモジュールを製造する企業では、設計の確定、資材調達、生産工程の順序、品質確認ポイントが工程上の依存関係を形成し、それらは設計から工場での製造、そして納品まで一連の流れとして管理されます。 よくある誤解 誤解: プロジェクト時間管理はプロジェクトスケジューリングと同じである。 実際: スケジューリングは時間管理を構成する一要素であり、論理的なアクティビティネットワークを作成・維持することを指します。一方、プロジェクト時間管理は、計画、リソース配分、基準工程の設定、進捗監視、差異分析、是正措置、および遅延分析を含む管理サイクル全体を対象とします。管理プロセスを伴わないスケジュールは単なる図表に過ぎず、マネジメントツールではありません。 誤解: プロジェクト開始時に詳細なスケジュールを作成すれば、予定どおりの完了が保証される。 実際: プロジェクト開始時のスケジュールは、生産性、リソースの利用可能性、資材の納入、現場条件に関する前提に基づいた仮説にすぎません。これらはすべて、プロジェクトの実行中に変化します。予定どおりの完了を実現するには、プロジェクトライフサイクル全体を通じて、継続的な進捗監視、差異分析、および是正措置が必要です。重要なのは初期計画の完成度ではなく、継続的な管理プロセスの質です。 誤解: スケジュール遅延は、主にプロジェクトチームの管理範囲外にある外部要因によって発生する。 実際: 外部要因（天候、規制上の遅延、不可抗力など）によって発生する遅延もありますが、スケジュール遅延の大半は内部要因によって引き起こされます。具体的には、不十分なリソース計画、調達判断の遅れ、工種間の調整不足、進捗監視の不備、および是正措置の遅れです。これらは不可抗力によるものではなく、マネジメント上の失敗です。 誤解: 作業を加速すれば、失われた時間は必ず取り戻せる。 実際: 工程短縮（リソースの追加、作業時間の延長、順次実施すべき作業の並行実施など）は、スケジュール回復の中で最もコストが高く、リスクの大きい手法です。これは原価を増加させるだけでなく、品質リスクや安全上の危険を招き、作業の混雑によって生産性の向上効果が相殺されるため、効果は次第に薄れていきます。早期の問題検知と作業順序の見直しは、ほとんどの場合、遅れてから工程を加速するよりも効果的で低コストです。 関連トピック: プロジェクトスケジューリングとは何か？ — プロジェクト期間とクリティカルパスを定義する論理的なアクティビティネットワークを作成し、維持する手法です。 進捗測定とは何か？ — 計画された数量やマイルストーンに対する実際の進捗を客観的に測定する手法です。 プロジェクトライフサイクルの継続性とは何か？ — 入札から施工、そして完了まで、一貫したデータの整合性とトレーサビリティを維持することです。 遅延分析とは何か？ — スケジュール遅延の原因、責任、および影響を特定・分析するための手法です。 関連分野との連携: プロジェクト型ビジネスとは何か？ — 時間が回復不能な資源であり、その使い方がプロジェクトの収益性を直接左右する経済モデルです。 プロジェクト原価管理とは何か？ — 工程の進捗状況や遅延がもたらす財務上の影響を定量化するための管理手法です。 資本プロジェクトにおけるリスク管理とは何か？ — 工程リスクの特定とコンティンジェンシー計画によって、プロジェクトのスケジュールをどのように守るかを扱う管理手法です。 関連インサイト： ProjectVIEW ERPのネイティブコネクタがもたらす力を解き放つ ― 時間と原価を高精度に結び付ける ドライドッキング・ガバナンス ― フリートマネージャーの視点から見る原価・工程・変更管理 建設ERPとは何か？ 最適なソリューションを選ぶための実践ガイド プロジェクト時間管理とは何ですか？ プロジェクト時間管理とは、資本プロジェクトを契約上の工期内に完了させるために必要な作業を計画し、順序付けし、リソースを割り当て、スケジュールを作成し、進捗を監視し、管理するための手法です。これは一度限りの計画作業ではなく、継続的な管理サイクルとして機能し、プロジェクトライフサイクル全体を通じて、工程管理を原価管理、調達管理、およびリスク管理と統合します。 プロジェクト時間管理とプロジェクトスケジューリングの違いは何ですか？ スケジューリングは時間管理を構成する一要素であり、作業の期間と依存関係に基づいて論理的なアクティビティネットワークを作成することを指します。一方、プロジェクト時間管理は、基準工程の設定、進捗監視、差異分析、是正措置、および遅延分析を含む管理サイクル全体を対象とします。管理プロセスを伴わないスケジュールは単なる静的な図に過ぎませんが、時間管理はそれを、プロジェクトを予定どおりに完了させるための動的な管理ツールへと変えます。 プロジェクトスケジュールはなぜ実行段階で機能しなくなるのですか？ プロジェクトスケジュールが機能しなくなる最大の理由は、実際の業務運営と切り離されていることにあります。スケジュールは、原価管理、調達管理、およびリソース管理のシステムとは独立したツール上で作成されます。進捗データは遅れて届き、手作業での解釈が必要となります。リソースの制約はモデル化されておらず、また、遅延は正式に記録されるのではなく吸収されてしまうため、基準工程は徐々に失われていきます。その結果、スケジュールは実行開始からわずか数週間で実態とかけ離れたものになってしまいます。 ERPシステムはプロジェクト時間管理をどのように支援しますか？ 業界特化型ERPは、工程表を原価管理、調達管理、およびリソース管理と単一のシステム上で統合します。ある作業が遅延すると、その原価への影響は直ちに予測へ反映されます。調達への影響は自動的に検知され、リソースの競合も現場に影響が及ぶ前に特定されます。この統合により、工程表は単独の計画書ではなく、リアルタイムで実際の業務状況を反映する統合型の管理ツールへと変わります。 関連資料 関連業界 建設 プロジェクトベースの製造業 海洋・オフショア建設 鉱業・採石 造船・修繕 関連資料 関連ステークホルダー オーナー／デベロッパー E&Pオーナー 船主 鉱山・採石場オーナー コンサルタント ゼネコン 海洋工事請負業者 造船会社 鉱業請負業者 関連資料 関連する役割 Cレベル・エグゼクティブ プロジェクトマネージャー 入札マネージャー 積算担当者 コストコントローラー