プラント建設では，応札者であるエンジニアリング会社は，見積提案書をRFP(提案依頼書）に記載された期限までに，オーナー（発注者）に提出します。その見積提案書は通常，次の3部構成となります。

（1）金額や支払い条件を記載する「見積書（Quotation）」
（2）提供する成果物の範囲と技術的な内容を記載する「技術提案書（Technical Proposal）」
（3）プロジェクトの進め方を記載する「プロジェクト遂行手順書（Project Execution Procedure）」

　プロジェクト遂行手順書は「コーディネーション・プロシジャ（Coordination Procedure）」と呼ぶこともあります。また，見積書とプロジェクト遂行手順書を組み合わせて，営業提案書（Commercial Proposal）として提出することもあります。

　プロジェクト遂行手順書は，プラント建設におけるプロジェクトマネジメントでは極めて重要な書類です。今回は，システム開発ではあまり馴染みがない，プロジェクト遂行手順書について解説しましょう。

定額請負契約と実費償還型契約

　プロジェクト遂行手順書の説明に入る前に，契約形態の話をしておきましょう。プロジェクト遂行手順書は，契約形態ともかかわってくるからです。

　前回も触れましたが，プラント建設では，RFPの中に契約書のドラフトが含まれています。このため，契約形態は非常に明解です。プラント建設では，契約形態には大きく次の2種類があります。

（1）定額請負（Lump-Sum）契約
（2）実費償還型（Cost Reimburse）契約

　「定額請負契約」(民法上の請負契約）は，RFPで規定されている設計から機器資材の調達，現地工事などの「一式すべて」を一定の金額で受注するものです。プロジェクト遂行途中で，コストが当初の見積もりと違ってきても，スケジュールが遅れて人件費の費用がかさんでも，基本的にはコントラクター（受注者）が負担します。これは，システム開発でも多い契約形態です。

　「実費償還型契約」(民法上の委任契約）は，コントラクターが，かかった費用をすべてオーナーに請求するものです。設計などの人件費は固定にしておき，コントラクターが購入する機材や工事費は実費で請求する契約と，人件費まで含めて実費を請求する契約の2種類があります。前者を「コスト・プラスフィー契約」と呼びます。実費償還型契約(委任契約）は，システム開発では要件定義や外部設計のように，仕様が決まりにくいフェーズで適用されます。

　ちなみに，プラント建設は完成まで数年かかるのが普通で，その間に何が起こるか分からないというリスクがあります。このため，欧米では実費償還型契約が主流でした。コントラクターとしては，仕様が途中で変わるかもしれないリスクやインフレで機材購入費や人件費が上がるかもしれないリスクは取れない---という考え方が常識だったからです。そこに日本のエンジニアリング会社が定額請負契約で参入し，世界のシェアを伸ばしてきました。オーナーにしてみれば投資額を発注時に確定できるので，そちらが好ましいに決まっています。

定額請負契約では，リスクを見込んで見積額を提示する

　定額請負契約では，応札者であるエンジニアリング会社が，ある程度コスト変動のリスクを読み，それを見込んで見積額を提示することが前提となります。

　更地にプラントを建設する「グラスルーツ・プロジェクト」の場合は，経験からリスクがある程度読めるため，日本のエンジニアリング会社は，定額請負契約で受注しても成功裏にプロジェクトを遂行できました。しかし，「改造プロジェクト」の場合は，既存環境にどんなリスクが存在するのかよく読めません。このため，内情に詳しいエンジニアリング会社が有利になりますし，内情に詳しくない会社は見積提示前の詳細な現地調査が欠かせません。

　よく問題になるのが，既存設備との接続です。通常は，接続する配管やケーブル，接続方法などの接続条件がRFPで明示されますが，明示されない場合は，応札者が見積書に接続条件を明示します。

　前回にも述べましたが，システム開発のほとんどは「改造プロジェクト」です。しかし，既存システムとの接続条件があいまいなまま，開発を進めることが多いのではないでしょうか。そのため開発コストが膨らみ，追加コストをユーザーとベンダーのどちらが負担するかで揉めることがままあります。

　システム開発でもプラント建設と同じように，ユーザー企業が既存システムとの接続条件をRFPに明示すれば，開発途中での思い違いによるトラブルはかなり防げると思います。RFPに明示されていない場合は，応札者が見積書の中で，既存システムとの接続条件（把握している接続個所，仕様，接続方法，かかる費用概算や開発スケジュールなど）を明示すれば，元請けベンダーはユーザー企業の過大な要求を防御できるはずです。