最近になり,繰り返しシステム障害に見舞われる現場が増えていると感じる。ここでシステム障害というのは,システムがカットオーバーした後に発生した,処理停止,処理誤り,処理遅延(性能劣化),情報漏えい・改ざんなどを指す。

 東京証券取引所は,その典型例だ。2005年11月には全銘柄の取引停止,12月にはジェイコム株大量誤発注に際して注文が取り消せない不具合が明らかになった。さらに2006年1月には,売り注文の殺到で約定件数がシステム処理能力の限界近くに達し,後場を通常より20分短縮して14時40分に終了する事態に追い込まれた。再発防止に向け,2月1日にNTTデータフォースの鈴木義伯氏がCIO(最高情報責任者)に着任した。

 なぜ,東京証券取引所はシステム障害を繰り返してしまったのだろうか。システム障害の原因は,11月は設定ミス,12月はレア・ケースのテスト漏れというように,一見するとバラバラだ。だが,取材や報道で得た情報を掘り下げていくと,システムにかかわる担当者間に生まれた“すき間”が,原因に深くかかわっていることが見えてきた。

 東京証券取引所のシステム担当者は主に企画が中心で,システムの全容を詳細に把握している技術者はいなかった。このため,開発ベンダーである富士通や日立製作所,運用子会社である東証コンピュータシステムに,事実上任せきりになっていたようだ。その結果,例えば11月のシステム障害では,プログラムのバグを本番機上で開発ベンダー(富士通)に修正させるという異例の措置を許した。

 本来は,富士通はテスト機でプログラムを修正し,東証コンピュータシステムが本番機に反映させるルールだった。しかし“緊急対応”の名の元に,ルールはたびたび破られていたようだ。この異例の措置により,プログラムを本番環境に移行する手順が平常時と変わった。富士通は臨時の作業手順書を作成したが,そこに記述ミス(手順もれ)があり,システム障害が発生した(参考記事)。

 東京証券取引所は,ルールに反したやり方を断固として禁止するか,許可しないと実務が回らないならば緊急時(例外時)を想定した手順書を作成しておくべきだった。ところが,東京証券取引所では,どちらを徹底することもできなかった。一方の東証コンピュータシステムや富士通は,自分たちの責任範囲をあいまいにしたまま,異例の措置を続けてしまった。例外時を想定した手順書の必要性を,東証コンピュータシステムや富士通が認識していなかったとは思えない。薄々気づきながらも,東京証券取引所に進言するには至らなかったのではあるまいか。ここには,東京証券取引所,東証コンピュータシステム,富士通の三者が,本来果たすべきだった役割の“すき間”が見て取れる。

 同じようなすき間は,他の多くの現場で発生し得る。また,すき間はユーザー企業の担当者と開発/運用ベンダーの担当者との間だけでなく,経営者と現場担当者との間にできることもあるだろう。稼働中のシステムに対して機能拡張や改修を繰り返すケースでは,開発担当者と運用担当者の間にもすき間が生じやすい。団塊の世代が相次いで定年退職を迎えることでシステムのノウハウが失われるという“2007年問題”は,設計者同士など同じ役割を担う世代間に生じたすき間ととらえることもできる。あなたと同僚とのすき間が,システム障害を繰り返す要因になりかねないのだ。

 3月26日に発刊される新雑誌『日経SYSTEMS』(詳細を見る)の連載「深層ルポ なぜ繰り返すのかシステム障害」では,このようなシステム障害の温床となる,人と人の間に生まれるすき間を具体的に洗い出そうと考えている。すき間を洗い出し,なぜそれが生じたのか,なぜ解消できないかを分析することで,システム障害を繰り返してしまう真の理由に迫りたいからである。そうすることで,システム障害を繰り返さないための教訓の一端を導き出せると考えている。

(実森 仁志=日経システム構築