PMプロの知恵コーナー
先号　　　次号

ゼネラルなプロ (16)

向後　忠明　[プロフィール]　：2月号
　これまでスキームモデルとシステムモデルの隙間を埋める作業としての入札書(RFP)の作成、提案書の作成そして契約前の交渉について説明してきました。
　今月号はその集大成である契約について説明することとします。
　筆者は入札、提案、交渉、そして契約までの作業は「プロジェクトの死の谷」と考えています。
　しかし、プロジェクトマネジメントに関する書物で、この期間についての記述はP2Mでの関係性マネジメントにわずか記述されているだけです。
　IT産業においてプロジェクトマネジメントにかかわる人の多くはPMBOKの影響も多く、この期間での作業はほとんどが営業の仕事とみられているようです。
　しかし、契約はプロジェクト計画と同様に関係性マネジメントの視点から非常に重要であり、プロジェクトを実行する立場であるプロジェクトマネジャおよびプロジェクト要員には必須の知識であると筆者は思っています。
　“プロジェクトの死の谷”の問題は“ゼネラルなプロ(14)”の＜筆者からの提言＞で言っているような問題も多く生じています。この事実から、何度も述べますが、技術のみならず商務的知識を駆使し、下記に示す3つの作業プロセスに関しても“ゼネラルなプロ”として十分な知識と経験を積んでいく必要があるでしょう。
① 発注者のプロセスであるRFPの作成
② 入札者のプロセスである提案書の作成
③ 発注者及び入札者双方の共同作業である交渉、契約
　このプロセスが“死の谷”と呼ばれる理由にはこのプロセスをオーナ(事業者)である発注者側も請負企業である入札側も重要と心得ているにもかかわらず、
① RFPの曖昧な記述と発注側の姿勢
② 入札側の営業姿勢とプロジェクト実行側との役割分担のミスマッチ等々
によりお互いの思いのすれ違いが生じ、そのまま契約そして実行となるケースが多ことによります。
　その結果、プロジェクトの実行中に多くの変更が発注者側から出され、問題が発生し、限りなく失敗プロジェクトに近づいて行くことになります。
　しかし、入札者側にも曖昧な発注者側のRFPに対してあまりものも言えない状況にあるのも原因ですが、もう少し入札者もプロフェッショナルとしてものを言っても良いような気がします。
　このように発注者・入札者双方ともプロジェクトを成功に導きたい意思を持ちながらも、RFP作成能力の問題、発注者/入札者と言う関係そして入札者側提案フェーズでの体制問題がこのプロセスを“プロジェクトの死の谷”としているのが現状です。
　これまでの説明からもわかるように、RFPから契約までのプロセスの改善を行う事がプロジェクトの成功に大きく近づくことになります。
　このように“死の谷”の最終調整段階としての交渉と契約を上手に乗りこなせる人材も“ゼネラルなプロ”と言うことになります。
　さて、言うまでもなく契約はリスクマネジメントの観点からも重要な行為であり、プロジェクト遂行上のリスクを関係者間で認識し、そのリスクを分担する行為と言っても過言ではありません。
　それ故にプロジェクトやプログラムを遂行する責任者は契約および契約に至るまでのプロセスにも深く関与し、リスクの軽減および除去に注意を払う必要があるのです。
　さらに、プロジェクトやプログラムでのスキル(経験+知識)を持った責任者(ゼネラルなプロ)はこのリスクの軽減や除去については営業担当者より多くの治験を持っているので、事業者(オーナ/発注者)側のリスク分担も必然的に軽減することになり、Win-Winの形で契約をすることができます。
　これにより事業者(オーナ/発注者)および請負企業(受注者)との相互信頼のある契約となり、以降の実行段階でも順調なプロジェクトの遂行が可能となります。
　このことはすでに前月12月号の“交渉”のあり方について述べています。

　契約と言ってもプログラムまたはプロジェクトライフサイクルにおいては関連する各種ステークホルダー(利害関係者)と仕事を進めるうえで各種の契約行為があります。
　ここでは発注者が事業会社(オーナ)でありそのプロジェクトを受注する請負企業(受注者)の関係での合意形成を行う行為としての契約について述べることにします。
　＜注意＞
　 “ゼネラルなプロ(14)”説明した図11-1の説明のプログラムマネジャが幾つかのプロジェクトに分かれて行うケースは事業会社(オーナ)側の社内的な役割分担であり、ここには契約行為はありません。
　
　一般的に、プロジェクトの規模が大きくなればなるほど請負企業の能力によっては同一システムをエリアごとに複数に分けたり、また各サブﾞシステムに分けたりする必要が出てきます。この時の契約条件としてはマルチ方式を取る場合が多いです。
　一方、プロジェクトマネジメント側から見るとマルチ方式はそれだけ関係者も増え，そのインターフェース調整を含めた高度なプロジェクトマネジメントが必要になってきます。
　これは事業会社のプロジェクト遂行能力に十分なものがあればプロジェクトの範囲をプロジェクトの専門性や地域を分割したマルチ方式、または十分な人材または能力がない場合は一括で1社の請負企業(プライム)への発注にする場合の2つのケースがあります。
　表16-1にマルチ方式とプライム方式の特徴を示す。

表 - 1　マルチ方式とプライム方式
項目 マルチ方式 プライム方式
1) 形態
2) 工事完了
　<完了工事>
　<設備管理責任>
　<保証期間>		 各請負企業ごとに工事完了時点が異なる。よって別々の完了テストを行い、設備・システム・ソフト等管理責任の移転が行われるので必然的に保証期限の終りも別々になる。 請負企業の管理化で単一工事完了となり、各サブシステムの完了もプライムの責任で管理。なお保証期間は契約上一本となる。(請負企業が下請負する場合は建業法にかかるのでこのケースは無い)
3) 保険 各々の請負企業がそれぞれ保険契約するので各企業簡にギャップを生じる。 左記の問題も無く単一契約になるのと保険金額も安くなる。
4) パーフォーマンスボンド
　(履行補償)		 各企業が別々にボンドを入れるので、発注者は1社の問題で全体に問題が発生しても他の企業からはボンドの没収は出来ない。 単一なので左記のような問題は無い。
5) 品質性能保証 ここの請負部分の保証はされるがシステム全体の保証はされない。
この場合、発注者のリスクとしては契約書にて専門化の派遣による修理の義務付けをしておく必要がある。		 単一契約なので請負企業がシステム全体の責任を持ち品質性能保証する。
6) 総括 各々の請負企業がそれぞれの与えられた範囲の仕事をするのでそのインターフェースの調整は発注者のリスクとなる。
このため発注者側には高度なプロジェクトマネージメント能力我求められる。		 単一契約ゆえ、マルチケースで行わなければならない調整作業から発注者は開放される。但し、全ての作業を請負企業にゆだねることになるので、業者選定は厳密である必要がある。この選定に失敗したら、マルチ方式よりリスクは大きい。

　上記の過程を経ては発注方針の枠組みを作り、プロジェクトに求める条件の設定を行うわけですが、遂行すべき仕事の範囲や契約の形態、請負方法、契約通貨等によって種々の契約の形があります。下記に関連する契約形態について箇条書きに示します。

＜遂行すべき仕事の範囲別の分類＞
FOB型契約　： 機械／材料等の購入取引に利用される形態で本船渡しの契約であり、機器材料供給メーカーとの売買契約に多く利用される。
CIF型契約　： 上記と同じであるが、船の手配、海上保険を含む現地港渡しで、若干FOB型契約より複雑な手続きがある。
ターンキー契約： 設計、機械供給、建設又は試運転まで含む契約で、キー(Key)を廻すと設備が動き出すような所までの範囲の仕事をする。
メカコン渡し　： 機械的完了を意味し、設備の建設を機械的に完了し、運転の開始の出きる準備までの範囲で仕事を引き渡す
試運転渡し　　： メカコン渡しより一歩踏み込んだ契約で、設備の始動、保証運転までの範囲の仕事で引渡し
訓練、指導付　： 事業会社(発注者)の運転員を訓練、指導する役務までの範囲を含む
ソフトウエアー型契約： 設計、調達、建設監査、試運転指導に関する個々又は全部の役務のみを対象とした契約
IT関連の契約はこの尾部分に相当します。
　上記の契約形態は受注する請負企業と事業会社(発注者)とのプロジェクトの遂行能力にかかわる部分が大きいので、それぞれ自社の供給できる人材、機器材料そして能力等を十分に考慮した上で決定して行くとことが望ましいです。
＜形態別の契約＞
ランプサム契約： 代金を一括で決定し、特別の変更がない限りプロジェクトの完了まで契約事に決まった金額内で全てを実行する契約
(但し、このケースの場合、技術用件及びその他のプロジェクト遂行上の条件が全て決まっている必要がある。)
コストプラスフィー契約： 実績に基づく報酬加算型契約を意味し、プロジェクトの実積に基づき、その都度清算して行く方式であるが、技術条件が未設定でランプサム契約が出来ない場合に利用する契約形態(アジャイルなプロジェクトに適応できる契約形態)
単価契約　　　：
(ユニット)		 技術要件が決まらずに、仕事を請負企業に発注せざる得ない場合、機器材料／人件費等の単金を決めて実績生産して行く契約。運用としては上記のコストプラスフィーと同じ(アジャイルなプロジェクトに適応できる契約形態)
実績償還部分付ランプサム契約：
 発注側も技術要件が決まっていなくかつ早期のプロジェクトスタートを要求し、かつ将来技術要件が決まったところでランプサム契約に切替える契約(アジャイルなプロジェクトに適応できる契約形態)
＜請負方法による分類＞
プライム方式　： 単独でプロジェクトの全ての設備又はシステムを設計、調達、建設、場合によっては設備の運用までの範囲の仕事を一括で請負う方式
マルチ方式　　： 設備又はシステムを建設エリア別又は技術分野別に分割し、数社に発注する方式
コンソーシアム方式　： 数社の請負会社が合意のもとで連携して、プロジェクトを実行する方式(ジョイントベンチャー方式もその1つ)
＜建値通貨による分類＞
円立て契約　　： 契約代金が円決済で行われる。日本側の請負企業にとっては為替リスクは少ない
ドル立て決済　： 契約代金がドル決済で行われる。日本側の請負企業に為替はリスクが出てくるので為替の変動を予測して契約金額を決めて行く必要がある
多通貨建て契約： 多通貨による決済方法であるが一般的には下記のケースが多い
オフショア／オンショア契約　： 請負業者が日本企業であればオフショアポーションは円決済か又はドル決済で、オンショアポーションは事業実施国の現地通貨決済
＜決済時期による分類＞
進捗払い　　　： 契約時に決められた進捗表により実行作業の出来高を計算し、請負企業に支払う方式
スケジュール払い　： 月々又は一定のスケジュールに従った支払い。但し、進捗度合いに関係無くこの契約の場合は支払義務が生じてくる。
＜形態による分類＞
　特命／随意契約および指名入札などあるが読者諸君も知っている通りです。

　契約には上記に示すように多くの種類があります。対象とするプロジェクトの契約をこの中のどの方法を組み合わせて取るかはそのプロジェクトに求められる要求条件、プロジェクトの規模そしてプロジェクトを取巻く環境等々を考慮しながら設定する必要があります。
　ここに示す各種の契約の形を熟知し、対象とするプロジェクトにどれを採用していくかはかなりこの分野に熟達した人でなければ難しいでしょう。
　もちろん、筆者はプログラムやプロジェクトの責任者のみが、いわゆる“死の谷”を一人で乗り越えなければならないとは言っていません。
　営業、法務、そして技術のそれぞれの担当者との連携で、彼らの知恵やアイデアを借り連携して進めていく必要があります。
　なお、プロジェクトの契約方式は一般的に発注者側である事業者(オーナ)が引合書(RFP)にて設定しますが、特に発注者側に指定された契約形態がなければ請負企業側から提案することもできます。また、請負企業も下請けに対しても同様な契約行為もあることからこれらに関する知識を持っていなければなりません。
　もちろん、契約の中身の条文もそれぞれの契約方法で異なることになります。特に重要なのはリスクマネジメントからの観点からの作成が重要となるので、将来リスクもプロジェクトの内容、規模、技術的問題等を考え、契約条文の作成を行う必要があります。

　さて読者諸氏もこの辺で“俺にはこのようなことは無理だよー”と言う人もいるでしょう。
　ところが契約には契約条文だけではありません。引合書(RFP)や提案書でも商務的な記述のほかに技術的な記述もありましたよねー！
　それと同じように契約書にはいろいろな付属書類が必要となるし、また引合書(RFP)などでも要求されます。

　以下にその一例として契約書の全体構成とそこに記述される項目を示します。　ただし、この構成もプロジェクトの特性、規模そして内容によっても変わってきます。

契約書の全体構成とそこに記述される項目

　以上が契約に関する説明ですが、来月号からはいよいよプロジェクトの立ち上げ、計画から実行の話に入ります。
ページトップに戻る