カスタマとベンダ間で責任分担を明確化しておくための契約および危機管理プラン
例えば『Wisconsin State Journal』で取り上げられた、ウィスコンシン州の管理当局とその契約ベンダとの間で生じた事件も、こうした問題の一例である。これは、サーバおよび付属サービスのインストールに関する約700万ドルの契約において、州側が最終金180万ドルの支払いを差し止めたという事件であった。
この契約においてベンダは、一連の到達目標を達成するごとに、該当する報酬が支払われるものとされていた。州側の主張は、この契約条項をコントラクタ側が履行できなかったため、同社との契約を打ち切ることでプロジェクト達成に必要な責任を果たした、というものである。対するコンストラクタ側の主張では、作業の遅れは州側に責任があり、業務の遂行上必要な措置の実施、人員の雇用と訓練および、サーバ群の統合に必要な設備上の改善が当局により行われなかった、とされている。またコンストラクタ側の代表者は、指定された到達目標はすべて達成したと主張し続けている。
この事例のようなケースは、かなりの頻度で他のプロジェクトでも発生しうるものである。
発生の予想される問題点を洗い出す
潜在的な問題点を特定しその対策を講じるという作業は、見過ごされがちな過程である。例えば、既に契約も締結されているし、その内容はプロジェクト当事者の双方が納得したものであり、契約ベンダも優れた実績のある業者であるといった状況に置かれれば、誰しも「何も懸念することはないではないか」と思いたいところであろう。ところがこうした安易な思考は、何か1つが上手く進まなくなった場合、簡単に破綻する。いずれかの当事者の思惑に反することが生じると、事態は加速度を付けて崩壊への道を疾走するのである。
こうした状況を回避する責任が誰にあるかというと、それは契約ベンダ側ではなく、カスタマ側つまりは貴方にあるのだ。ベンダ側の行う提案や作業の内容の基となる標準契約とは、本質的にベンダ側の利益を守るためのものでしかない。よって、仮に何らかの問題が生じた場合、そうした契約を基に自分の主張を通そうとしても、大抵はうまくゆかないものである。
こうした現実を受け止めるのであれば、契約締結の前に潜在的な問題点を洗い出しておくことが、将来起こりうる問題を回避する有効な手法として機能することになる。つまりカスタマ側は、ベンダ側から提示される契約内容を余すことなく検討し、プロジェクトの進行に関するカスタマとベンダ間の合意事項を具体的なプランとして確立しておくのだ。
カスタマ側が押さえておくべき1つの基本ルールは、法務部による書面上での確認が済むまでは具体的な行動を起こさず、その後に法的な助言に従った措置を執っておくことである。このルールをおろそかにし、契約の締結段階で法務関係の人間を参加させておかないと、将来的に大きな危険を抱え込むことを覚悟しなければならない。
考えておくべきは、法務関係の内容だけではない。プロジェクトを進める上での共同プランというものをカスタマとベンダとで検討しておく必要があり、そうしたプランの中には、個々の事項に関して責任を負うべき当事者の規定、プロジェクトで作成されるべき成果物のリスト、プロジェクトが完成したと見なす際の基準を定めておかなければならない。
こうした共同プランの確立は、ベンダとの契約そのものに匹敵する重要性を有している。よってこの取り決めでは、プロジェクトの全分野における細部に至る事柄を可能な限り煮詰めておく必要があり、不明瞭な部分を残したり見逃していた事項があると、後に禍根を残すことになりかねない。
必要な書類を作成する際には、常に法務部からのアドバイスを得られるようにしておくべきである。さらにカスタマ/ベンダ形式の契約についての経験が豊富なコンサルタントを雇い入れて、書類作成の協力を得られればベストだろう。
共同プランには、最低でも下記の要件を取り込んでおく必要がある。
- プロジェクトにおいてベンダ側が関与する内容を明示化しておく。ここで言う関与する内容とは、特定のアプリケーション群を提供するだけで終わるのか、あるいはソフトウェアだけに止まらず関連するコンサルティングやトレーニングなどのサービスも含まれるのか、などを指す。またその内容は詳細に規定しておくべきであり、例えばコンサルティングサービスも含めるのであれば、提供されるコンサルティング時間や達成目標をプランに記しておく。同様にトレーニングも含めるのであれば、提供されるトレーニング時間はもとより、トレーニングで行われる内容および目標達成までのプロセスも定めておかなければならない。
- プロジェクトの各ステップにおける到達目標については、日程的な期限だけでなく、個々の到達時までに達成しておくべき内容も一覧しておく。より具体的には「契約書に一覧されたすべての購入予定アプリケーションは、2007年6月15日までにインストールが完了し、カスタマインストレーションにおける負荷試験が可能な状態になるものとする」などと指定しておく。
- ソフトウェアおよびその他の成果物に関する検査の規定を定める。具体的には、検査の責任者、用いる検査手法、検査の合否判定の方法などを指定しておく。
- 最終的な確認事項として、プロジェクトが完成したかの判定プロセスを、共同プランに文章化しておく必要がある。例えば「プロジェクトが完成したと見なす条件は、エラーを発生させることなく5回のプロジェクトランに成功し、その実行結果が必要な要件を満たしている場合とする」などというように指定をする。
共同プランをまとめる際には、用いる文言にも注意をする必要がある。例えば「カスタマを支援する」、「サポートを提供する」、「最善の努力をする」など曖昧性を残す表現は、問題発生時には異なる解釈をされる余地があるため、新たな論争の火種となる危険性がある。それを避けるには、可能な限り具体的な記述をするよう心がける。
まとめ
ここでのプロセスは、共同プランに関する両者の合意が得られれば終わり、というものではない。完成したプランについては、双方の代表者による承認が必要である。その際にカスタマ側が注意すべきことは、ベンダ側で最終的な承認をする者が協定を結ぶにふさわしい権限を有している人物であるか、という点である。例えば、セールスマネージャによる承認では充分だとは言えないだろう。
それではベンダ側が、「過去にそうしたステップを経た先例が無い」、「これまでのカスタマはすべて標準契約の締結だけで了承した」という理由をもちだして、共同プランの構築を受け入れなかった場合はどうすればいいだろうか？ これも往々にして生じうるケースであるが、そのような主張を受け入れることは、何らかの問題が生じた場合に使える対抗手段を放棄することになり、自分のサイドが不利な立場に追いやられる危険性を意味する。
共同プランの構築にベンダ側が難色を示した場合に取りうるオプションは、別のベンダを探すか、あるいは将来的な問題に対する自衛策を備えておくかの、いずれかとなるだろう。
ところで冒頭に紹介した事例の顛末だが、この場合は両方の当事者が事態は穏便に解決できると楽観視していたものの、結局は州側がプロジェクトの未完成分の責任を負うことになるだろうとのことである。仮にそうした穏便な解決策があり得るとしても、そこに至る以前に双方が損害を被っているのも事実である。両陣営とも訴訟費用を持ち出す必要に迫られたのはもとより、州側はプロジェクトが遅延され、ベンダ側も最終金180万ドルを受け取れなかったのであるから。そして信頼に傷が付いたのは、双方にとっての痛手だろう。
このような厄介事の当事者になりたくないのであれば、自分が携わるプロジェクトについては、事前に充分な時間と手間を割いて、将来的に発生しうる問題に備えた防止策をあらかじめ講じておくことである。
NewsForge.com 原文
