東日本全域にわたって未曽有の被害をもたらした大震災。筆者は東北地方には多くの知人がいる。以前、当コラムでご紹介した千田精密工業の工場は、今回の震災でも特に被害の大きかった岩手県大槌町にある。今後の復興に少しでも力になることができればと思う。
震災の影響で発生した福島第一原子力発電所の事故は、ニュースや解説記事を読んでいろいろと考えさせられることが多く、トラブル対応の難しさを改めて強く認識させられた。また、筆者は銀行担当のSEとしてキャリアをスタートしたので、同時期に発生したみずほ銀行のシステム障害も高い関心を持って見ていた。メガバンクのシステム障害が数日間も継続する事態はIT業界では大事故である。
どちらの事故も、はたから見れば「対応が後手後手」「決断が遅い」と現場を非難する材料には事欠かない。また後日の検証でも「こうすればよかった」「あの時点で決断していたら被害は小さかった」とタラレバ論は山ほど出てくるだろう。しかし現実には、現場が最善を尽くしても悪循環に陥ってしまうことも多々あるのだ。筆者はこれまでに大小いろいろなシステム障害を経験してきた。現場担当者が実際にトラブル対応しているときの心理的な負担や、部外者からの批判にさらされたときの気持ちはよく分かる。
懸命に最善を尽くしているのに対応がうまくいかず、障害が長引いてしまう原因の一つは、特定の担当者への依存状態になることだ。筆者が経験したあるシステム障害のケースを紹介しよう。
あるとき何の前ぶれもなく、オンラインシステムが停止した。すぐにバックアップ機が起動したが、なぜか正常に動作しない。現場の緊張感は一気に高まった。プロパーのシステム部員だけでなくベンダーのSEも飛んできて、運用ルームはごったがえした。
多数のエンジニアがいても、実際にトラブル対応のオペレーションを実施するのは1人か2人。周りは見ているしかなかった。それはある意味当然だ。複数のメンバーが同時にあれもこれもと勝手にオペレーションしたら、収拾はつかなくなる。
このトラブルの場合、オペレーションを実行したのはリーダークラスの最も優秀なベンダーSEであった。理想論でいえば、リーダーは端末から離れ、全体の状況を把握して各種の判断をし、部下にオペレーションの指示を出すべきであろう。しかしいったん大規模な障害が発生したらそうはいかない。最高のSEが事に当たるのは間違いではない。多くの場合、それによってより短時間で解決できるからだ。
しかし、障害原因が複雑だったり、初動に誤りがあったりして対応が長引くと、そうしたことが裏目に出てしまう。このケースでも、リーダーが脇目も振らずに対応する一方で、周りのSEはいまどんな状況なのか分からなくなった。聞くに聞けない雰囲気なのだ。やがてシステム部長や役員たちが「どうなっているんだ」とやって来た。状況が分かるのはリーダーなので、作業の手を止めて説明を始める。周りのSEはそれを聞いてようやく状況を理解した。
その時点でオペレーションを他のSEに任せ、リーダーは指揮命令に徹すればよかった。だが、緊迫した状況であり、上長たちから「早くなんとかしろ」と厳しい口調で言われたために、リーダーはまたオペレーションに戻ってしまった。最初の体制立て直しの機会を失ったのだ。その後もリーダー1人に過大な負荷が掛かり、情報が滞留して悪循環に陥った。結果として、解決までに数日を要することになった。
トラブルのときこそ、指揮命令系統の明確化によって情報を整理して流通させ、作業の負荷分散を図り、全体的な視野を確保するようにしなければならない。「言うは易く行うは難し」ではあるが。IT業界としても、トラブルマネジメントは大いに研究していく必要があるだろう。
