ベンダーやユーザーの両方の立場から大型開発プロジェクトにかかわった経験をお持ちの,あるコンサルタントの方とお話しする機会があった。この方は,動かないコンピュータの種類を3つに分けて考えるべきではないかと指摘している。

 第一のトラブルは,到底不可能なプロジェクトをやろうとしたための失敗。二つ目は,システム開発のやり方がまずかったために,プロジェクトが失敗してしまったケース。三つ目は,システムは完成し無事に稼働していたものが,あるとき突然に不具合が発生して大きなトラブルを呼んでしまうというものだ。

 第一番目の例は,もともとの予算や開発期間,用途などに問題があった例である。こうしたケースでは,どのような腕利きの専門家を揃えてもプロジェクトを成功させるのは難しい。気が付かないうちに,バベルの塔を建てようとしていたと言えばいいのだろうか。

 2番目の例が,いわゆる動かないコンピュータとして,馴染みの深いものになるだろう。予定通りに完成する可能性は十分にあったにもかかわらず,プロジェクトの進め方に問題があり失敗したケースである。

3番目の例は,不具合が突然顕在化してシステム障害が起きるような場合を指している。無事に稼働していたシステムが,突然障害を経験する3番目のパターンの場合,プログラムの開発体制に,トラブルの原因を押しつけるのは無理がある。若干の不具合がプログラムに残っているのは不可避の問題であるし,稼働後に深刻な障害が起きた事例の大半は,障害発生後の対処策に問題があって,トラブルが大規模化したケースが多いからである。動かないコンピュータの原因としては,危機管理体制などを考慮に入れる必要がある

 繰り返しになるが,プロジェクト単体ではなく,プロジェクトを巡る状況を考慮に入れた上でなければ,動かないコンピュータが生まれる理由を特定することはできない,ということである。