ソフトウェア開発が当初の目的を達成できずに失敗、あるいはそれに近い状態で終わるケースは比較的多いようだ。1997年に出版された訳本「ソフトウェアの成功と失敗」（共立出版）では、失敗について詳しく記されていて興味深い。これを参考にしながら、「失敗」について考えてみよう。

　開発が失敗したかどうかの判断は、立場や見方によって異なるだろう。発注側のユーザーから見れば、仕様通りのものが、所定の予算の範囲内で、一定の品質を保って、納期までに完成すれば、それは成功であり、この条件が一つでも満たされなければ、失敗とみなされる。一方、開発するベンダーにとっても、このような条件は一緒であるが、もう一つ重要なのは自身の経費である。見積りが甘くて、予想以上に経費がかかったり、納期を守るために当初の計画以上の要員を投入したりすると、最終的には赤字プロジェクトになり、結局は失敗となる。

　失敗にはいろいろな要因が考えられるが、大別すると、不十分な要求定義、不完全な設計、不適切なプロジェクト管理の三つとなろう。要求定義は曖昧さを排除し、あとからの変更や追加を極力避ける必要がある。要求定義が不備だと、経費や納期の見積りが不正確になって、プロジェクトの成否に影響を与える。要求の変更や追加が30％を超えると、ほとんど失敗するそうだ。

　ユーザーとベンダーは協力して要求定義を行わなければならないが、その際に、要求、経費、納期の間には密接な関係があるので、両者はこれを的確に理解する必要がある。それには両者の信頼関係が何よりも大切である。

　基本設計やデータベースの定義などの設計工程には、時間をかけるべきである。設計の手抜きは、あとの工程で時間的な損失を生む。完成度の高い設計のために費やす時間は、あとで取り戻すことができる。急がば回れである。

　プロジェクト管理には、スケジュール、要員、費用、品質、リスクなどさまざまな管理が含まれる。開発規模が大きくなり、開発要員の人数が増えると、プロジェクト管理が飛躍的に難しくなる。失敗を回避するには、プロジェクト管理に万全を期す必要がある。だが、専門知識をもったプロジェクトマネージャーが足りない。大学もこの分野の人材育成に力を入れるべきである。

　ソフトウェア開発を成功させるためには、「失敗」というリスクを最小にするという視点も必要である。