東証のシステムがダウンして，いわゆる株の取引が完全に麻痺状態になってしまったそうです。そして，原因は，このシステムにプログラムミスがあったためであることが判明しました。
危機管理マニュアルはないの？
通常は，サーバが壊れるなどに備えて，二重化三重化等の対応を講じていますが，今回のようなプログラムミスの場合，システムを多重化しても防止することはできません。
現状のシステム社会における最大の問題点は，「システム自体に欠陥があった場合，一瞬にして全業務が停止する」という点です。今回も，株取引ができなかったことから，国内外の投資家には多大な損害が発生してしまいました。
では，これを防ぐにはどうすればよいでしょうか。一つは開発業者のスキルを上げることでしょうが，どんなに優秀な業者でもバグは発生します。そして，僅かなバグでも，機能停止してしまうことはあります。
第二の手法としては，完全稼働を確認するまでリリースしないことですが，やはり業務の効率化を考えると，一応動くことが確認できる場合，どうしてもリリースせざるを得ないものです。
とすると，最後に考えるのは，「危機管理」です。つまり，「システムは必ず壊れるもの」という大前提の元に，壊れた場合の機械保守はもちろんのこと，壊れたときの業務フォローをどうするのかという点を事前にしっかりとマニュアル化しておく必要があります。
残念ながら，システムにおける危機管理マニュアルについては，機械の復旧に重点を置いている会社は多いですが，その間の業務フォローについて，きっちりとしている会社は少ないのではないでしょうか。
現に，羽田空港での電源トラブルや，管制塔のトラブル等の際も，空港業務が完全に停止してしまいました。
機械に頼っているから仕方がないという意見もありますが，もし大災害が発生した場合，どう対応すべきなのか，ということを視野においた場合，これからは「機械に頼らない非常時の業務はどうするのか」という観点をしっかり持って検討する必要があるでしょう。
以上今日のトピックスでした。
（続きのあとに追記があります）
よろしければ１クリックお願いしますm(__)m→人気blogランキングへ
（１１月３日追記）
危機管理に対する対応について，いろいろご意見いただきました。ありがとうございました。
ここで，危機管理に関する私の考え方をまとめておきたいと思いますので，またご意見ご指摘をいただければ幸いです。
１ 危機管理対策とは，早期復旧とシステム停止中の混乱防止にある。
システム障害が発生した場合，大至急システムを復旧させる必要があるわけで，それについて連絡体制も含めたマニュアルは確実に存在します。
問題なのは，システム停止中の業務をどうするのかという点です。これについても，もちろんマニュアルは存在しているはずですが，業務ができない以上，結局「ごめん」という以外にすべがない，というマニュアルになっている場合が多いのではないでしょうか。
しかし，「ごめん」というだけではなく，混乱防止のための手法をいろいろ検討しておく必要があるといえるでしょう。
コメントを頂きました中で，羽田空港での停電トラブルでは，事故などが発生しなかったというものを頂きましたが，あれはまさに「ごめん」以外の混乱回避マニュアルが存在していたのだろうと私も思います（この点は，当初の本文から認識を改めました。）。欲をいうと，その状態でも最低限の業務が行えればベストなのでしょうが，人命がかかっている業務の場合は，「あえて通暁業務は行わない」という手法もありなのかもしれません。
２ システム停止中の混乱防止とは，ミニマムな業務の継続にある
システム停止はどこに原因があるにせよ，少なくと顧客には罪がありません。したがって，顧客のニーズを完全でないにしても多少は顧客満足度を満たす必要があります。
そのためには，ミニマムであっても業務を継続する手法を考えなければなりません。ただし，ミニマムな業務とは，前述のように「安全最優先」ということも当然含まれます（むしろ，人命がかかるような業務の場合は，ここに全精力をおくべきでしょう）。
３ ミニマムな業務のためには必ずしもマンパワーである必要はない
システム停止中のミニマムな業務継続のために，平素から人力による業務を併行して行うのか，というとそれは必ずしも適切ではありません。人力を省力するためのシステム導入，という本旨に反するからです。
では，システム停止中の措置はどうするのか。これは，「他社のシステムの同時稼働」です。
もちろん，全く同じものを開発することは，多額の費用がかかり，かつ無意味になる場合が多いです。そこで，「ミニマムな業務」に視点を置いたサブシステムを導入しておきます。
例えば，毎日データをバックアップしているはずですから，サブシステムではそのバックアップデータを流し込めば，現状把握（検索照会機能）ぐらいが行えるようにしておくわけです。もちろん，業務系の一部が担えればそれもサブシステムに盛り込みます。
あくまでもサブシステムは「保険」です。
４ システム障害には無数のバリエーションがある
想定されるシステム障害を洗い出し検討する，ということがシステム監査の項目にも含まれていますが，現実には，想定しない傷害が発生します。
したがって，その障害に応じて応急措置はいろいろ考えられますが，少なくとも他社サブシステムによる応急措置であれば，例え一時的であれ，当座の混乱は解消できるはずです。
５ 更新時が要注意
機器やプログラムの更新を行った場合，経験則上かなりの確率で不具合が発生します。
したがって，このような場合には，例えば不具合発生時は旧システムにすぐに戻すなどの保険を講じておく必要もあるでしょう。本番系で戻すことが難しいのであれば，ダミーサーバなどを一時的に用意しておくなどもありかもしれません。
いずれにしても，「ダメだと思ったら戻す」という手法も，状況によってはありです。
以上が危機管理に対する考え方です。一部には「非現実的」と思われる部分もありますが，「すべてはユーザのため」という発想に基づいていることはご理解ください。
危機管理マニュアルはないの？
通常は，サーバが壊れるなどに備えて，二重化三重化等の対応を講じていますが，今回のようなプログラムミスの場合，システムを多重化しても防止することはできません。
現状のシステム社会における最大の問題点は，「システム自体に欠陥があった場合，一瞬にして全業務が停止する」という点です。今回も，株取引ができなかったことから，国内外の投資家には多大な損害が発生してしまいました。
では，これを防ぐにはどうすればよいでしょうか。一つは開発業者のスキルを上げることでしょうが，どんなに優秀な業者でもバグは発生します。そして，僅かなバグでも，機能停止してしまうことはあります。
第二の手法としては，完全稼働を確認するまでリリースしないことですが，やはり業務の効率化を考えると，一応動くことが確認できる場合，どうしてもリリースせざるを得ないものです。
とすると，最後に考えるのは，「危機管理」です。つまり，「システムは必ず壊れるもの」という大前提の元に，壊れた場合の機械保守はもちろんのこと，壊れたときの業務フォローをどうするのかという点を事前にしっかりとマニュアル化しておく必要があります。
残念ながら，システムにおける危機管理マニュアルについては，機械の復旧に重点を置いている会社は多いですが，その間の業務フォローについて，きっちりとしている会社は少ないのではないでしょうか。
現に，羽田空港での電源トラブルや，管制塔のトラブル等の際も，空港業務が完全に停止してしまいました。
機械に頼っているから仕方がないという意見もありますが，もし大災害が発生した場合，どう対応すべきなのか，ということを視野においた場合，これからは「機械に頼らない非常時の業務はどうするのか」という観点をしっかり持って検討する必要があるでしょう。
以上今日のトピックスでした。
（続きのあとに追記があります）
よろしければ１クリックお願いしますm(__)m→人気blogランキングへ
（１１月３日追記）
危機管理に対する対応について，いろいろご意見いただきました。ありがとうございました。
ここで，危機管理に関する私の考え方をまとめておきたいと思いますので，またご意見ご指摘をいただければ幸いです。
１ 危機管理対策とは，早期復旧とシステム停止中の混乱防止にある。
システム障害が発生した場合，大至急システムを復旧させる必要があるわけで，それについて連絡体制も含めたマニュアルは確実に存在します。
問題なのは，システム停止中の業務をどうするのかという点です。これについても，もちろんマニュアルは存在しているはずですが，業務ができない以上，結局「ごめん」という以外にすべがない，というマニュアルになっている場合が多いのではないでしょうか。
しかし，「ごめん」というだけではなく，混乱防止のための手法をいろいろ検討しておく必要があるといえるでしょう。
コメントを頂きました中で，羽田空港での停電トラブルでは，事故などが発生しなかったというものを頂きましたが，あれはまさに「ごめん」以外の混乱回避マニュアルが存在していたのだろうと私も思います（この点は，当初の本文から認識を改めました。）。欲をいうと，その状態でも最低限の業務が行えればベストなのでしょうが，人命がかかっている業務の場合は，「あえて通暁業務は行わない」という手法もありなのかもしれません。
２ システム停止中の混乱防止とは，ミニマムな業務の継続にある
システム停止はどこに原因があるにせよ，少なくと顧客には罪がありません。したがって，顧客のニーズを完全でないにしても多少は顧客満足度を満たす必要があります。
そのためには，ミニマムであっても業務を継続する手法を考えなければなりません。ただし，ミニマムな業務とは，前述のように「安全最優先」ということも当然含まれます（むしろ，人命がかかるような業務の場合は，ここに全精力をおくべきでしょう）。
３ ミニマムな業務のためには必ずしもマンパワーである必要はない
システム停止中のミニマムな業務継続のために，平素から人力による業務を併行して行うのか，というとそれは必ずしも適切ではありません。人力を省力するためのシステム導入，という本旨に反するからです。
では，システム停止中の措置はどうするのか。これは，「他社のシステムの同時稼働」です。
もちろん，全く同じものを開発することは，多額の費用がかかり，かつ無意味になる場合が多いです。そこで，「ミニマムな業務」に視点を置いたサブシステムを導入しておきます。
例えば，毎日データをバックアップしているはずですから，サブシステムではそのバックアップデータを流し込めば，現状把握（検索照会機能）ぐらいが行えるようにしておくわけです。もちろん，業務系の一部が担えればそれもサブシステムに盛り込みます。
あくまでもサブシステムは「保険」です。
４ システム障害には無数のバリエーションがある
想定されるシステム障害を洗い出し検討する，ということがシステム監査の項目にも含まれていますが，現実には，想定しない傷害が発生します。
したがって，その障害に応じて応急措置はいろいろ考えられますが，少なくとも他社サブシステムによる応急措置であれば，例え一時的であれ，当座の混乱は解消できるはずです。
５ 更新時が要注意
機器やプログラムの更新を行った場合，経験則上かなりの確率で不具合が発生します。
したがって，このような場合には，例えば不具合発生時は旧システムにすぐに戻すなどの保険を講じておく必要もあるでしょう。本番系で戻すことが難しいのであれば，ダミーサーバなどを一時的に用意しておくなどもありかもしれません。
いずれにしても，「ダメだと思ったら戻す」という手法も，状況によってはありです。
以上が危機管理に対する考え方です。一部には「非現実的」と思われる部分もありますが，「すべてはユーザのため」という発想に基づいていることはご理解ください。