第8回テスト・検証はシステム開発の最後の山場

2008.04.28

岩井孝夫
佐藤三智子

本記事は日経コンピュータの連載をほぼそのまま再掲したものです。初出から数年が経過しており現在とは状況が異なる部分もありますが，この記事で焦点を当てたITマネジメントの本質は今でも変わりません。

システム開発の最後には，テスト・検証という大仕事が待ち受けている。ここでは，システムで何を実現したいのかを言い出したところが善しあしを判断することがポイントだ。その意味からすれば，利用部門が主役になり，情報システム部門は脇役および裏方として支えるべきである。しかしながら，利用部門が主体的にテストをすることなどほとんどない。そこで情報システム部門の本当の力が試されることになる。

　「このやり方では，こういうケースに対応できない」。今日もまた現場の利用者が，新システムの処理機能にクレームをつけてきた。物流システムの再構築を決定したA社で，新システムの稼働テストで問題が発生している。基本設計，詳細設計，開発と作業はほぼ順調に進んできたが，テスト段階に入ったところで予想外のクレームが続発し始めた。

　再構築の作業は，情報システム部門が中心となって全社的な体制で進められてきた。経営陣の狙いは，「サプライチェーン・マネジメントまでを視野に入れた21世紀の物流システム構築」という壮大なものである。開発規模も大きく，予算も相当な額になることから，経営陣の期待も大きくかつ要求も厳しいものになった。

　そこで，従来からその場しのぎで対処してきたシステム面の不具合を一気に解消することにした。さらに将来の環境変化にもシステムの全体構造を修正せずに対応できるように，設計の段階で十分議論をつくすことにした。こうした事情もあって，計画立ち上げから基本設計，詳細設計にいたるまでに十分な時間をかけ，現場部門への入念なインタビューをした後に開発作業に着手した。

　そのかいあって開発作業はほぼ順調に進んだ。ところがいよいよシステムの形が出来上がり，最終の結合テストの段階になって問題が発生したのである。現場にシステムを見せ始めた途端，冒頭のような「文句」がやたらとたくさん出てきた。そのたびに情報システム部門に対しては，修正や作り直しの要求が出された。これでは最終確認どころではなくなった。

　情報システム部門は当初，要求される修正項目の一つひとつに対応していた。ところがあまりにも細かな要求がたくさん出てくるので，このままではテスト・スケジュールがどんどん延びてしまう。そこでテスト時に出てきた要求をもう一度総合的に見直してみることにした。

　すると，修正要求の8割は通常の業務処理ではなく，例外的に行う処理を想定したものであることに気づいた。1カ月に何度も使わない処理のためにシステムを作り直していたらきりがない。情報システム部門はその旨を利用部門に説明するのだが，「これができないと困る」の一点張りでOKが出ない。

　そうこうしているうちに本番稼働のスケジュールは目前に迫ってきた。経営陣からは「本番稼働はまだか」と矢のような催促がある。「本番を遅らせる」などと報告しようものなら，どのような叱責がなされるかわからない。テスト計画を事前に綿密に組んでおかなかったつけが，今になって回ってきた。情報システム部長は頭を抱えている。