今回は、システムの受注や契約にからむ諸問題をテーマに取り上げる。システムの受注なしに、システム・ビジネスが存続できない以上、受注の確保に必死になるのは当然である。しかし、受注できてもシステムがうまくまとまらず、大混乱が起これば、ベンダーが存亡の危機に陥るだけでなく、顧客に大迷惑を掛けることになる。幅広い視点から問題点を探し、できる限りの回避策を考えておかねばならない。
 |
いくら優れた機能が実現できても、顧客の予算と要求納期を満たさないシステムは意味がない。機能の実現に苦戦して、大幅な納期遅延や予算超過に追い込まれる事例が多いことが、IT業界が抱える深刻な問題である。
その最大の原因は、提案依頼を受けたときに、顧客の予算に十分配慮もせずシステムを考え提案し、見積もりを出すことである。しかも、その額では注文を取れないと分かると、仕様とは無関係に見積もりを下げてしまう。それで注文が取れたとしても、当然、巨額の赤字に陥る。これが多くの実例だ。
何より大事なことは、顧客の予算がいくらなのかをフランクに聞くことだ。予算を聞けない場合でも、ベンダー内で予算を推定し、その予算で実現できるシステム案を考え提案することである。予算を配慮せずにシステムを提案するのはアマチュアで、とてもプロのSEとは言えないだろう。
 |
今日、ウォータフォール型開発モデルは時代遅れとされ、スパイラル型開発モデルの良さが喧伝されている。
しかし、プロトタイプを作り、問題点を修正しながら完成形に近付けていく開発手法は、派遣契約で開発する場合は効率がいい方法であろうが、これを安易に一括請負契約で引き受けると赤字プロジェクトに転落してしまう危険性がある。特に大規模で複雑なシステムでは、顧客によってはプロトタイプを見るたびに悩み、仕様決定が遅れがちになったり、いつまでも変更が続いたりという潜在リスクが高くなる。
どうしても一括請負契約が不可避なら、プロトタイプを作る回数や、スパイラルの繰り返しの上限回数、あるいはスパイラルの終結時期を設定する必要があろう。さらには、サイクルごとに再見積もりができるような契約条件をあらかじめ設定しておくべきだ。
 |
契約書の重要な項目の1つが、検収条件だ。どのように検収するかは顧客の考え方次第だが、大体は日程的にも費用的にもプロジェクト全体の5％を超えない範囲で、検収が済むような契約条件にまとめるのが妥当だろう。
そのためにも、検収条件は「条件Xiのとき結果Yiとなること」というような有限の明示的条件にまとめる必要がある。すなわち、正しいi個の試験結果を提出すれば検収が完了するような検収条件にするわけだ。もう1つの方法は、検収期間を有限期間とし、検収をすべて顧客でやってもらうことである。例えば、1カ月の検収試験期間を設定し、この間に発見された問題点が解決されたら検収とする方法である。
 |
プロジェクトの工期をより短くするには、より多くの要員を投入しなければならない。だが、多くの要員を投入したからといって工期が短くなるとは限らない。無秩序に要員を投入するとむしろ生産性は下がり、かえって工期は長くなる。従って、開発量に応じた最低限の工期はどうしても必要になる。
バリー・べーム氏によれば、63種のソフトウエア・プロジェクトを分析した結果、最適の工期は
T（最適期間）＝2.5（所要人月）1/3であり、最適工期を下回れば、コストは急上昇するという。さらに投入要員数に無関係に、最適スケジュールの4分の3より短い時間内で成功したプロジェクトはほとんどないという。
従って、 要求納期に比べ総開発量が大きい場合は、顧客に何とか段階的稼働を考えてもらえるように提案し、第1次稼働時は最低限度の機能に絞り、第2次以降は別見積もり・別契約とするよう折衝すべきだろう。
