過去4回にわたってITProで「動かないコンピュータ・フォーラム」を執筆しました。前回の「豊かなコミュニケーションはプロジェクトを救う」は，前々回の「気遣いは動かないコンピュータを減らすのか」へのご意見を基に執筆したものですが，みなさんからのご意見は300を超えました。ありがとうございました。

　システム開発にかかわるプロの皆さんから300を超すご意見を一時にいただくチャンスは，そうは多くない。日経コンピュータ本誌では，「動かないコンピュータ」を連載しているが，取り上げる事例は原則として毎回1社。日経コンピュータは隔週刊だから毎年26社しか紹介できない計算になる（ちなみに2000年1月1日号から「誤算の検証」と題して，日経コンピュータで連載を再開してから今年9月6日号までの連載回数も累計で96回にしかならない）。

　個別の動かないコンピュータは様々な状況の中で生まれるのだろうが，これだけ多くのみなさんからのご意見を生かせば，従来の日経コンピュータの枠を超えて，動かないコンピュータに共通する原因を探ることができるのではないか，と記者は今思い始めている。

　そこで今回から，読者のみなさんのお力を借りて，動かないコンピュータが生まれてくる原因について考えていきたいと思う。大きな問題なので，何度かこのテーマでフォーラムを続けることになるかもしれないが，よろしくお願いします。最後に一つ，お知らせもあります。

情報システムはトラブルに見舞われる

　「動かないコンピュータ」，つまりシステム開発，あるいはシステムの運用がトラブルに直面した経験をお持ちの方は多いだろう。日経コンピュータが，2003年11月17日号で掲載した「プロジェクト実態調査」によれば，品質・コスト・納期のすべてで予定を満たしたプロジェクトは全体の26.7％にすぎない。

　同様の結果は外国でも明らかにされている。米スタンディッシュ・グループによるカオスレポートがそうだ。1994年に実施されたカオスレポートの結果によると，システム開発プロジェクトのうち，完全に成功したといえるものは全体の16.2％だけという。このレポートによれば、完成はしたものの予算超過や納期遅れ、当初想定した機能を実現できなかったシステムが、全体の52.7％、そして完成前のどこかの段階で中止になってしまったプロジェクトが31.1％も存在する。

　集計した数字は手元にないが，企業の機密情報の漏洩や，システム障害，ウイルスによる企業の被害も頻発している。システム自体は正常に動いているように見えても，ある日突然に深刻な障害に見舞われる企業も多い。9月に入ってからだけでも，東京電力や埼玉県草加市・八潮市などで個人情報が漏洩していたこと，KDDIが携帯電話利用者の一部に通信料を過剰に請求していた，といった事実が明らかになった。

　なぜ，これほど情報システムはトラブルに見舞われるのだろうか。あるいは，どういったことがキッカケとなってトラブルに陥るのだろうか。またトラブルに陥りやすいプロジェクトとはどのようなものなのだろうか。

　この疑問に対する答えは多いようで少ない。答えるのが難しい問題だからである。これまで，動かないコンピュータ・フォーラムを続けるなかで，あまりに難しい問題だという理由から，あえてこの問題には触れずにきたが，多くのみなさんがこのフォーラムに興味を持っていただいている現状なら，ある程度の答えが出せるかもしれないと考えている。

一つのカギは要件定義

　ちなみに，上記の日経コンピュータの調査でも，プロジェクトの品質・コスト・納期の3点について当初計画を守ることができなかった理由を尋ねた。納期やコストについては，要件定義と開発段階の作業の増大がプロジェクトを予定通りのものにしなかったという結果だった。興味深いのは品質についてである。

　システムの品質が当初の狙いを果たせなかった理由を，複数回答可能で聞いたところ，要件定義が十分でなかったが回答全体の35.9％で最も多く，その他の27.7％を除くと，テストが不十分・移行作業に問題があったの21.9％がこれに続いた。

　ちなみに他の選択肢と回答率（カッコ内）は，「社内の開発体制に問題があった」（13.9％），「ベンダーの選択に問題があった」（10.6％），「システムの企画が十分でなかった」（18.7％），「システムの設計が不正確だった」（19.1％），「システムの開発作業の質が悪かった」（13.1％），「エンドユーザーへの教育が不十分だった」（19.1％），「運用計画が利用形態に沿っていなかった」（7.6％）である。

　もっとも，これはアンケートの回答の一部に過ぎない。なぜ，動かないコンピュータが誕生したのかという理由を考える材料としては十分とはいえない。また，なぜ常々システム開発プロジェクトでは「要件定義などの上流工程が重要」と言われているにもかかわらず，結果として要件定義が不十分になってしまったのか，といった理由を知ることはできない。

何がトラブルの原因だったのか

　さらに，実際のプロジェクトを進める上での問題ばかりを考えても，動かないコンピュータがなぜ起こるかを考えるのは難しいという指摘もある。