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

ゼネラルなプロ (153) (プロジェクトマネジメントと契約)

向後 忠明 [プロフィール] :7月号

 これまでリスクマネジメント、およびそのマネジメントサイクルの中で起きる可能性のあるリスクとその対応について下記のようにA、B、C、Dに選別してその対応策について説明してきました。
A:原因の除去、特定脅威の回避
B:リスク事象の移転
C:リスク影響の軽減と分担
D:リスク影響の受容
 
 前月号におけるマネジメントサイクルでの各フェーズで示されたリスク特定と対応策ごとの選別により次のようなことが分かります。
 
  1. ① リスクの特定
    起こると予想されるどの事象がリスクとしてプロジェクト業務のどこに影響を与えるかをPJ特性と自社・自分の経験の有無、技術、自分を取り巻く人材や協力会社の特性等々を考慮し、過去のデータベースやベテランの意見を聞きながらその特定作業を行います。
  2. ② リスクの影響
    そのリスクがどの程度の確率で起こり得るか、そして、どの程度の影響力を持つかをプロジェクト初期で特定し、契約条件、保険及びその他プロジェクト特性への対応策を示し、契約書及び関連付属書にて対処することが必要です。
  3. ③ 不確定な要件
    プロジェクトでの不確定要件に対する顧客(ユーザ)の求める目指すべき姿の検討の甘さや、それに対する対応の甘さが原因となり大きなリスクを招くことが多くみられます。特に、プロジェクト開始時での詰めの甘さがリスク発生とその影響が最大となることが良くわかります。すなわち、外的リスクやプロジェクトチームの統制や影響の及ばないリスクもその範疇に入ります。プロジェクトの規模が大きく、特に海外プロジェクトの場合はリスク事象の増大はさらに多くなります。

 例えば、特に以下のようなことが考えられます。
  1. ① 経済変動及び市場変動さらに新たな市場要請への進出等予期しない出来事への対応でこれまでの経験知識の及ばない範疇のリスク、すなわち不確実性への対応には契約知識への対応能力が必要となることも多いです。特に海外事案におけるカントリーリスク等への対応を含めた問題には交渉能力も必要となります。
  2. ② 為替の変動や金融関係にかかわる基礎知識を少なくともプロジェクトをリードする人たちが持っていなければならない。例えば為替変動などは提案時に為替ヘッジなども考慮したうえで常に為替レートを気にしながら対応していく必要もあります。このような予期できぬ事象に対しても契約条項での抑えとファイナンス関係での対応が必要となります。
  3. ③ 特に海外事案におけるカントリーリスクは会社としても対応が無理なケースもあり、このような場合は契約書に示される不可抗力の対応策となります。このような場合はプロマネ判断での対応が困難となりうるので法律家(弁護士)を入れた対応が必要となるでしょう。
  4. ④ 一方プロジェクト規模が大きくなると一社だけでの対応では無理があり、必ずそれに見合った体制作りと協力企業間での契約事項が発生し、プロジェクトの相互運営の在り方や技術的インターフェース及び業務遂行上で発生する各種不都合への対応においても契約に関連した対処が必要となります。

 外的リスクについては前月号にて簡単にその対応策を示したが、このような事態をプロジェクト初期時点で未然に防ぐのは難しく、いわゆる暗黙知(個人の経験や勘に基づくような内容を簡単に言語化できない知識)でもあり、提案時ではすべて網羅することは困難です。このような場合頼りになるのが提案時における契約でありその知識です。
 今月号から契約についてプロジェクマネジメントで「契約がどのように関係してくるか?」について話をしてみたいと思います。

 昨今のイノベーションに関係するITを含む各産業でもその対応には定常の業務から外れたプロジェクトマネジメントといったビジネス手法が必要となります。
 このビジネス手法にはエンジニアリングに対応する技術だけではなく人間の知恵や知識を組み合わせた「人の知識と技術の総和」といった組み合わせが重要となり、それによりプロジェクト要求に柔軟に対応し、ソリューションを行うことが要求されます。
 ここで言う技術や人間の知恵や知識にはプロマネ個人ですべて賄うことは不可能であり、プロジェクト特性を考慮した適正人材の組織への導入が必要です。
 その人材の中には契約、ファイナンス & コスト、保険、貿易実務及び調達等々の知識を持った人材リソースも含まれます。プロマネはこれらの人材を適切に利用する能力や関連する基本的知識を持っている必要があり、これら人材の知恵や知識を有効に活用していくことが重要になります。
 ここで言う「エンジニアリング」という言葉はプラント関連事業に限らず、IT 系事業、建設系事業、公共インフラ事業その他各種産業においても多くの関連リソースの最大利用により実施されるソリューションビジネスと同義語となります。
 ソリューションの各種事業にかかわるプロジェクトでは必ず契約というものを介在してプロジェクトが進められます。
 今回はプロジェクトがスタートする前からの顧客(ユーザ)とプロジェクト実行側(請負)の一般的な役割分担とプロジェクト実現までの過程を含めながら契約について述べていきます。この契約というものにもその種類は多く、内容も多岐にわたり、関連する用語も膨大となります。
 ここでエンジニアリング産業において多く利用されている標準的な契約約款としてエンジニアリング振興協会が1992年に発刊したENAA モデルというものがあります。
 一方、国際的に利用されているものとしてはFIDICといった契約約款があり、これは国際協力機構(JICA)、世界銀行(WB)、アジア開発銀行(ADB)などの国際融資機関の入札図書のサンプルにも組み込まれているものであり、国際建設契約のディファクトスタンダードとして広く使用されています。
 この二つの約款がこれまでプラントエンジニアリングや建設業界で参考にされていました。この約款はプロジェクト開始時においてどのような業界においても必要なもので、この約款には多くのリスク回避に必要な条項が含まれているので、そこに示されている約款の内容を基本的知識として理解したうえでプロジェクト計画を立てるとよいと思います。このようなこともリスク対応策の一つと言えます。
 なお、上記の2つの契約約款や運用方法についてはここでは詳述しませんが、プロマネを志向する人は一度は目を通してそこに示される各条項を理解しておく必要があります。

 次に昨今のプロジェクトマネジメント業界の外部環境がVUCA(ブーカ、Volatility(変動性)、Uncertainty(不確実性)、Complexity(複雑性)、Ambiguity(曖昧性))という言葉に代表される目まぐるしく変転する予測困難な状況となっていて、課題解決型ミッションが、プロジェクト目的としての要求として多くなってきています。
 すなわち、プロジェクトの提案や契約の段階でいろいろと知恵を働かす必要がこれまで以上に多くなってきていてそれだけにリスク事象とその対応といったものが、より多くなってきています。
 この事象に対応する提案型プロジェクトの遂行手法として「アジャイル」といった用語が使われています。これは顧客(ユーザ側)及び請負側が共同にてプロジェクト要求要件を形成していきプロジェクトを進めていく方法であり、プロジェクトの具体的仕様が設定されるまでコストや設計仕様が決まらないようなケースです。
 このような現象は先にも述べたように提案時に発生することであり、提案内容(提案組織、適用技術、提案コスト、具体的目標)が全く分からない状況であり、このような場合に適用する方法には以下の2種類があります。
  1. ① コストプラスフィー方式
    工事の実費(コスト)を実費精算とし、これにあらかじめ合意された報酬(フィー)を加算して支払う契約。工事においては施工業者のコスト(外注費、材料費、労務費等)とフィー(報酬)をガラス張りで開示する契約方法
  2. ② レインバーサブル方式(実費償還)
    受注者が顧客(ユーザ)の代行者としてプロジェクトを遂行・マネジメントし、発注者がコストを含めた責任を負うパターンで、コスト・レインバース契約と言います。 顧客(ユーザ)は、アサインメンバー1人1人に高水準での業務遂行と、説明責任を常に求めます。本契約と①は同じであるが、扱いが①と少し異なりかなり高度なマネジメントが必要となる。

 ①と②は要件が明確になるまでプロジェクトの全体像が見えないので見えるまでの期間は人件費やそのほかの機材、経費を顧客に期間(毎月)を決めて提案する方法です。以降はコストプラスフィー契約を中心に説明していきます。
 その他に③としてランプサム方式というのがありますが、顧客要求が明確であり、顧客(ユーザ)から与えられたRFP(Request For Proposal)に従い提案書をプロジェクト計画、提案コスト、提案技術そしてプロジェクト目標を明確に示し、この提案書に従い付帯する契約書に従い責任をもってプロジェクトを完遂する方法です。
 これまでは③に示す方法が最も一般的であったが、①及び②の結果で生成された顧客(ユーザ)条件や仕様そして技術仕様が明確になったプロジェクト要件をベースにランプサム方式にてプロジェクトを進めるやり方もあります。
 昨今のプロジェクト環境の変化に伴い①及び②でプロジェクトを進めなければならないすなわち、顧客(ユーザ)要件設定がないままプロジェクトが進められるケースが特にIT 業界では多くなっています。これは顧客側(ユーザー側)に問題がありこれを請負側がうまく対応できないことにも原因があります。
 特に、金融系のプロジェクトではプロジェクト完了後での支払いとなり、双方とも目標設定もできないままでのプロジェクト実行となり、大きなリスクを負ってのプロジェクトとなっているケースもあります。そこで考えられた方法が先にも述べた請負方法ですが、この方法は顧客側(ユーザー側)および請負側にとっても有効な方法と思います。

 次月号ではプロジェクトの流れに沿って請負側(受注者側)の立場からの契約の類型について話をしていきますが、請負の範囲によっては上記に述べたように契約形態も変わってきます。契約は上記に示したものだけではなくコマーシャル面での様々な要因を考慮の上、最適の形態が選ばれることになります。

ページトップに戻る