脆弱な情報システムの類型と対応
通常の業務系システムは、一定程度のバグや操作ミスがあることは避けられないという前提の下、一定の不都合な結果の発生は黙認している（せざるを得ない）状況にあると思われます。費用対効果を考えれば、これはやむを得ないとも言えるわけですが、以下に挙げるようなシステムについては、その費用対効果が破れるリスクが高く、再考を迫られます。自社のシステムの中に、こうした性質を持ったシステムがないか、注意しておく必要があります。
結果重大型 筆頭に挙げられるのは、原因によらず、事故が起きた際の結果が大きいシステムです。医療や航空、社会インフラ関係など、いわゆる「重要インフラ情報システム」がこれに該当します。一般企業の基幹系システムでも、コア業務の管理・遂行に関わる部分や請求・支払等の金銭に関わる部分は、他の部分とは異なる扱いをしていることが多いはずです。
障害対策については最も知見が蓄積されている分野ですが、システムのライフサイクルにわたる、技術面と手続面の双方からの品質確保が基本です。多重化やフェイルセーフの考え方も必要となってきます。
メルトダウン型 これは、原因となるミスや不具合があってから直ちに結果が発生し、あるいは多少の時間的余裕があっても結果の発生を防止する実効的な手段がない、というシステムです。「１円６１万株」の誤発注が数分のうちに次々と取引成立していった東証の事件が思い起こされます。結果が不可逆的であるという意味で、情報流出を引き起こすおそれがあるシステムも、これに相当すると言えます。
システムの（と言うよりシステムを含めた仕組み・業務全体の）停止・遮断が可能なように設計しておく必要があります。東証の事件でも、売買停止措置へのためらいが状況を悪化させました。
自動車事故型 これは、わずかのミスや不具合が重大な結果を生ずるシステムです。ある程度の結果を生じさせるのに相応のミスや不具合が必要であれば、原因も絞れますのでそれなりの対処を考えることはできます。しかし、この型のシステムはそうではないため、延々と続く走行の中の一瞬の注意不足が命取りとなる、自動車事故さながらの状態となってしまいます。
事故を防ぐためにはノーミスで塗り固めなければならない点に困難があり、システムのあり方自体を再考する必要があります。場合によっては、システムの存廃までを選択肢に入れるべき場合もあるかも知れません。
潜伏累積型 これは、実際には結果が発生してもすぐには気づかず、気づいた時には累積した結果が重大なレベルに達している、というものです。法人間の過大請求が数年分もたまっていた、といった報道が時々ありますが、大量反復型の取引では、請求側はシステムを信頼するしかない、請求される側は実際問題として分からない、そのため何かの偶然のきっかけがなければ発覚しない、ということなのでしょう。
導入時のテスト以外に、稼動中のモニタリングやサンプリング調査といった監査的な仕組みが必要となりそうです。特に、何らかの変更があった後の一定期間は、集中的なチェック対象とすべきです。
一発勝負型 これは、問題があるかないかテストできない、あるいはテストしないというものです。情報システムでテストできない、テストしないなどあり得ないと思われるかも知れませんが、テストの際の環境や条件を本番と十分に一致させられないシステムや、ユーザの多くが実は十分なテストをしないＥＵＣ絡みのシステムは、実質的にこの類型に入ります。ロジックの多くをパラメータ制御しているシステムも、この型のリスクがあります。
本体アプリケーションとは別に、そのままでは不可能／非効率なテストを可能にするための、特別なアプリケーション（あるいは仕組み）が必要となります。「本番で枯らす」という考え方は、障害のマイナスがよほど小さくない限り、避けるべきです。