ミスによるシステムトラブルを防ぐ5つのポイント

システムトラブルの30%はうっかりミス

あいかわらずシステムトラブルが続いています。

2012年3月、日立製作所グループ120社で電子メールが使えなくなり16万人に影響しました。原因はソフトのバーションアップにともなう設定作業の見おとしでした。

2012年2月には東京証券取引所のシステムでトラブルがおき、241銘柄の取引ができず市場が混乱。

深夜に障害発生があり、担当者が富士通の夜間保守窓口に電話とメールで連絡します。富士通のSEが障害診断リポートを携帯電話のメールで確認したところバックアップ体制をまかせている他のマシンが順調に動いていました。これなら障害がでているマシンを引き継いでいると判断しましたが、これが判断ミスで引継はできておらず朝から取引で市場が混乱。担当者も富士通にまかせきりで、みずから確認していませんでした。

2012年6月、レンタルサーバーのファーストサーバで、データ消失をともなう大規模障害が発生。消失した顧客データが復旧不可能となりました。原因は更新プログラムのバグとバックアップしていた領域にも更新プログラムを同時適用するという運用の不備。せっかくのバックアップデータが消えてしまい復旧不可能になりました。

システム導入事例
みずほ銀行、全日空などシステムトラブルの事例をガイド記事としてまとめています。

システムトラブルの30%はうっかりミスと言われています。システムの複雑さが増しているなか現場でのミスが起きやすくなっています。トラブルを防ぐポイントをみていきましょう。

ポイント1　誤った合理化をしない

ポイントの1つが誤った合理化。システムはコストとみられがちで財務担当の役員は情報システム部の予算をなんとか削減できないかと目をひからせています。

情報システム部の社員を減らし、ITベンダーにアウトソーシングしたほうがコスト的には安くなるという話を聞きますが、安易にアウトソーシングすると、技術やノウハウが社内から失われます。アウトソーシングした当初は、システム作りに携わった社員が社内に残っていますのでITベンダーとの打ち合わせにも対応できコスト削減効果がありますが、時間がたつと人事異動などで経験者がへっていきます。

数年たつとITベンダーと仕様をどうつめたらよいか経験がない社員ばかり。仕様を中途半端な形でつめてしまい開発を進めた結果、途中で手戻りが発生。終わってみたら高くついた、使いものにならないシステムとなったという話はよく聞きます。またできあがったシステムには仕様ミスが紛れこむ可能性がふえます。

大手企業のなかにはシステム部門を子会社化し、さらに大手ITベンダーに売却するところも。これでは蓄積してきたシステム構築・運用スキルをすてるのと同じです。昔と違い業務をおこなうのに社内システムはなくてはならないインフラです。ムダな経費は削減すべきですが、必要以上の合理化は会社のインフラをみずから壊していることになります。

ポイント2　なぜなぜ5回を繰り返す

トラブルが起きると対応策を考えます。たとえば東証のトラブルであればSE一人にチェックをまかせず、複数でチェックする体制を作る対応策が考えられます。きちっと運用することで、同じようなトラブルを抑制することはできますが対症療法にすぎません。これで満足せず、トラブルの真因をさぐっていかなければなりません。

多くのトラブルは仕組みの問題に起因します。トラブル時の障害診断リポートの確認を携帯電話の小さな画面でおこなったことでトラブル発生を見逃したのなら、なぜSEが携帯電話で確認せざるをえないような状況に追いこまれているかを確認しなければなりません。

夜間保守窓口の人数がたりず、他のトラブル対応でSEが外へでており携帯電話で確認せざるをえないのであれば、夜間保守窓口の運用がまずく運用の見直しから考えなければなりません。ファーストサーバのトラブルも最終的には運用の不備が原因の一つになっていました。

「なぜなぜ5回」というトヨタのカイゼン運動の言葉があります。トラブルに対して、1～2回考えるだけでなく何度も何度も徹底的に考え抜く大切さを示した言葉です。”なぜ”、”なぜ”を繰り返し真因をさぐりましょう。