動かないコンピュータForum

第47回 ATMの危機に解決の妙手は見つからず

動かないコンピュータ・フォーラム 主宰者 中村 建助=日経コンピュータ編集

日経コンピュータを読む理由No.1 「動かないコンピュータ」連載が単行本になりました。全国の書店でお求めいただけます。

フォーラムの主旨と参加ルールへフォーラム・トップへ

 1月に連続したATM(現金自動預け払い機)障害の原因について、皆さんから非常に参考になるご意見を頂ました。本当に有難うございます。

 みなさんのご意見でも、ATM障害の特効薬はなかなか見つからないようです。プロジェクト全体の効率化に伴う、汎用ソフトの採用やテスト不足が改善すべき問題として指摘されていますが、現在の金融機関の置かれた状況を考えると、いずれも簡単に解決できるものではありません。ATM利用の障害は、今後もしばらくは続きそうです。

 まず2月20日には、次のようなご意見をいただきました。



 今回の統合ATMシステムへの切り替え自体は非常に大規模な刷新プロジェクトであるから、この程度のトラブルでよく済んだなあ、というのが私の正直な感想です。今回のトラブルの出方をみると、全部の接続システムを一気に切り替えたようで、このようなスケジュールで、あの程度の障害で終わったのは奇跡のようだ。リスクを考えると、銀行と接続システムごとに何回かのフェーズに分けて徐々に慎重に確認しながら移行するのが普通ではないだろうか。

 さて、IT投資とトラブルの関係だが、正直なところ、銀行側の財布が渋い関係で、なかなか技術力のある技術者が投入し難くなってきているようには思う。一方、銀行のシステム部門もリストラの影響で、本体から切り離されてきており、システム運用のノウハウ自体が生かせなくなってきているのではないか、との懸念もある。今回の切り替えに関してはあまり心配していないが、銀行自体のIT活用力に関しては大いに心配する材料が多いように思う。

(40代、システム・インテグレーター、システムエンジニア )


 二つの興味深いご指摘があります。一つは、全国の様々な金融機関で相互にATMを利用可能にする接続システムである「統合ATM」の導入方式自体に対する問題提起、もう一つは銀行のIT活用力についての不安です。

 特に二つ目の力のある技術者の投入が難しくなっていること、銀行をはじめとした金融機関のシステム部門が本体から切り離されつつある問題については、ご指摘の通りだと思います。コストを削りながら「IT活用力」を下げないために現在、多くの金融機関は基幹系システムのパッケージ・ソフトや共同センターの利用を検討しています。

 しかし、この方法はこれまで、当初ベンダーやユーザーが想定していた成果を挙げていません。すでに、一度はパッケージ・ソフトの利用を決定しながらソフトの完成が遅れて、その判断を覆した金融機関も登場しています。

 またご指摘のように、ここにきて大手都銀をはじめとした、システム要員の移籍やアウトソーシング形態の変更が相次いでいます。人に付随する現場の知恵がどうなっていくのか、この問題については、引き続きウォッチしていきたいと思っています。

 ともあれ、コストや人を減らしながら、従来通りのものを維持することは簡単ではありせん。金融機関には今、何に対する投資を優先しそうでないものについて、どのような将来計画を立てるかが求められているのではないでしょうか。

 2月24日には、実際に金融機関の情報化の最前線にいらっしゃるエンジニアの方からご意見をいただきました。



 銀行の斜陽化というより、日本のシステム作りの能力の劣化・斜陽化という方が正しい気がします。今、某銀行のWeb化ATM対応をしておりますが、結局、ベンダも銀行もより高性能・低コストへ移っていくのに必死で、以前であったら行っていたテストも、工数を掛けないものに変わりつつあります。以前から汎用機の技術を安価で実現できるというUnix機やトレンドなLinux機への変更というトレンドはあってもその上で動作するパッケージは自社の製品か、徹底的にテストされたパッケージを使用していました。

 しかし、現状はそういった自前の技術や信頼性を持てるパッケージを使用するのではなく、一般的なWebLogicやSphereなどのAPサーバや碌にテストされていない低品質なCORBA系のソフトを堂々と使用しています。つまり、こういったオンラインシステムの根幹部分のソフト製品をきちんと評価・構築するだけの技術やその技術を育てるだけのベンダの余裕がなくなってきているという部分こそ核の部分と考えます。

(30代、システム・インテグレーター、システムエンジニア )


 このご意見は金融機関だけでなく、日本の産業界全体の低下を危惧するものです。

 「コストの制約が厳しいなかでは、汎用的なミドルウエアの採用を進めるしかない」。記者もこういった論調の記事を書いたことがありますが、現場からのご意見を前にするといろいろと考えさせられます。

 自前でシステムを開発する場合には、上流行程から下流のテストまで様々な形でソフトの品質を高める努力が可能です。ですが、完成品であるパッケージ・ソフトの場合、ソフトの完成度をユーザー企業が向上させることは自力では不可能です。

 現実には、不具合が見つかっても迅速に対応できないソフトもあります。海外にしか開発拠点がなく、不具合の解消までに様々な手続きが必要だったり、その会社の方針として、バージョンアップの際に不具合を一括して解消する、など理由はいろいろです。

 少し前ですが、海外ではOSにWindowsを使ったATMがコンピュータ・ウイルスに感染したという事例が報道されていました。汎用ソフトの利用が拡大すれば、この事例のように思ってもいなかった障害が今後も登場する可能性があります。

 とはいえ、コスト削減という目的で、銀行をはじめとした金融機関で基幹系システムのメインフレーム離れが進んでいるのはまぎれのない事実です。金融機関は、汎用のミドルウエアやパッケージ・ソフトでいかにシステムの信頼性を確保するか、という頭の痛い問題に取り組む必要があります。

 2月25日には、テストが十分ではなかったのではないか、という可能性に触れたご意見がありました。



 現状として、MAXを想定した負荷試験が出来ない事が要因として大きいと思われるが、金融関係のシステムで、何処まで本番環境でテストが出来るかが問われると考えています。本番環境を使用してのテストが、可能な箇所の方が少ないのではないでしょうか。

 また、現行のネットワークからの移行という事で、今までの実績を考慮し、最小のテスト環境でしかテストを実施していないのではないかと想定されます。今後は、汎用機から脱却していく中で、どのようなシステム構築でも、負荷・異常時等を何処まで想定したテストを実施していくかが課題と考えます。

(40代、システム・インテグレーター、情報システム部門 )


 本番環境を使ったテストが難しいというのは、利用者の多いシステムの多くが直面していることだと思います。残念ながら、統合ATMの導入に伴うテストがどの程度だったのかは、取材できていません。テスト不足が障害にどの程度の影響をもたらしたのかは不明です。

 ただし、テストには限界があります。初期段階から品質を向上させる努力を続けていなければ、テストを徹底するだけでシステムの品質を向上できないのも確かです。

 2月26日と3月3日には、「リスク」について触れた二つのご意見をいただきました。順番にご紹介します。



 問題は障害が発生するリスクはゼロにはできないということを認められないことにあります。もしゼロに近づけるなら利用者に相当な負担をしてもらうしかない訳です。しかし、誰もゼロは求めていません。リスクの範囲と程度と理由と代替手段があればパニックなど起きません。日本人の悪い癖ですが、水も安全もただではありません。リスクの存在を認めない限り適切な危機管理体制は構築できません。事前にリスクを予告し、問題があれば迅速に代替手段で対応することが、真に利用者の信頼を獲得する企業姿勢であると思います。
(30代、ハード・ソフトベンダー、コンサルタント )




 以前、都市銀行にてATM開発を担当してました。今回の統合ATM問題とはやや主旨が異なりますが、ATMのサービス検討時において他行との差別化を意識してなのか通常メーカーが標準装備している機能に相当のカスタマイズニーズを安価で求めます。メーカー側SEもその銀行専任のチームを古くから組成して対応しており、もはや職人の領域です。ある新型ATMにおいては公共料金や小切手も取り扱うなど、窓口業務の更なるATM誘導のためリリースしましたが、利用頻度からでしょうか、全店への展開は見合わせてます。(かなりの体力を要して世に出したのですが...)

 そもそも、日本の銀行のATMに消費者はどこまでのサービスを求め、それに伴うリスクを心情的に許容してくれるものなのでしょうか? 開発側としては全く計りきれなく開発に没頭してます。欧米でのサービス内容に比べ日本のサービス内容は同等レベルなのでしょうか?やりすぎ?と感じながら開発する案件も多数を感じてます。

(40代、システム・インテグレーター、システムエンジニア )


 弊誌は、システム開発プロジェクトの成功率を上げる策として、プロジェクトマネジメントに積極的に取り組むべきだ、という趣旨の記事を何度も取り上げています。

 リスクを認めて、代替手段を用意しておく。実はこれは、プロジェクトマネジメントの基本的な考えの一つです。金融機関のATMという公共性の高いシステムの開発に当たっても、まだプロジェクトマネジメントの採用は進んでいない、というのが現実なのでしょうか。

 3月3日のご意見を見ると、リスクを測定しないままにプロジェクトを進めることの弊害は、システムの開発段階から現れているようです。当然のことかもしれませんが、プロジェクトに伴うリスクを早い段階から把握することが求められています。

 3月4日には2件の意見がありました。1件目は、「ATM」の障害という言葉についてのご注意です。



 「ATMの障害」という表現は正確なのか?ATMというのは、端末のことではありませんか?とすれば、中継システムとかセンターシステムとか統合相互接続センタシステムといったシステムの障害と表現されるべきかと思いますがいかがですか?実際にトラブルを起こしている物、場所、企業、組織が矢面に出てこないと不公正だと思います。
(50代、システム・インテグレーター、情報システム部門 )


 ご指摘の通り、正確には統合ATMという新しい銀行間の相互接続システムや、同システムと各銀行のシステムの接続用ソフトの不具合によって、ATMが正常には利用できなくなったわけです。「ATMの障害」という言葉は、利用者からの視点で見るとどうなるか、ということを考えて使いました。

 フォーラムでは丁寧に書いていなかったかもしれませんが、日経コンピュータ本誌の「動かないコンピュータ」を併せて読んでいただければ、どこに原因があったかはわかると思います。決して、ATM端末や端末を製造したメーカーに対して批判しているわけではありません。誤解を与えたのであれば、申し訳ありません。

 3月4日にいただいたもう一つのご意見は、ATMに同時接続できる端末の数が増えていることが、トラブルの増加につながっている可能性について、指摘されたものです。



 ATMトラブルが多発するようになった原因は、非常に荒っぽい見解ですが、ATMの台数が増え、その処理数が増加したからではないでしょうか。信頼性が従来と変わらない場合、台数や処理数の増加に対して、障害の発生頻度は指数関数的に増加するものと考えられます。まして、各行の提携が進んで複雑化した為に、信頼性はむしろ低下しているのかも?しれません。

 対策としては、ATMの台数増加に歯止をかけることは当分できないでしょうから、信頼性を向上させるしかないと思います。その一つは、全体をシンプルなシステム構成に再構築して、複雑さによる信頼性低下を排除すること。もう一つは、システム開発手法を見直して設計段階から信頼性を徹底的に作り込むこと(品質はできるだけ上流工程で作り込むのとの考え方)。どちらも色々な意味で難しい課題ですが、それしかないように感じます。

(30代、ユーザー企業、情報システム部門 )


 実は数年前から、正月休みやゴールデンウイークの前後にATMが利用できなくなるトラブルが金融機関で多発しています。休みの前後であるこれらの時期には、ATMの利用が集中します。ご指摘いただいたように、他の金融機関やコンビニなど既存の支店以外のATM端末が利用できるようになった結果、想定以上の端末からの取引が、システムの不具合を顕在化させるのです。
 ハードの能力を増強すれば問題は解決するのかもしれませんが、システム関連の投資を抑制しようという現状のなかでは、なかなかハードの増強もままならないのでしょう。

 ですが、金融機関のATMの相互乗り入れやコンビニATMの利用は時代の流れです。これに逆らうのは難しいでしょう。ベンダーの提供するパッケージを使うのか、オープン系のハードに移行してコストを下げるのと同時に、開発手法を含めて見直しを進めるのか、それとも既存のメインフレームを使い続けるのか。いずれにしても、金融機関にとっては難しい選択だと思います。

 今回は、いただいたご意見に長いものが多く、フォーラムの総括編もかなり長いものになってしまいました。最後までお読みいただき、有難うございました。

 またフォーラムの進行スケジュールの関係で、ATM障害についてはタイミングよく取り上げることができませんでした。できれば、今年はもう少し機動的にフォーラムを展開する方法がないかどうか、考えていきたいと思っています。