システム障害(証券業界で頻発)



少し古い記事ですが、日経新聞平成17年9月3日号に、ネット証券や取引所のシステム障害が頻発しており、業界・行政ともに危機感を強めているというニュースがありました。

昨年、金融庁に報告された証券会社オンラインの障害件数は70件だったそうで、今年は更に増えているそうです。登録証券会社数は232社ですから、3社に1社が年1回のシステム・ダウンを起こしていることになります。こう考えると、余り頻繁だとは言えません。それに、1社だけで取引する顧客も少ないでしょう。電話注文を含めて代替手段がありますし。ただ、当局に報告するのは、顧客に重大な支障を来す場合となっていますので、報告されない短時間障害や規模の小さな証券会社の障害を含めれば、もっと多くの件数にはなるでしょう。重大な障害の具体的基準はありません。ただし、当局への報告をしないでいて、マスコミなどに報道されるような事態は、悲惨なことになります。ですから、銀行は些細な障害でも、一応報告するようです。

今回、日経の記事になったのは、ハイテク装備と思われ、知名度の高いネット専業証券やジャスダックでの障害が続いたためです。典型的なディ・トレイダーは、大手証券1社、ネット専業2社で取引しています。大手からは市場情報を入手し、ネット専業は売買手法や手数料で使い分けています。1社のシステムが停止していると、もう1社で注文しますので、その会社のデータ量が急増します。そして、共倒れのスローダウンが危惧されるようになりました。金融庁はネット専業証券6社のシステム担当役員を呼んで、障害対策の強化を要請したということです。連鎖障害を恐れたのでしょう。

新聞記者の中には、オープン系システムの限界と考える人もいます。確かにオープン系技術の特質が原因と言える面がありますが、それには回避策があります。むしろ、設計ミスや要件漏れ、そしてデータ量予測の失敗など、かなり単純なミスが多いようです。加えて、売買手法が多様化していること、ネット取引が普及して取引の頻閑格差が極端になったことなどがあります。ソフトの説明をしても役所やマスコミには理解できませんので、証券会社側はハードの増強を強調します。しかし、やたらとハイMIPS化したり、ディスク容量を増やしても効果は限定的です。オープン系の場合はチャネルが弱いので、そこがネックとなるからです。また、システムは有機体ですから全体のバランスが大切なのですが、証券関連SEは、昔からアーキテクチャが嫌いです。ややこしいことは考えずに、直ぐに作り込みをやりたがります。デザインレス開発が大好きです。

ところが、オープン系の場合はマルチベンダーとなります。複数ベンダーの製品や技術者を集めて構築するのですから、設計とプロジェクト管理が重要なのですが、そのトレーニングを積んだ人材は少ないのが実態です。製品間のインタフェースが最も開発負荷とリスクのある作業にも関わらず、それを理解する経営者はいません。業務プロセスを大量に安く作ることばかり考えます。オープン系では、アプリケーション・エンジニアが主役で、システム・プログラマーは面倒なことばかり言う存在と思われています。ベンダーは、これをもって戦略分野への人材投入と言い、若い技術者の間では、システム・プログラマーは死語となっているようです。結果として、バッファーのサイズ設定や例外処理発生時のロジック・エラーなど、ベテランSEからすれば唖然とするミスが原因のことが多いと言います。バグは、要件定義、設計、コード開発の各段階で3分の一ずつ組みこんでしまうという統計結果があります。開発時のテストで発見できるのは、コーディング・エラーだけですから、多くのバグは未発見のまま本番を迎えてしまいます。

この状態になると、小手先の対応では解決できません。再構築となります。大手証券や銀行の基幹系システムは20年以上も稼動し続けています。業務が変わっていないということもありますが、枯れた技術の安定性と長寿命を考えると、オープン系よりも低コストで安全と言えるでしょう。

オープン系とレガシーの良いとこ取りができればベストです。IT技術も製品も、オープン化・コンポネント化していきます。つまり、アンバンドルと水平構造化が進みます。それらのバランスを取りながら統合する必要がありますが、そのためにはアーキテクチャが最重要となります。残念ながら日本にはアーキテクトを育成する仕組みが存在しません。このコラムで何度も申し上げていますが、オペレーター経験のないSEが作るシステムは運用が難しく、開発をしたことのないSEが設計するシステムは作るのが難しい。適当な試験で資格ばかりを重視していると、実践的な技術者は育ちません。ITケイパビリティ強化のためには、スキル育成計画が最も重要なことが明らかです。ましてや、他人に丸投げなどは。