システム開発に失敗する。満足のいくシステムが完成しない。システムが深刻な障害を経験する。こうした「動かないコンピュータ」の当事者の大変さを想像するのは難しい。

　先日，最終的に中断することになった，ある動かないコンピュータを経験した方から，「中断が決まったとき、ものすごい挫折感とものすごい安堵感が同時に襲ってきた。今でもあの経験は、私だけでなく関係した多くの人間・企業にトラウマとして残っている」という言葉を聞いた。この言葉を聞いて記者は，動かないコンピュータに巻き込まれた当事者のつらさや孤独，心に残る傷を改めて強く感じた。

　問題は当事者の経験だけではない。巨額の経費を投資したシステムは，企業の業績にも深刻な影響を与えかねない。例えば長い混迷の後，ようやく稼働したある製造業ユーザーの大規模プロジェクトは，開発費が当初予定をおよそ200億円もオーバーしたといわれる。この200億円という金額はその企業の1年間の営業利益を大きく上回る。真偽のほどは不明だが、このプロジェクトは、このユーザー企業の経営層の人事に影響を及ぼしたという声すらある。

　日経コンピュータが，「動かないコンピュータ」というタイトルで，システムにまつわる様々な失敗についての連載を開始したのは1982年のことだ。いったん連載は中断したが，2001年1月から連載を再開している。日経コンピュータ本誌の動かないコンピュータの連載回数は，合計で200回を超えた。開発が難航したプロジェクトから，深刻なシステム障害，ウイルスによる社内システムのマヒ，最近では個人情報の漏洩事件まで取り上げている。

　実はこの連載で取り上げる少なくない企業が，何度も動かないコンピュータを経験している。あるいは，必ずといっていいほど自分のかかわったプロジェクトが，深刻なトラブルに直面する人がいる。

　なぜ，こうした企業は苦しい経験を糧にできないのだろうか。一方で，動かないコンピュータ経験を糧にして，情報化の体制をガラっと変える企業があるのも確かだ。そこで今回は，こうした深刻な動かないコンピュータ経験を，企業や担当者は，どうすれば有用な教訓にできるのかを考えてみたい。

動かないコンピュータの原因とは

　簡単な問題ではないので，いくつか考える手がかりになりそうなことを書いてみる。

　以前，このフォーラムでは，「大募集！　動かないコンピュータが生まれる理由は何か」と題して，もっと直接的に動かないコンピュータが誕生する理由について考えてみた。

　この回のフォーラムについての反響は「読者が伝えた70の動かないコンピュータから考える（上）」，「同（下）」にまとめた。

　このフォーラムで指摘があった，動かないコンピュータの原因は以下のようなものだ。

　まずは「バベルの塔」の建造のように，できないプロジェクトをやろうとしたというものである。こうしたプロジェクトはスタートすることはできても，要件を固めることすら簡単ではない。何とかして動かすことができたとしても当初，考えていたものとはまるで違うものになってしまったり，動いてはいてもほとんど利用されないものになってしまう。

　次は要件定義の失敗である。要件を固めることができなければ，正しく開発を進めるのは不可能に近い。「ユーザーが何を作りたいのか分からないのにシステムができるはずがない」とベンダーが言う事態である。ERPパッケージの導入で失敗するプロジェクトに多いような、ベンダーがやみくもにユーザーにインタビューを重ねるだけで要件を固めようとするケースもこれに当てはまるるだろう。

　単に要件定義の問題に限らず，ユーザーとベンダーのメンバーがプロジェクトに適していなかったことも動かないコンピュータの原因になる。単純にシステム化しようとする業務への理解度の問題もあれば，対人コミュニケーション能力，リーダーシップの欠如といった問題もある。ここ数年，日経コンピュータが編集テーマの一つとして強く打ち出してきたプロジェクトマネジメント力の有無が、成功と失敗を分けることもあるはずだ。単純に技術力の有無が問題になることもある。

　最近では減ってきてはいるものの，パッケージ・ソフトやハードの不具合がプロジェクトの敵となることもある。こうした場合は，不具合の有無よりも，製品を提供しているベンダーが不具合を迅速に解決できないことが，トラブルを大きくしていることが多い。

　テスト不足も原因として挙がった。開発コストの削減や開発期間の短期化を求められる中で，テストの工数が必要以上に削減されているというのである。テストをどれだけ繰り返しても，すべての不具合をなくすことはできないが，必要なテスト量を確保できなければ失敗の可能性は高まる。