ソフトウエアの改造力が足りない――。そのために，システムの変更作業でミスが生じ，次々とトラブルが引き起こされている。

　2006年5月9日，シティバンク（エヌ・エイ在日支店）で顧客口座の取引処理にかかわるシステム障害が発生。約6万9800件の取引が二重処理された。原因は，追加したプログラムの不具合。シティバンクは，「障害が発生した原因は、新規プログラム導入に際し、口座取引情報処理において間違ったシステム処理が発生したものです。十分事前テストをいたしましたが実際の運用に際し、結果的に、予想しなかった不具合が発生しました。」と発表した。

　2006年6月19日には，プログラム変更のミスによって，労働金庫連合会のシステムにトラブルが発生。総額5億円を超える送金に失敗した。この実例から，なぜ改造が引き金となってトラブルが発生するのかを見よう（図1）。

図1●改造のミスはトラブルに直結する 6月19日の午前中，労働金庫連合会のシステムに障害が発生。郵便貯金口座から<ろうきん>口座への送金処理の一部がエラーと判定され失敗した。当日に入れ替えたプログラムに余計な変更を加えていたことが原因。あるチェック・ロジックを改良する作業において，送金処理には不要だったチェック・ロジックを誤って適用してしまった。テストは行ったが，エラーになるパターンが漏れていた [画像のクリックで拡大表示]

余計なロジックを追加した

　労働金庫連合会は，郵便貯金口座からの入金，送金を受け付ける「受付プログラム」を6月19日に新たなプログラムに入れ替えた。目的は，あるチェック・ロジックを改良すること。

　ところが，プログラムを変更した際に，本来は入金だけに必要なチェック・ロジック（図1の左）を，送金処理にも適用してしまった。背景には，送金と入金を，同じ電文フォーマットで処理していたことがある。不要なチェックにより，「キャッシュカード発行済み（再発行あり）」と「キャッシュカード未発行」の送金パターンが誤ってエラーと判定されてしまった。

　トラブルに至った原因は二つある。一つは，変更範囲を見誤り，余計な変更を加えたこと。もう一つは，テスト項目から，トラブルになったパターンが漏れたこと。事前のテストは，「キャッシュカード発行済み（再発行なし）」のパターンしか行っていない。ある関係者は「テスト・パターンの網羅性が足りなかった。どこまで目配りできるかが今後の課題」と反省点を挙げる。