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

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

向後　忠明　[プロフィール]　：11月号
　前月号の段階で受注予定業者の作成した契約書類の作成が終わり顧客（ユーザ）とその内容についての話し会いとなります。これが契約交渉です。

　契約交渉とは、取引先となる顧客と受注予定業者との間で条件のすり合わせを面対で行うことであり、この結果を契約書にまとめ、合意するまでの一連の過程です。 契約では取引の目的となる商品やサービスの内容、価格のほか、問題が発生した際の対処方法などについても決めるものであり、この時点での話し合いが契約締結で最も重要な時期です。
　すなわち、ここでの話し合いは前月号で説明した顧客（ユーザ）要求のRFPと受注予定業者が提出したプロポーザルとの照合ですが主に各種提案条件、技術的内容の確認、所掌範囲、スケジュールの確認や調整を行い、顧客（ユーザ）の要求する条件に極力近づけることで実質応札金額の実質値下げを交渉する場でもあります。
　この契約交渉時の内容から見てもわかるように双方の代表はこのプロジェクトを最後まで管理監督する人であり受注側はいわゆるプロジェクトマネジャ（以降プロマネという）が中心となります。顧客接触での中心は営業であり話が具体的になったら営業の独走を許さないように実プロジェクトの経験を持つプロマネが介在する必要があります。これもリスク回避の一手段でもあります。
　よって契約にはあまりプロマネが介在するものではないという考え方は捨てたほうが良いと思います。

　なお、契約交渉に至るまでの道筋は顧客要請内容の違いによって、業務委託契約の方法は異なり大きく下記の3つに分かれます。
  1. ① 請負契約（ランプサム方式による一括請負契約と同義語）
  2. ② 委任契約（レインバーサブル方式によるコストプラスフィー契約と同義語）
  3. ③ 委任契約と請負契約の切り替えタイミングによる契約切り替え
ランプサム方式による一括請負契約及びレインバーサブル方式によるコストプラスフィー契約の違いについてはすでにゼネラルなプロ155で説明していますのでここでの説明は割愛します。

　ゼネラルなプロ154にて受注契約の類型について話をしたようにリスク回避のための契約ではでき得る限り顧客（ユーザ）は詳細なRFPを作成し、受注側はそれに従ってプロポーザルを提出し、その後の交渉を通じて契約書を相互に確認し、調印し、実行作業に入ることになります。しかし、実際は顧客（ユーザ）側にとってはここに至るまでは時間と金も意外とかかるものであり、かつ昨今求められる顧客（ユーザ）要求にもビジネス環境からの業務変革（イノベーション）を求める内容のものが多く、多様な契約手法が求められるようになっている。
　このような状況下での顧客（ユーザ）側の立場からの契約に到達するまでの経緯と受注側との関係について説明して行きます。

　顧客（ユーザ）自身がはっきりした要件を示すことができず対象となる業務が明確な方向性のないままでは受注予定業者側もその業務を受けることはできません。

　業務要件発祥時点は、顧客（ユーザ）側は経営上層部の企業戦略すなわち社会環境、自社の環境、市場を展望し中長期的視点に企業のあるべき姿をデザインすることから始まります。このデザインをもとに顧客（ユーザ）側の「何をやりたいのか、またはある程度こうしたいという意思」を企画関連部門、またはその配下が経営者の方針に沿った課題を整理し、例えばゼネラルなプロ136でも説明した下記のどれに相当するかを顧客（ユーザ）社内で検討し、顧客（ユーザ）側の不確定ではあるが顧客要求といったミッション（使命）の方向性を示します。

　これが顧客（ユーザ）側の不確定要素を含む対受注予定業者に提示するミッション（使命）となります。
  1. ① 確実に見通せるソリューション（技術革新などの方向の見えるトレンド）
  2. ② ほかの可能性のあるソリューション（現状からの脱皮、多様性への対応）
  3. ③ 可能性の範囲が見える将来（新規技術による既存業務のイノベーション）

　しかし、上記のどれもが「ビジネス環境からの業務変革」に対応するものであり、例えば業務のIT 化（DX：情報戦略）、SDGs（環境問題）等に相当するものは会社の風土、組織構造等に大きな変革をもたらすもので戦略課題は経営や技術革新要求からくる現状からの脱皮といったソリューションとなります。よって、昨今の企業トップに想定される思考の多くはこれに相当するものであり、その結果として上記の①②③に関係し、求められているミッションもそれに相当するものと考えられます。
　顧客（ユーザ）側担当者の行動も経営層からの指示をそれに対応した体制を作り①②③のどれに相当する提案であるかを明確にしてから受注予定業者に仕事を依頼することになります。
　これまではこの種の経営層からの要請は顧客（ユーザ）の企画部門や委任したコンサルタント会社がその経営層からの要請を理解し、その解決策の立案を社内において検討してもらい、その結果を顧客（ユーザ）側の要件内容に落とし込み、受注業者に依頼することが多いと聞いています。
　しかし、それでも実行段階において多くの変更や顧客との思いや考え方との不一致から実際作業を進めてみると「ずれ」が生じ、やり直しや変更が多く発生し、結果として多くの失敗プロジェクトが発生したことが情報処理系の文献に書かれていました。

　このような手段をとったことを想像すると顧客（ユーザ）は自社自身で実行作業にあって具体的作業（プロジェクトマネジメント、設計、資材調達、テスト、試運転）に関する具体的要件すなわちRFP を準備するまでの時間的余裕もなくまた能力にも限界があり、どうしても抽象的で曖昧な要件により受注業者に依頼することになります。特に情報処理にかかわるプロジェクトではこのケースが多く、受注する側もこのような超上流の顧客側の望む企画的作業の対応に慣れていなかったことで多くの失敗プロジェクトが排出されました。

　情報処理系に限らず、昨今の顧客（ユーザ）側からのミッションの多くは顧客（ユーザ）側企業が抱えている問題（課題）であり、これを受注側が何とか具体化しその課題を解決していこうといった「問題へのアプローチ」を行い、「何が、なぜどのような問題」か、しっかりつかんで整理構造化していかなければならないプロジェクトが多くなっています。
　そのため、このような要件が曖昧な内容の仕事を受けるにあたっても受注側も「何をどうするのか」と迷ってしまうのが普通です。受注側は顧客（ユーザ）の思いを受けて、同じ土俵でこのミッション課題を「一体、何が、なぜ、どのように、問題なのかしっかりつかみ整理、構造化する（これをP2Mではスキームモデルと称する）ことが可能にならなければなりません。すなわち、この場合はミッションの作成経緯を知っている顧客（ユーザ）と共に与えられたミッションの紐とき（解決）を行い、最終的な要件固めを行う必要がある。
　一方、顧客（ユーザ）側から見てもコンサル企業と受注企業と2段階の入札そして契約は時間がかかり、また余分な労力やコストもかかること、また一方のコンサル企業にも上記のスキームモデル、例えば情報処理関係では詳細設計、プログラム・システム総合テスト（システムモデル）までを一気通貫で顧客が要求することもあり、これまでの既存の受注企業との競争も出てきているようです。
　まさにP2Mでのミッションプロファイルから始まるスキームモデルによって設定された具体的プロジェクト要件を設定し、これをベースにしたプロジェクト計画をもとにPDCAを回したプロジェクトマネジメント手法によりシステムモデルまたはサービスモデルの一部（試運転、）までを一貫して進めることで受注企業側も顧客（ユーザ）に売り込みをするようになっているようです。

　さて、それでは具体的にどのような契約形態で顧客（ユーザ）は受注業者にこの曖昧な要件を含むミッションをお願いすることになるのでしょうか？
　本件は前記したように「顧客側（ユーザ）の要件は顧客（ユーザ）自身が抱えている問題（課題）であり、これを「何が、なぜどのような問題」か、しっかりつかんで整理構造化する。」ことが必要です。そしてその検証結果を文書化し、最初は受注企業を指名し競争入札の形をとることになります。
　しかし、コンサル会社を経由しないで直接受注企業に上記に示すような条件にて引き合いを行っても、入札にあたっては各社ばらばらのプロポーザルとなり業者の選定もできないことになります。
　そこで最初から入札という形をとらず、まずは彼らに曖昧要件ではあるが条件の概要と作業内容を要求内容に適応できると考えられる各業者にInvitation Letterを発出し まずはプレゼンテーションン行わせ、有望な数社を選ぶことになります。

　ここまでが顧客（ユーザ）側の最初の行動ですが、この要請を受けて受注予定業者側は顧客（ユーザ）の案件情報を営業が入手し、担当部署にて顧客情報を分析し、人選と関係人材を集め、対応可能性分析を行います。
　当然、受注側も案件の複雑さ、規模感そして難易度をプロジェクト遂行部門またはPMO担当と相談し、顧客（ユーザ）側と接触を図り、必要な確認などを取るための打ち合わせを行います。

　ここでプレゼンテーションのあり方について簡単に解説します。
　受注側のプレゼンテーションは上記の①②③の項目にのっとった顧客（ユーザ）側のまだ曖昧と思われるミッションを「何が、なぜどのような問題」か、しっかりつかんで整理構造化するまでの受注会社の想定するスキーム作りと要件の具体化までの作業概要の説明をします。さらに具体的にその目標を達成するためのプロジェクトマネジメントにかかわる実行計画までを示します。
　すなわち一気通貫でのスキーム作りから、それによって整理整頓された目標達成のためのプロジェクトマネジメントを具体的に示すことが必要です。この時は、現実的問題解決を前提とし、限られた情報をもとに顧客の問題点をプロファイルし、大まかに整理し、施策や行動指針の方向性を強調する必要があります。
　このように一気通貫で顧客要求の思いや考えを捉え、最後まで効果的に目標を達成するプロジェクトマネジメントの実行能力をプレゼンにて説明し、聞き手に関心を持たせ、また興味がわくようにすることが必要です。また、最後に質問などを顧客（ユーザ）側に発信し、質疑応答に入れるような状態に持っていく、それにより聞き手が内容を理解してくれたかどうかを確認することもできます。
　なお、ここでのやり取り、すなわちコミュニケーションを営業と共にプロマネは最大限発揮し、プレゼン後も密に顧客（ユーザ）との関係を保っておく必要があります。
　すなわち、ここまでの段階は顧客側及び受注側の質疑応答も含めこれからの契約に大きく影響するものであり、一種の契約の前哨戦の交渉といってもよいでしょう。
　以上のような経緯を通してプレゼンの結果の良し悪しを顧客（ユーザ）が検証した結果としてその意向を証明する Letter of Intent（LOI）を受注予定企業に提出することになります。
　以上のような過程を通して受注業者の選定がされます。なお、ここまでの作業は一般的に受注側から見ると受注活動の一環であり、すべてのコストは受注側持ちとなります。

　来月号は Letter of intent後の実際の作業と顧客（ユーザ）と受注側の契約のあり方とその違いなどについて話をして行きます。
ページトップに戻る