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

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

向後　忠明　[プロフィール]　：12月号
　前月号では曖昧な顧客（ユーザ）要件からの顧客（ユーザ）側と受注側がとる行動についての例について話を進めてきました。顧客要求ミッション（使命）が示された後の顧客（ユーザ）側の行動について述べてみたいと思います。そのミッション（使命）に対して顧客（ユーザ）は以下のような2つのケースを取るでしょう。

  1. ① 顧客（ユーザ）自身は必要十分で確実な要件の設定ができないミッションの場合はコンサルタントに準委任契約（業務委託契約の一種で、特定の業務を行うことを定めた契約のことです。例えばコンサルタントによるコンサルティングサービスに対応）によって、ともに不確定要件要素を極力なくし、求められるミッション要件をさらに固め、「ゼネラルなプロ156」のRFP（Request For Proposal）に示すような項目にて書類を作成し、応札者に提示し競争入札を行い、応札者の評価をRFPに沿って行い、その評価結果の妥当性をさらに応札者との契約交渉を通して一社を選択し、契約書にまとめ調印する。
  2. ② 顧客（ユーザ）側は事前調査により問題のない業者（能力のあるまたは経験のある）を複数選定し、まだ曖昧な状態のミッション要求を提示し、その予定業者に対してまずはプレゼンテーションを要求する。そして、この要求に応じてきた応札者側対して本プロジェクトの実行可能性をこのプレゼンテーションとそこでの質疑応答により検証し、このヒアリングを通して得た情報も採用し、顧客（ユーザ）側の依頼事項を固め、受注予定業者の絞り込みを行います。そして、顧客（ユーザ）側はInstruction to Bidder （入札者への一般的注意事項および勧告）とプレゼンの結果にて知りえた下記に示す条件や要件にて書類を発出し、応札者からのプロポーザルの提出を求め、評価して受注業者を決定し、契約交渉を通じてまとめた契約書作成と調印を行う。

    ＊所掌範囲/作業場所及び条件/作業方法
    ＊技術要件と組織体制/スタッフ
    ＊スケジュールのマイルストーン（完了日）
    ＊支払い方法
    ＊検収及び引き渡し条件
    ＊その他一般的な基本契約条件
    　　　　　　　　　　　　　　　　　等々

　①の場合は典型的なエンジニアリング会社での海外の大型プラント建設プロジェクトにみられる例です。なお、一般的な設備/建物建設プロジェクトでも多く採用されています。顧客（ユーザ）も受注業者もこの種のプロジェクトに多くの経験があり自分たちのテンプレートもあり、場合によってはRFP 等も顧客（ユーザ）自身で準備し、それにしたがって入札を行い、受注業者を決めているケースもあります。なお、この場合の交渉事は主にRFPに従った内容と契約内容の確認が主なものであり、契約交渉の後にランプサム方式での一括請負契約になります。
　契約書類の構成や内容はすでに「ゼネラルなプロ156」で大型プロジェクトのケースを参考に示してあります。なお、小規模またはシステム開発プロジェクトの場合はさらに簡易なものとなります。
　なお、情報処理関連でも要件定義」から「運用」までの一連の工程を、上流から下流まで順番に進めるウオータホール方式の場合でもこの方式が採用されるが、これまで顧客（ユーザ）自身も入札書類（RFPのようなもの）を作成できないケースもあり、詳細な要件が決まらないままでのプロジェクト遂行となりこれが多くの失敗を生む原因となり、最近は②のケースで進めているようです。

　②の場合は以下のような2種類があります。
　入札業者のプレゼンの結果での実績、能力そして提案技術の評価の結果でプロジェクト遂行方法と体制そして支払い条件等々などの確認により1社に発注する。
　この時点では完成時のコストや技術的詳細は不明のままとなるが、プロジェクトの進捗具合により、顧客（ユーザ）と受注業者との話し合いにてプロジェクト体制や計画を提出させ,双方の同意のもとで作業を進める。
　プロジェクトの進め方は「ゼネラルなプロ155」で説明のコストプラス方式が多く採用されます。
　ランプサム（一括請負）方式とコストプラス方式の違いは「ゼネラルなプロ155」を参照してください、ここではコストプラス方式による契約で話をします。
　このケースは契約調印後、人件費、物品購入費、工事の実費（コスト）を実費精算とし、これにあらかじめ合意された報酬（フィー）を加算して支払う契約です。工事においては施工業者のコスト（外注費、材料費、労務費等）とフィー（報酬）をガラス張りで開示する契約方法です。
　このケースは不確定要素が多いため①に示すRFPもなく、顧客（ユーザ）要件が明確になっていないケースであり、この場合はプロジェクトの全体像が見えるまでの期間は人件費やそのほかの機材、経費を顧客（ユーザ）に求め、その期間をコストプラス方式で作業を顧客（ユーザ）と共に要件が設定されるまで進める方法です。
　この場合でもプロジェクトの完了までこの方式で進める場合と基本設計を行い、ある程度プロジェクトの全体像が見えたところで一括請負契約にする場合もあります。
　詳細は「ゼネラルなプロ155」に示すコストプラスフィー方式の利点・欠点を参照してください。
　特に最近アジャイル方式という方式がシステム開発プロジェクトで言われていますがこれもコストプラス方式の一環です。
　「アジャイル方式とは複雑な手続きを排除して小規模なチームで顧客（ユーザ）と受注者間が対面でやり取りにより作業を進めることである」と言っています。
　しかし、アジャイル方式の信条として「複雑な手続きの排除」、「顧客（ユーザ）との協調」「プロセスより個人との対話」、「計画に従うより変化への対応」ということを大事にしているものであるが、この内容から見るとコンサル契約に近い準委任契約となりあまり契約的な縛りがないような方式のように推察されます。
　コストプラス方式も顧客（ユーザ）との対話を重視したものであり、委任契約にのっとって顧客（ユーザ）は契約に至るまでの間、先にも述べたようなプレゼンなどを通して、発注先の能力の確認の後に各種条件設定を行いながら進める方式です。
　よってアジャイルもコストプラス方式の一環であるが、どちらの場合も顧客（ユーザ）と受注者の信頼関係で作業を進めることになります。しかし、一番重要なことは作業途中では「走りながら考える」手法なので問題は必ず発生します。その問題解決にあたっての処理の「決断」はだれがするのかまた責任は？といったことが必ず生じます。この場合は受注者側のプロマネに大きな負担が生じることにもなり、プロジェクト遂行に関する条件を含む契約書があいまいなままでは問題発生の場合、大きなリスクとなります。
　契約の趣旨は「思いもよらない事象に対するリスク回避」に対する顧客（ユーザ）及び受注者側の双方にとっても有用であり、筆者としてはどのような場合でも実行業務の初めには双方納得のいく約束事として重要と思っています。
　よって、この方式の場合は「契約交渉よりも顧客との協調」を重要視する手法なので契約書を前提としたこれまで述べてきたコストプラス方式の進め方とは異なるようであり、どちらかというとリスク回避、除去の面では仕事の進め方においてアジャイル方式は少し危険を伴うプロジェクトの運営方法と筆者は感じています。

　来月は不確定要件のコストプラス契約で途中から基本設計後に一括契約にしたケースの金融系のシステム開発の契約書の事例を示し、その中での一般的な条項と内容について説明していきます。
ページトップに戻る