情報システムの開発期間がどんどん短くなっている。一昔前までは企画から本番の稼働まで1年半から2年というケースが多かった。しかし最近は，新しく設立する銀行の基幹システム構築でさえ1年で終わらせるというように，以前は考えられなかったほど短期でシステムを構築するケースが出てきている。eビジネスがらみでパッケージ・ソフトを使う情報システムなら，たった3カ月という短期間で開発を進めることも多い。

　短い期間でシステムを開発できるなら，ユーザーにとっては嬉しい限りだ。しかし，手放しで喜んでばかりはいられない。納品されてもまともに動かないケースがかなり増えているからだ。「納品日に届くシステムのうち10件に8件ぐらいは使いものにならないというのが現状だ」とある独立系システム・コンサルタントは指摘する（詳細は日経コンピュータ2月12日号特集に掲載）。

　こうなると，期限通りにシステムが納入されたとしても，正常に稼働するまでやり直しが発生して，ズルズルと稼働時期が遅れてしまうことになる。無理やり稼働させてしまうと，バグによる動作不良などによってトラブルを引き起こす。例えば，2000年2月に正常なオンライン証券取り引きサービスができなくなり，打撃を受けたエイチ・アイ・エス協立証券のケースも，不具合をみつけられないまま本稼働を急いだことが原因だった。

　不具合が発生する理由の一つがテスト不足だ。期間短縮のしわ寄せがテスト工程にいってしまい，テストで手を抜かれてしまうことが多いからだ。ベンダーがテストをほとんど実施しないままに納品し，それでもテストをしたフリをする場合もけっこうある。

　別のシステム・コンサルタントは，テストの実態を次のように語る。「テストが不足していても，『まだテストが終わっていないので納期を延ばして下さい』というと，ふざけるなと怒鳴られ責任問題になるので，とりあえず納品する。いったん納品すれば，バグが出ても発注側の担当者は『ある程度のバグはしょうがないね。直してから持ってきてください』となり，丸くおさまる」という構図があるという。こんな納品の仕方がベンダーのテクニックになってしまっているのだ。

　短期開発で生じる問題はテストだけではない。プログラムが当初予定していた基本設計や詳細設計の通りにはなっていないケースもよくある。納期が迫るなかでベンダーがユーザーに確認せずにシステム開発を進めてしまい，最終的にはユーザーが望んだ機能の半分しか実現できなかった，という例も多発している。

パッケージをシステムの中心に据えたシステムでも，このようなトラブルは多発している。ベンダーが自分の都合の良いようにユーザー要件を解釈する悪質な例も数多い。これはIT業界のモラル・ハザード問題に結びついている。

　このような問題を防ぐためには，ユーザーが開発現場を把握しシステム構築をきちんと監視しなければならない。テストについてもユーザー要件についても，ユーザーが進捗状況を毎週のようにベンダーと協議する必要がある。ただし，ユーザーも要件定義を明確にする，といった作業をきっちりとしておくことが前提になる。「いつも稼働時期が遅れてしまう」と思っているユーザーは，一度その理由を明確にしておくべきだろう。

（安保　秀雄＝日経コンピュータ編集委員）