経営情報学会
『システム統合』特設研究部会
       
 東京証券取引所(以下,東証と略す)におけるこの度の一連の障害発生に対して,雑誌,新聞,ウェブサイトなどで公表されている資料をもとに,『システム統合』特設研究部会としての見解を述べる。

経緯
 東証で最近発生した一連のシステム障害で,社会的な影響が大きいものとしては,
  • 11月1日のシステムダウン,
  • 12月8日のみずほ証券誤発注のシステム対応,
  • 1月18日の約定処理キャパシティ不足による取引強制停止
の3件がある。これらのシステム障害における情報技術的な原因としては,運用の問題,アプリケーション仕様の不備,システムキャパシティ計画の見積もり不足などがあげられる。また,マネジメントの側面からは,情報技術的な対応の限界や異常事態発生時に備えたルール作りや体制整備面での課題などもあげられる。
証券ビジネスとして
 部会メンバーの一人は,かつてオンライン証券会社の情報システムに携わっていた。その視点から見ると,東証の経営者には,「証券取引所ビジネスが情報システムで成り立っている」という自覚が不足しているように思われる。特に最初のシステムダウン時に,委託先の社名を出して損害賠償について言及していることを見ると,情報システムの運用管理についての自らの責任を感じているとは思われない。また,証券取引所の情報システムという基幹業務をアウトソースしているということに対する本質的な理解が欠けているのではないかといわざるを得ない。一般的に今回のような対応をすると,現場の士気が大幅にダウンすると考えられ,また,すぐに損害賠償などの話が出てしまうと,対応が防衛的になる傾向がある。
キャパシティ問題
 キャパシティ問題については,増強の方向で進められているが,後手後手に回っている感がある。最近の株取引の主体は,オンライン証券を利用した個人投資家である。その意味で東証は,間接的にオンライン証券会社を経由した,eビジネスを営んでいると云える。eビジネスの特徴の一つは,物理的な制限がない,または見えない点である。従来の対面営業においては,支店の顧客窓口,コールセンターのオペレータの人数,また営業員の人数などの制限によって,注文の集中は分散・平均化される。しかし,eビジネスにおいては,顧客の注文の集中は,そのまま証券会社を経由して,東証のシステムを直撃する。そのためキャパシティプランは,等差数列的な増強では,なにかあったときには対応しきれないので,幾何級数的な増強が必要になる。
 それでも,処理能力の増強には限界があり,技術的に対応が困難,あるいは法外な費用がかかる可能性も残される。その予防対策としての小口取引の手数料体系のあり方や,非常時の流入制限などの制度的スキームについても,きちんと議論したうえで,事前に関係者の合意形成をはかり,事態の収拾を円滑に進めることができる体制を整える必要がある。
 ただ,流入制限については,現実的にはオンライン証券会社が軒並みキャパシティを増強している現状を考えると,東証の入り口での実施には,公平さを担保するという観点から技術的にかなり難しくなると思われる。というのは,証券会社は,自社のサーバーに入った注文は執行する責任が発生するため,ここで遅れがでて顧客に損失が発生した場合には,賠償責任に発展するからである。
システム障害は避けられない
 ところで,今回のようなソフトウェアのバグやシステムの運用ミスに対する,マスコミを含めた社会の対応は,建築物の施工ミスと同じ類の問題として認識されているように感じられる。すなわち,事前に仕様をきちんと決めて,そのとおり実装,運用すれば,ミスなどは起こりえない話であり,したがって,障害が発生したのはソフトウェアの作成側やシステムの運用サイドに問題があるという論調である。人間は神ではない。それゆえ,過ちを犯す存在であり,また現在のような巨大化し,複雑化したシステムに対して,その実装や運用におけるミスを100%防止することは可能であるはずがなく,したがって,システム障害は自然災害と同じように,発生することを前提に対処法を考えておくべきであると思う。
 ソフトウェア工学の観点からは,システム障害が起きたときに,その原因を短時間で究明し,改修できるように,対象となるシステムを構造化しておくことが必要である。そのためには,きちんとした情報システム・アーキテクチャにしたがって,トラブルや変更に強い柔軟な構造を持つシステムを作ることが必要である。
 一方,マネジメントの観点からは,今回の問題に即して具体的に考えると,処理能力を超えそうになったり,取り消しが出来ないというような,異常状態に対して,市場閉鎖のような措置をすばやく発動するような,障害発生を前提としたルール作りや体制の整備が必要であろう。
 わが国では一般に,システム障害が発生するとまず責任問題が取り上げられ,ベンダー側が責任を取れば一件落着のような風潮がある。ベンダー側も,責任の所在をめぐってユーザー企業と対立するよりも,長期的な付き合いを大事にした方がビジネス上有利であるとの判断からか,今後トラブルが発生しないと断言することはできないにもかかわらず,再発防止を約束して謝ることによって丸く収めようと傾向があるのではないだろうか。その結果,ユーザー企業側の問題が顕在化しないだけではなく,ベンダー側の再発防止策も中途半端になっていると言わざるを得ない。
 このようなシステム障害が発生した場合には,できるだけ情報を開示して,広く建設的な議論を巻き起こし,できるだけ,再発防止のためのノウハウが社会的に蓄積することが必要であろう。「失敗」から学ぶためには,障害発生を次の失敗を起こさないための契機として捉えることが必要である。発注側と受注側の責任の押し付け合いになることもあるので,航空機事故における調査機関のような,第三者機関による公正な分析や判断ができるような仕組みがあるとよいと思われる。
アウトソースITガバナンス
 最後に,ガバナンスの問題として次にくるのは,アウトソースしたときの,発注側の体制の問題であろう。実質的に丸投げしたとしても,発注側に最低限残さなければならない機能は何なのかということである。1月25日づけの朝刊に,やっとCIOを任命したのと記事が出ていたが,小手先だけでなく,ITガバナンスを全面的に見直し,体制を再構築することが必要と考える。また,先に述べたように,今回の一連の障害発生を「社会知」として共有するためにも,こうした問題の発生と収拾の経緯については,積極的に公開を進め,再発防止についてのノウハウの社会的な共有をはかることが重要である。
以上
『システム統合』特設研究部会は,2002年4月に発生した,大手銀行のシステム障害事件を契機に,経営情報学会で設置した特設研究部会である。昨年10月に報告書『成功に導くシステム統合の論点』(日科技連出版社)を上梓している。
メンバーは,下記である:
飯島淳一(東京工業大学・大学院)
伊藤誠彦(日本IBM)
繁野高仁(KDDI情報システム本部)
島田裕次(東京ガス監査部)
手島歩三(ビジネス情報システムアーキテクト)
南波幸雄(エスバーグ)
森田勝弘(県立広島大学)
山本修一郎(NTTデータ技術開発本部)
この見解に対するご意見,ご質問は,iijima@me.titech.ac.jpまでお寄せください。
ページの上へ