企業のイメージや業績に取り返しのつかないダメージを与えるシステム・トラブル。「短期開発を迫られ，ミスを見逃した」，「突然の企業合併が決まり，システム統合の作業量を正しく見積もれなかった」，「基幹系が肥大化を続けた結果，10年前のバグが顕在化した」。最近では，こうしたさまざまな理由でシステム稼働前のテストを十分に実施できず，そのために障害発生を防げなかった事件が目立って増えている。
障害の原因となるバグや仕様の不備は，どんなシステムにも必ず潜んでいる。こうしたトラブルの芽を稼働前に摘み取るための最後の砦がテストだ。頻発するシステム・トラブルを目の当たりにして，企業は改めてテストの重要性に目覚め始めた。東京海上火災保険やセブンーイレブン・ジャパン，東レなどの先進ユーザー企業や大手インテグレータへの取材から，企業を危機から救うテストのあり方を探った。
本記事は日経コンピュータ2002年7月29日号からの抜粋です。そのため図や表が一部割愛されていることをあらかじめご了承ください。なお本号のご購入はバックナンバー，または日経コンピュータの定期ご購読をご利用ください。
「その不具合は，もともと計画になかったテストをある担当者が実施して偶然発見した。再構築した株式売買システムを稼働させる，わずか数日前のことだ。不具合を見逃して稼働させていたら，株式売買システムに接続する全端末が起動できなくなるところだった。今でも思い出すと冷や汗が出る」。東京証券取引所 株式部システム開発運用グループの佐藤博リーダーは，2000年春の出来事をこう振り返る。
東証の株式売買システムは，証券会社に設置した取引用端末に対して，株式売買に必要な「銘柄」などのデータを一括して送信する。端末は，受信したデータを読み込んでから立ち上がる仕組みになっている。
佐藤リーダーが冒頭の発言で言及した担当者は，新システムの稼働を間近に控えたテストで，端末に送信するデータに，ある特殊記号を含めることを思いついた。この特殊記号が初めて，上場予定企業の銘柄に使われることを知ったからだ。テストを実施してみると，端末はその特殊記号を認識できずに，動かなくなってしまった。
それまでのテストでは，上場済みの銘柄のデータを使っていたので，この不具合を発見できなかった。東証の株式売買システムは，取引金額が1兆円を超える日もある。佐藤リーダーは，「もしかしたら…という担当者の直感によって，深刻なトラブルの芽を摘み取ることができた」と胸をなで下ろす。
的確なテストの実施が困難に
過去に起きた深刻なシステム障害の中には，テストを地道に実施していれば未然に防ぐことができたはず，というものが少なくない。だが，ここにきて，テストを的確に計画したり実施するのが難しくなってきた。
その理由の一つは，特に基幹系システムの肥大化や複雑化が進んでいることだ。その背景には，企業の合併に伴うシステム統合や，ビジネス環境の激変に合わせたシステムの修整が増えている，という事情がある。
システムの規模が膨らむと，「当然，テストには時間がかかるし，不具合の検出漏れも起きやすくなる」（KDDI 情報システム本部の繁野高仁ネットワークシステム開発部長）。例えば，昨年から今年にかけて日本航空（JAL）やJRが起こしたシステム障害の原因は，何年も前から潜んでいたバグにあった。それだけシステムの全体像を把握するのが困難になってきたと言える。UFJ銀行やみずほ銀行の勘定系システム障害も，限られた時間で巨大システムを刷新するプロジェクトの恐さを再認識させた。
もう一つの理由は，開発の短期化が進み，テストに割ける時間が減ってきたことだ。「わずか3カ月程度のWebシステム開発では，設計や実装に手間取れば，テスト期間はあっという間になくなってしまう」（日本ユニシス Eテクノロジ＆サービス部の羽田昭裕 メソドロジ＆アーキテクチャ課長）。
こうした事情から，多くの企業ではテスト不足が慢性的になり，トラブルの芽を摘み残したまま，システム稼働を迎えることになる。この1年間に“動かないコンピュータ”に陥った事例を検証してみると，このような実態が浮かび上がる。
眠れるバグが目を覚ます
基幹系システムの肥大化が招いた象徴的な事件が，この3月にJRの座席予約システムで発生した。予約データに不整合が生じ，一部の指定席を重複販売したトラブルである。
きっかけは，ディスク装置の取り換えだった。この作業がシステムに与える影響範囲を把握しきれず，本来は修整が必要なプログラムに手を加えなかったため，過去10年以上にわたって顕在化しなかったバグが“発症”した。
システムが大規模になればなるほど，こうしたバグを見逃す危険性は高くなる。だが，十分なテストを実施していれば，バグの発症を防ぐことはできたはずだ。JRのケースでも，トラブルの大きな原因がテスト不足にあったことは否めない。
基幹系システムについては，多くの企業が導入に取り組んでいるERPパッケージ（統合業務パッケージ）の存在も，テストを難しくする一因になっている。独自開発のシステムとは違った注意が必要だからだ。
東レは2000年1月に初めてERPパッケージを導入。SAPジャパンの「R/3」を使って，人事システムを刷新した。同社はこのプロジェクトでテストを実施するのに当たり，パッケージ製品ならではの問題に直面した。「パッケージ製品は処理の内容がいっさい見えない“ブラックボックス”なので，処理や分岐条件などをすべて検証したかどうかを把握するのが難しい。テストするにはパッケージ特有のノウハウが必要だと痛感した」（東レの重松直システム企画開発部長）。
Webシステムの意外な落とし穴
一方，Webシステムでは，膨大なアクセスによる負荷の集中を回避するためのテストが課題になっている。
例えば今年1月には，インターネット専業銀行の最大手であるジャパンネット銀行（東京都新宿区）が，Webシステムの応答性能を大幅に低下させた。通常の4倍ものアクセスが殺到したのが原因で，利用者が同社のWebシステムにログインしづらい状況が続いた。
ジャパンネット銀行の口座数は，2000年10月の開業以来，順調に増え続けており，今年7月8日現在で約52万。同行は口座の増加状況に注意を払いながらシステムを増強してきたが，予想を上回るアクセスが舞い込んだ。障害検知システムがエラーを誤認識するというトラブルも重なり，システムの回復に丸1日かかった。この一件から，念入りな負荷テストによって応答性能の低下を防ぐことに加えて，実際に障害が発生した場合を想定した障害テストの重要性も浮き彫りになった。
電子商取引サイトなどのWebシステムは，Webサーバーやアプリケーション・サーバーなど，さまざまなパッケージ製品を組み合わせて構築する。こうした製品に対するパッチ・ファイルの適用状況も，トラブルの芽になることがある。首都圏コープ事業連合（東京都文京区）の電子商取引サイトは今年2月，Webブラウザの「Internet Explorer Ver.5.01（以下，IE 5.01）」からアクセスできないというトラブルを起こした。負荷分散装置の設定の誤りが原因だった。
このトラブルをテストで発見できなかったのは，首都圏コープがテスト環境で利用しているすべてのIE5.01に，セキュリティにかかわるパッチ・ファイルを適用していたからだ。そのため，パッチ・ファイルを適用していないIE5.01を使った場合の不具合を発見できなかった。皮肉な結果だが，これもテストに潜む落とし穴と言える。
実は，このようなトラブルは珍しくない。Webシステムの構築を手がける電通国際情報サービス（ISID）産業ソリューション事業部e-プラットフォーム技術部プラットフォームソリューショングループの芝田潤統括マネージャーは，「テスト環境と本番環境が少しでも違うと，まったく別の現象が起こることがあり，不具合発見の妨げになる」と警告する。
テストは準備に時間がかかる
システム・トラブルを回避するには，テストの実施段階だけでなく，その前の計画段階からさまざまな準備をしておく必要がある。「テスト項目を洗い出すと同時に，テストを実施するための体制を整えておかなければならない。要件定義が終わったら，即座にテスト計画の検討を始めるべきだ」。本特集でテストへの取り組みを取材した企業の担当者たちは，こう口をそろえる。
特に複数の企業のシステムが密接に連携するケースでは，早い段階でテスト計画を立てることが極めて重要だ。例えば，航空券の予約・販売サイトを手がける国内線ドットコム（東京都港区）は，多くの航空会社とのシステム連携が必要な処理のテストに手間取り，昨年4月に予定していた稼働を3カ月延期する羽目になった。
同社は，その大きな原因の一つとして，「複数の航空会社が同時にテスト環境を用意できる日が，なかなか見つからなかった」（国内線ドットコムの幸重孝典総務部長）ことを挙げる。テストケースの中には，複数の航空会社と同時にシステムを接続できるタイミングでしか，テストを実施できないものがあるからだ。
全工程で品質向上が前提
もちろん，テストを徹底することが，システム・トラブルを回避するための“王道”というわけではない。品質の高いシステムを完成させるためには，「開発着手から稼働までのすべての工程で厳密なレビューを実施するなど，プロジェクトマネジメントが欠かせない」（日本IBM 技術 ソフトウエア・エンジニアリングの榊原彰担当）。榊原担当は，「システムの品質は，設計段階で作り込むものだ」と強調する。
ただ，すでに稼働している巨大な基幹系システムを修整しながら維持していくような場合は，「テストを地道にやるしかない」（東証の佐藤リーダー）。決してテストで手を抜いてはならない。
情報システムのテストとは
テストの目的は，あらかじめ決めた仕様どおりにシステムが動作するかどうかを確認することにある。テストは，「テストケース」に基づいて実施する。テストケースとは，「この処理や操作を実行したら，こういう結果になるはずだ」という観点で，入力データ，実施する処理の内容，期待する結果をセットにしたものを指す。
設計工程で作成する仕様の種類に応じて，実施するテストの種類も異なる（図A[拡大表示]）。例えば，基本設計どおりに機能面，性能面，運用面の仕様を満たしているかどうかは，後述するさまざまな「システム・テスト」によって確認する。完成したシステムが，要件定義どおりに仕上がっているかどうかを確認するのが「受け入れテスト」だ。
 |
| 図A●テストは，要件定義，基本設計，詳細設計といった各工程の内容に応じて実施する。 テストの実施順序は，必ずしも図の通りとは限らない |
受け入れテストやシステム・テストは，システムの中身を意識せずに，どのように動作するのかという面から検証するので，「ブラックボックス・テスト」と呼ぶ。一方，個々のプログラムの“作り”を確認する「単体テスト」や，プログラム同士の連携に着目する「結合テスト」は，システムの中身を検証するので「ホワイトボックス・テスト」という。
システム・テストは，図Aに示した5種類のテストに分類できる。例えば「機能テスト」は，「利用者が“購入”の操作をしたら，データベースを更新し，注文者に回答を返す」という具合に，新たに実装した機能が正しく働くことを確認する。これに対して，従来の機能に支障が出ないかどうかは「回帰テスト」でチェックする。このほか，アクセスの増加に対するシステムの耐久性を確認する「負荷テスト」，システム障害からの回復をチェックする「障害テスト」，システムの運用を試す「運用テスト」がある。
続きは日経コンピュータ2002年7月29日号をお読み下さい。この号のご購入はバックナンバー，または日経コンピュータの定期ご購読をご利用ください。
「ユーザー企業は最近，情報システムの品質を重視するようになってきている」。今回の特集で取材したあるベンダーの担当者は，こう話していました。ベンダーの担当者によれば，ユーザー企業から「テストの実施基準や品質管理基準はどうなっていますか」と突っ込まれることが増えているそうです。それも，システムの提案段階でのこと。それに合わせてベンダー側も，自社の品質管理やテストに対する取り組みを提案書に明記することが増えているといいます。
ユーザー企業が，テストや品質管理基準についてベンダーにどんどん問いただす。それが，企業に取り返しのつかないダメージを与えるシステム・トラブルを防止する第一歩のような気がします。（大和田）
