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

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

向後　忠明　[プロフィール]　：1月号
　今月号からはコストプラス契約の事例として基本設計後に一括契約にした金融系システム開発の契約書を取り上げ、その中の一般的な契約条項とその内容について説明していきます。
　本事例は顧客側（ユーザ）側にとっても初めてのシステム開発であり、これまの人力やドキュメントでのやり取りを本社・支社そしてほかの関係機関を含めた全工程をデジタル化して運用の効率化を図るというもので、顧客側（ユーザ）の具体的要件はありませんでした。
　なお、本件は海外の案件ですがシステム開発の方法は日本とはあまり違いはないものの、システム開発においての重要な要素であるコミュニケーションという観点で大きな障壁がありました。もう一つ、ここで参考に言っておきたいことは人種、国柄、習慣の違いからくる問題にも気を付けなければならないということです。
　海外におけるシステム開発プロジェクトの多くはビジネス環境や人種そして言語も異なり、日本国内でのプロジェクトに比べその困難さは倍加します。海外プロジェクト特有のリスク回避に必要な「予測できない」事象を考慮しなければなりません。すなわち契約書の必要性が顧客（ユーザ）も含め双方に重要な項目となります。
　契約書の準備もなく海外関連プロジェクトを進めようとする考えはシステム開発関連に限らずすべてのプロジェクトで捨てなければなりません。「複雑な手続きの排除」「顧客（ユーザ）との協調」「プロセスより個人との対話」「計画に従うより変化への対応」の方式を特徴とするアジャイル型プロジェクトも例外ではありません。
　特に日本人は「性善説」に立った仕事のやり方ですが、相手方の思考や習慣も異なることからどうしても疑いの目で見るといった少し言い方がきついですが性悪説に立つ必要があり、海外プロジェクトではこのようなリスクも考えていかなければなりません。
　それゆえに契約書というものが重要となります。
　このプロジェクトは冒頭にも述べたように技術的顧客（ユーザ）要件も明確でなく、関連機関をもネットワークで結ぶシステムとしての基盤状況もわからないものでした。
　このように日本におけるシステム開発関連プロジェクトに比較しても関連機関も多く規模も大きく多様な技術も必要とされる内容となっています。
　上記で述べてきたプロジェクトは前月号で説明した②のケースのプロジェクトであり、まだ顧客（ユーザ）要件が完全でないままの受注予定業者を招請するケースです。
　この場合は前月号でも説明したように本プロジェクトに必要な経験や実行能力を見るためのプレゼンテーションとその後のヒアリングから始める対象のものでした。このヒアリングの目的は顧客（ユーザ）側がこのヒアリングを通して、これまで曖昧であった顧客（ユーザ）依頼事項を固めると同時に、受注予定業者の対象業務に対する実行可能性を確認することを目的としたものです。
　上記の結果をもって顧客（ユーザ）からさらにメールにて各種質問が発出され、さらに以前より具体的な質問となり、日本での今回と類似する仕事の経験の詳細や既存類似システム等についての質疑応答も行われました。そして、その質疑応答の結果をまとめた内容を含めて受注予定業者数社に対して正式な契約を前提とした書類をプロポーサル形式にて提出するよう依頼がありました。
　当初これまで請負契約に慣れていた当社はどのようなプロポーザルを出すべきか社内で議論した結果、まだ顧客（ユーザ）要件が不確定であったこともありStep By Step で作業を進めることを前提としたプロジェクトの進め方と提案システム概要、そして役割分担や実績、支払い方法等々を示した第一回目のプロポーザルを提出しました。
　その内容は以下に示すようなもので、契約ドラフトとしてプロポーザルを作成提出し、顧客（ユーザ）の承認をもらい、正式な契約書として顧客（ユーザ）に提出しました。
  1. 1．サマリー
    本契約書の全体構成についての説明
  2. 2．提案システムの概要
    提案システムの概要と今後の考察
  3. 3．システム開発ステップとその期間
    各ステップでの作業内容
    例えばStep 1は master plan, Basic Plan Step2 はDetail design 等々
  4. 4．プロジェクト組織とスタッフ
  5. 5．コンサルテーションコスト
    各スタッフの月別及び日別コスト（コストプラス）及びStep 1 の担当期間 及び全工程のStep 2までのManingコスト
  6. 6．プロジェクト投資コスト
    経験上から推定されるプロジェクト完成までの投資コスト
  7. 7．Terms and Conditions（契約約款）
  1. ① 目的
    以下の条件は顧客及び受注者が本プロジェクト遂行にあたって守るべき条件を記したもので、両者サインの真正を表示した契約条件として効力を発生するものである。
  2. ② 定義 (Interpretation )
    所掌範囲、プロジェクトチーム、作業スケジュール（Working Schedule ）、契約金額、支払い条件、顧客側便宜供与、作業時間、作業場所、作業報告、契約発効、作業開始日、責任（liability）秘密保持、作業の一時停止(Suspension )と終了(Termination) 、責任 (Responsibility)、変更（Variation）、契約不履行（default）、不可抗力(force majeure) 、不履行（default）、瑕疵担保と損害賠償、 紛争の解決（settlement of Dispute）、法律対象国と言語（本件は日本のプロジェクトの場合は対象外となる）

　以上が事例での外国におけるプロジェクトの契約書の概要である。なお、契約約款と言われる部分はTerms and Conditions (契約条件)の部分であり実際の一括請負契約の大型建設関連プロジェクトではさらに約款条文はもっと種類も多くなります。なお、日本におけるシステム開発ではこの程度で十分であると思います。Terms and Conditions（契約約款）はプロジェクトの内容によって追加または削除されるものもありますが、むしろ社内法務や弁護士とよく相談する必要があります。
　なお、本プロジェクトは途中までは純粋なコストプラスフィー契約であり、その後基本設計が終了した時点でプロジェクト全体像が明確となり大きな変更が見られないようになったので請負契約型にしたものです。
　ここで少し読者も疑問に思うが、契約書の下記に示す5及び6にプロジェクトの全工程にかかわるコンサルテーションコスト及びプロジェクト投資コストがプロジェクト全体の仕様が明確になっていない前に示されていることだと思います。この項目の提示はかなり反論しましたが、請負側の実績や経験を判断するためのものであり、かなり幅を持たせた推定の数字で良いということで合意し契約書に記載しました。
　なお、5のコンサルテーションコストは各スタッフの月別及び日別コスト（コストプラス）及びStep 1 の担当期間 、そしてStep 2までの全工程のManingコストを示す。
　また、6のプロジェクト投資コストは経験上から推定されるプロジェクト完成までの投資コストであり、顧客（ユーザ）の強い要求と競争入札相手がすでにパッケージとして本プロジェクトの入札に参加してきているとの情報もあり日本での経験から算出したが概算数字です。
　この請負業者として上記のようなプロジェクトと同じような未経験の分野で曖昧な顧客（ユーザ）要求があった場合はリスク回避の意味でもこの応札に一括請負契約で参加しないことを推奨します。その場合は必ず要件が固まり、正確なプロジェクトコストが算出できるまでコストプラス方式でその後一括請負契約にする方法をとることを進めます。
　契約したら守らなければならないので顧客（ユーザ）よりの依頼が来たらその要求内容をよく見て、自社の能力及び経験そして人材を見渡し、自社の強みがどこにあり、　顧客（ユーザ）要求内容のどこに問題があるかをよく判断してそのプロジェクトへのアプローチを判断していくことが大事かと思います。

　これまでの話では、主に契約方式のうちで顧客要求に対応する請負側として最も多くそして重要なプロジェクトの価格設定においての価格形態別のものを対象として話をしてきました。
　この形態以外にも契約対象となる顧客（ユーザ）及び請負側の事情を考慮した契約の形態があります。
　その形態を決めるためには①請負業者の能力、②顧客（ユーザ）の能力、③技術条件の度合い、④完了時点のリスクの度合い、⑤研修引き渡しの条件等々を考慮する必要があります。
　今回の説明の方式はコストプラス方式やレインバーサブル方式そして一括請負契約方式のものであるが、そのほかに、仕事の範囲別の請負方式による契約、建値通貨による契約、成約形態（匿名、随意契約）による契約等があります。
　これらにはプロジェクトに求められる様々な因子を考慮する必要があります。そのため各種契約は仕事の進め方やプロジェクト規模そして国内または海外のプロジェクトにより上記に示す契約形態を組み合わせて設定する必要がある。

　来月号はこれまでプロジェクトには対価形態以外にどのようなものがあるか参考に説明し、最後に今月号の事例にあるTerms and Conditions（契約約款）とForm of Agreement（契約様式）の関係について話をしていきたいと思います。
ページトップに戻る