問題にかかるコストを削減する

私たちの会社では、あるトレーニングソフトウェアを使っていたのですが、すでに5回もアップグレードに遅れていました。ソフトウェアはかなり古くなり、ベンダーのサポートも切れた状態になっていました。私たちのプロジェクトの目的は、ベンダーとともにそのトレーニングソフトウェアを最新版にアップグレードし、それが使えるようユーザーを教育することでした。

私たちは2つのSOW（Statement of Work、作業範囲記述書）を定めました。ひとつはユーザートレーニングに関する合意について説明したもので、もうひとつは古いトレーニングソフトウェアをアップグレードするための「上限」コストを記述したものです。データをコピーしたあと、ベンダーは別のところで、データ変換と最初のアップグレードを始めるのに必要なスクリプト†の開発およびテストを実施するプロセスを開始しました。

スクリプトがベンダーのテストをパスすると、ベンダーは私たちの開発環境を移行し、ユーザーテストを実施しました。こうして5回のアップグレードそれぞれについて、このプロセスを繰り返しました。テストをしているあいだ、私たちは遭遇した問題を記録しておき、ベンダーがスクリプトを書き直してテストするたびに、それらについて再テストをしました。

ひとつずつアップグレード作業を進めながらも、私たちはベンダーの作業時間にSOWで定められた請求料率をかけたものが「上限」予算を超えていないか記録しました。アップグレードを進めているうちに、私たちはアプリケーションのアップグレード自体にバグがあることを発見しました。このバグは、アップグレードをインストールするために書いたカスタムスクリプトとは無関係なものでした。私たちはこうした問題も詳細に記録しておきました。画面をプリントして、どこでどのように問題に遭遇したのか、順を追って詳しく説明しておいたのです。

それから、私たちは本来そのソフトウェアがやるべきことを約束したベンダー保証書を彼らに見せました。ところがベンダーは、ソフトウェアは「仕様通り」に機能していると言い張ったのです。後になって、私たちが遭遇した小さなバグは氷山の一角にすぎず、もっと影響が大きいことがわかりました。アップグレードをしても、ソフトウェアの基本機能に重大な欠陥があることが明らかになったのです。

ようやくベンダーは、私たちが見つけた問題のいくつかは確かに「仕様通り」ではなく、実際にはバグであったことを認めました。ベンダーは自らの製品を修正するのに要した作業について、「上限」契約にある通り、「上限」を超えた分の費用請求をしませんでした。

この段階で、私たちは大事な締め切りに間に合わせるため、ソフトウェアをインストールすることだけに注力しました。このときには、もはや見つかった問題が「仕様通り」なのかバグなのかというのは、私たちにとってはどうでもよくなっていました。しかし、後になってわかったことですが、もしここで見つかったバグや問題に対してベンダーの作業時間を具体的に記録していれば、私たちは「上限」契約の総額すらを支払わずに済んだのです。

ベンダーと契約交渉をするときには、遭遇した個々の問題について、ベンダーの作業時間とプロジェクトチームの作業時間の両方を記録するよう明記しましょう。こうすることにより、問題がプロジェクト作業にまつわるものではなく、ベンダーの製品自体にもともとあったものの場合には、その解決に要した分の費用を抑えることができるでしょう。