日経コンピュータでは，創刊直後から「動かないコンピュータ」という連載を継続してきた。簡単に言えば，開発の大幅な遅れや深刻なシステム障害などといった情報システムに関連するトラブルを実名で紹介するコラムである。
実は日経コンピュータでは，2年ほど前から「動かないコンピュータ」をいかにして減らしていくかを，ネットを利用して考えていく「動かないコンピュータ・フォーラム」というコーナーを続けてきた。編集部からの記事提供だけでなく，読者の皆さんからもご意見をいただき，問題解決のヒントを探っていこう，という試みである。従来は，日経コンピュータのWebサイトで続けてきましたが，より多くの皆さんのご意見をいただきたいと考え，場所をIT Proに移すことにしました。当面は，この「記者の眼」のコラムに収録しようと思っています。
正式にIT Proに移行して初の動かないコンピュータ・フォーラムの第1回目のテーマは，「動かないコンピュータに巻き込まれてしまったときに，どう脱出すべきか」としたい。プロジェクトを進めるに当たって，「動かないコンピュータ」にさせないためにどのようなことに注意すべきか，あるいは現実の「動かないコンピュータ」からその原因を考える，といったことは，従来の動かないコンピュータ・フォーラムでも何度も取り上げてきた。場所が変わったこともあり，今回は少し感じの違うテーマを取り上げたいと思う。
このシリーズ「動かないコンピュータ・フォーラム」では，毎回皆さんからのご意見をお待ちしています（詳細は記事末を参照）。いただいたご意見は，後日，別記事として「記者の眼」の中でご紹介する予定です。
こうしてプロジェクトは破綻していく
本来，ある年月，ある予算，ある仕様を満たして完成するはずのシステムが，実際にはこうした条件を満たさないことは残念ながら非常に多い。日経コンピュータ2003年11月13日号の特集で実施した，プロジェクトの成功率に関する調査結果でも，納期・コスト・品質のすべての面で成功と呼べるプロジェクトは，全体のわずか26.7％に過ぎなかった。
もちろん，プロジェクトが難航してから脱出するよりも，あらかじめプロジェクトがトラブルに陥らないように努力するにこしたことはない。だが，実際には上記の調査結果でも明らかなように，トラブルに陥ったプロジェクトの立て直しも決して無視できないことである。
これまで動かないコンピュータを取材してきた経験を基に，以下でプロジェクトがトラブルに突き進んでいく典型的な状況を示してみたい。
まず要件定義が遅れ始める。その結果，基本設計や詳細設計と並行して要件定義を進めざるを得なくなる。その後も仕様変更が相次ぎ，プロジェクトが当初の予定通りに完成するのはほぼ不可能になる。極端な場合には，要件定義がほとんどまとまらず，時間だけが過ぎていくプロジェクトもある。
あるいは，仕様変更が相次ぐ中でも，プロジェクトを予定通りに終了させようとして工程をどんどん進めていく。まずテスト期間の短縮が決まる。押せ押せのなかでテストに突入するが，もともと要件の確定や仕様変更が多発してプログラムの品質が低いため，テストで不具合が多発。テストすら満足に進められない状況が続き，いつまで経ってもシステムの品質が実用レベルに達しない，といったことが起きる。総合テストを開始してデータを入力したシステムから，全く反応しなくなるようなこともある。
仕様変更が相次いで大量の追加開発が必要になった時点で，ベンダーとユーザーとの間で費用をどちらが負担するかがキッカケとなって，トラブルが顕在化することもある。ユーザーがベンダーに追加の費用を支払おうとしない場合，ベンダーが作業を止めてしまってプロジェクトが空転することもある。
では，以上のように，何らかの形でプロジェクトがトラブルに陥った場合に，どのように対処すべきだろうか。
まずは，ユーザーとベンダーの双方で対応を協議することになる。改めて，契約書やプロジェクトの中で作成したドキュメントを，読み返すようなこともあるだろう。一般的な対応策は，稼働時期の延期や追加開発に踏み切るといったものだ。協議の結果，システム要件の見直し，あるいはプロジェクト参加メンバーの増員などが検討されることも多い。
納期の延期や仕様の変更，要員の増加などの策を実行しても，トラブルが解決しないこともあれば，プロジェクトのキーとなるプロジェクト・マネジャーを交代させるなど，ユーザーとベンダーのコミュニケーションの取り方を変えるだけで問題が解決に向かうこともある。
ユーザーもベンダーも不満を抱えたまま，仕様を見直し規模を縮小して，何とかシステムを動かすこともある。金銭面についても，ユーザーとベンダーのどちらかが泣いて決着することもある。このような場合は，ユーザーもベンダーも，次のプロジェクトで元を取ろう，と考えるわけだ。
もちろん，開発プロジェクトが難航した後は，ユーザー企業とベンダーとの交渉が上手く進まないこともある。実際には，ベンダーを完全に交代して，プロジェクトを再スタートさせることもある。最悪の場合には，残念ながらプロジェクトが完全に失敗するケースもある。白紙撤回や無期限凍結などである。数億円を超す投資がムダになるわけだ。
意外に多い開発トラブル巡る裁判
ベンダーとユーザーが，「動かないコンピュータ」を続けるプロジェクトにずっと決着を付けることができない場合，最後の策として踏み切るのが民事訴訟だ。今回は，この「動かないコンピュータ」裁判の有用性についても考えたい。
ベンダーとユーザーの間で裁判が起きるような例としては，動いていたコンピュータが何らかの不具合が原因で障害を起こして，大トラブルが起きたケースも存在する。こういった場合，システムを開発したベンダーに金銭補償を求めると，ベンダーとユーザーのトラブルにつながりやすいのである。
実際に，システム開発を巡る裁判の数は意外に多い。東京地方裁判所だけでも，数日に1件は何らかの形で情報システムの開発にかかわる裁判が開かれている。こういった裁判のなかには，大手メーカーや大手企業が当事者となっているものも少なくない。
訴訟に踏み切る企業の数は徐々に増えている。理由の一つは，数年前からシステム開発プロジェクトにおける契約の重要性が指摘されるようになってきたが，現実にはまだまだあいまいな契約が多いことだ。このほかに，ユーザーがITコストの削減を進め，ベンダーが利益率の低下に悩む中で，プロジェクト・トラブルによって多額の損失が出た場合に，なあなあにできる体力を失ったことも理由として考えられる。
ちなみに，「動かないコンピュータ」を巡る裁判が最終的な判決で終わることは少ない。何度かの審理を経た後に，原告と被告の間で和解が成立するのが一般的だ。
記者は基本的に，「動かないコンピュータ」の解決に裁判が役に立つこともあると考えるが，ユーザーもベンダーもともに，何でもかんでもすぐに裁判を起こせばよいとは考えない。「動かないコンピュータ」を巡る裁判には多くの問題があるからだ。
一つには裁判所のITに対する理解の低さである。裁判官だけでなく，裁判の当事者である原告や被告の代理人である弁護士ですら，ITに関する知識が不十分だと感じることがある。こういった状況で果たして，プロジェクトの実態に沿った判断を裁判所が下すことができるのかどうか不安が残る。
ただし，現状については裁判所も理解しており，大企業のシステム部長経験者などが裁判に協力することもあるようだ。とはいえ，こういった協力体制がすべての裁判で敷かれているようには見えない。
日本における裁判には，終了までに長い時間がかるという問題もある。通常の民事裁判の場合，1カ月に一度程度のペースでしか裁判が進んでいかない。原告，被告，裁判所の担当裁判官の都合が合わないような場合には，次の審理が2カ月後ということもある。訴訟を開始して数年後にようやく結審することも少なくない。
何年も経過してトラブルが解決しても，そこにどれだけの意味があるのか。ユーザー，ベンダーの双方にとって，長期間にわたって本業以外の裁判に時間を取られることのデメリットは大きい。記者が取材したある中堅企業は，システム開発プロジェクトに伴うトラブルについて，訴訟を考えたが踏みとどまった。大きな理由は，数少ないシステム担当者が裁判で実務時間を取られることを嫌がったからである。裁判が長ければ長いほど，デメリットは大きくなる。
また裁判によって，ベンダーとユーザーの関係が決定的に悪化してしまうのも良いこととはいえない。果たして，一度の大トラブルだけを原因にしてベンダーとの取引を絶つようなことになってしまってよいのか。大なり小なりのトラブルを経験しながら，ユーザーとベンダーが長期間にわたって付き合っていくことで，システム開発の成功率が高まることも否定できないからである。
果たして，「動かないコンピュータ」の当事者となってしまった場合，裁判に持ち込んでトラブルを終結させることにメリットはあるのだろうか。それとも，あくまでも別の方法で動かないコンピュータからの脱出を目指すべきべきなのだろうか。また，裁判によってトラブルを解決しようとする場合には，どのような点に気を付けるべきなのだろうか。
皆さんからのご意見をいただければ幸いです。6月27日までにいただいたご意見を基に，このテーマに関する総括編を発表する予定です。
なお，動かないコンピュータ・フォーラムの今後のテーマ，あるいは動かないコンピュータについてのご意見がおありの方は，日経コンピュータ編集部（ncreader@nikkeibp.co.jp）までメールをいただければ幸いです。今後の参考にさせていただきます。これまでに議論したテーマはバックナンバーでご覧になれます。
（中村 建助＝日経コンピュータ）
