まりぱらおーぐ

主にコンピューター周辺の話を中心に、気ままに書いていきます。

東京証券取引所のシステム障害


日経BP記事より
それよりも問題にすべきは、東証富士通の力関係である。システム開発・運用業者などの外部人員がどこまで顧客の命令に従うべきなのか、年々保守サービスのスケジュールがタイトになるなか、出来る・出来ないを受託業者がどこまでコメントできる立場にあったかである。
私もシステム構築系の商売をしているワケですが、この手のニュースを聞くたびに、起こるべくして起こったなぁ...という感じがいつもしています。あとは、この案件を担当したSE、荒んでないかなぁとも思います(苦笑) 今回のシステム障害の原因は、月次処理の問題であり、かつ、その問題点については、富士通は気づいていた訳で、それを放置した富士通東証も問題があったということですよね。 その遠因は、システムの増設や改造。その手のことをした場合は、多くの場合において完全な試験を実施することは難しいので、仮のシステムを作って検証をした上で作業をする訳ですが、それに不備があったとも言えるでしょう。 この記事では、どちらかというと、事象が起きてしまった場合の対処のことを書いていますが、東証の対応に関しては、満点は無理にしても、多くの場合において、「対応」という点に関しては一定の評価が出来るものと思います。トップはすみやかに記者会見を行い、随時、情報も公開しているなど、取引所としては最低限するべきことはきちんとやっていますから。 今日、処分についても出ましたが、減俸ということで決着したようですが、それは裏を返せば、担当した技術者にとりあえず継続して担当して欲しいからこその関係を重視した上での決着なのかなという見方もしています。 どこかの記事で読みましたが、ベンダーを変えれば済むという問題ではなく、東証の側にシステム構築に関するノウハウを持った方が決定すべきですし、それがコンサルタントの仕事だったりもするわけですが、多くにおいて、予算のこともあるので要件を確定するより先におおまかなシステム構成は既に決定されていたりするので、構築していくうちに、実際の要件に遙かに遠いシステムが出来たりすることもあります。 最近、いろいろな仕事を担当していて、思うことの一つにシステムのリスクの考え方があまりされていないなぁと思う訳です。所詮は、機械な訳でいずれは壊れます。そのときに、縮退運転でどこまでの運用を保証して、どのぐらいの復旧時間を想定してシステム設計をするかという観点が抜け落ちていたり、負荷試験が十分にされていなかったり、負荷試験の考え方が間違っていたり(苦笑) 復旧時間が著しく短いのに予備機がなかったり、いろんなことがあります。 顧客のことばかりでなく、システムインテグレーターも、もう少し顧客の立場になって考えてアドバイスしてやれよと思うときもしばしばですし、技術屋のコミニュケーション不足もあったりと...。さしあたり、いつもこういうニュースを見るたびに、システム屋としては気をつけねばなぁと思う私なのでした..。

Copyright © 2002-2015 まりぱらおーぐ All Rights Reserved.