システム障害対応の本質を語らう

システム障害対応に「標準」が存在しない現実

中島　とはいえ、アラートや問い合わせを受けてから実際にどう対応するかは試行錯誤の連続です。プロジェクトマネジメントには PMBOK のような標準がありますが、システム障害対応そのものの標準的な手引きはないのでは？という印象です。

野村　実際、障害対応をどう管理すべきかの世界標準は存在しないに近いです。運用のベストプラクティス（例：ITIL）のような枠組みはありますが、障害時に何をどうやるかまでは具体的に書かれていない。多くの企業には厚い障害対応マニュアルがありますが、現場では開けられず、アドリブで回してしまう。まずは小さく始めるのがおすすめです。重厚長大なドキュメントを作る前に、少数の効くポイントを押さえる方が改善します。

責任ではなく“アクション”――復旧思考への転換

中島　責任追及に話が流れやすい点も課題ですね。ベンダーはどうしても「誰のせいか（自社か、メーカーか、インフラか）」という話に行きがちですが、まずは使えない現状で、何をどうするかを決めるのが大事。ユーザーにとって最優先です。

野村　まさに。事象（何が起きたか）ではなくアクションに注目する。復旧のための技術的アクションだけでなく、情報発信や代替手段も含めて選択肢を決める。責任分担探しに偏るのが最も不幸です。サービスが通常に戻るまでは事業会社・ユーザー企業・ベンダーが協力し、終わった後に責任や再発防止を議論するのが健全です。

中島　先日、3.11の福島第一原発で何が起きたかのルポを読みました。最悪だけは避けるという現場のアクション集中が印象的でした。

野村　私自身、大学で地震研究をしていて、卒業直前に東日本大震災が起きました。各地からボランティアが集まり助け合ったことに感動しました。一方、システム復旧では責任の所在が曖昧で助け合いが難しいことがある。だからこそ協同の姿勢を強調しています。ベンダーもユーザー企業も少しの協力で大きく良くなります。

平常時こそ準備を――“止まる”前提で考える

中島　今日、システムは100％稼働を保証することは現実的に難しいですね。だからメーカーもベンダーもSLAを作成し、例えば 99.9％の稼働を保証する代わりに0.1％の停止は許容いただく、というような話になりますね。とはいえ、その0.1％が最繁忙時間に当たればユーザーが怒り、混乱するのは当然です。ただ、インフラや電力・通信の障害でシステムが止まることもあるので、止まる可能性を前提に考えるべきなんですよね。

野村　同意です。「起こり得る」前提で会話し、対策を打つ方がより良いサービスにつながります。
明日から使えるアクションを一つ。次回の定例で5分だけ、「このシステムが全停止したら何をするか」を平常時に話し合ってください。緊急時は冷静な判断が難しい。平時に選択肢を持っておくだけで次のアクションが格段に良くなります。あるお客様はから「このサービスさえ生きていればまずは良い」と明確化していただいたことで、我々も最優先の確認と報告が迅速になった経験があります。

中島　当社が導入している業務システムでは受注・発注管理が主です。たとえば他の機能が落ちても、「今日受けた受注を請求まで処理できること」を最優先にする等、守る範囲を決めておくのは重要ですね。

野村　その合意があるだけでコミュニケーションは劇的に良くなります。さらに「どうしても無理な場合の代替」も決めておく。決済システムなら、クレジットのオンライン承認が落ちた際の電話承認など、最後の手段を用意しておくと安心です。多くの障害は数十分〜数時間の範囲なので、その橋渡しができれば良い。

中島　システムリリース前に「こういう時はこうする」を決めておきたいですね。

野村　5〜30分話すだけで十分な価値があります。障害報告の場だと弱気になって無理な約束をしてしまうので、平時に話すのが一番です。

中島　この考え方はシステム障害に限らず、緊急性のある意思決定全般に応用できますね。最悪ケースを平時に想定し、ベンダー側・ユーザー側ともに業務知見を持つ人同士が落ち着いて時間を取る。それが大事です。

情報は量より質――混乱を防ぐ現場の知恵

野村　もう一つのポイントは、情報は量ではなく質です。「何でもいいから情報を」と言うと、現場は不要情報まで集めて疲弊します。例えば復旧見込みなら「30分以内か、それ以上か」で十分役立つことが多い。何の判断に使う情報で、どの精度が必要かを一言添えていただけると、回答が速くなり、意思決定も早まります。暗黙の時間基準（15分なのか30分なのか）もすり合わせると質が上がります。

中島　障害は起きる前提で、必要な情報・基準（例えば通知は何分で出すか等）を決めておくべきですね。現場では言いづらい時もありますが、平時に合意しておけば必ず役に立ちます。

野村　そう言い出しにくい場合は、「野村がそう言っていたので一度話しましょう」と私のせいにして進めてください（笑）。最近の大規模クラウド障害のように、我々ではどうにもならない事態もあります。そのとき何を優先し、どの情報をどう出すかを話し合っておくのはとても有益です。定期的にユーザー企業に伝え、社内にも共有しておくことで、いざという時の初動がスムーズになります。経験が少ない部署ほどパニックになりがちなので、事前の避難訓練のようなシミュレーションが効きます。

避難訓練のように――“想定外”を想定する組織へ

中島　ユーザー企業の方々にも「起こり得る」「人的ミスでなくても起こる」ことを理解いただき、自社での備えと同時に、ベンダーとの接し方・渡す情報を整理しておいていただけると、トラブルを一緒に乗り越えられると思いますね。

野村　まさにおっしゃる通りです。最後に、普段私がお伝えしている3つのポイントです。

中島　確かにこの原則を押さえておくことで、ベンダー側もユーザー側も落ち着いて障害に向き合えそうですね。今日はありがとうございました。

野村　ありがとうございました。

対談のまとめ

野村さんとの対談を通じて、改めて感じたのは「障害対応とは、技術だけの話ではない」ということでした。システムを支えるのは結局、人であり、チームであり、関係性なのだ、と普段から考えてきたことに確信を持つことができました。

障害やトラブルが起きたとき、私たちはしばしば “誰が悪いのか” を探しがちです。しかし、最も重要なことは「どうすれば一歩でも前に進めるか」という視点であり、野村さんがおっしゃるように「事象ではなくアクションに注目」しなくてはいけないのだと再認識しました。

また、「平常時に話し合うことの重要性」については、言われてみれば当たり前だと感じるものの、実際にはなかなかできないのは何故なのか？を考えさせられました。 “止まること” を恐れるのではなく、“止まったときにどう動くか” を考えておくというのは生存戦略として最も重要と言えます。それは私自身が移民としてアメリカで生き抜いてきた経験からも、非常に実感のあるテーマでもありました。システムベンダーの立場で考えると、混乱の渦中では冷静な判断が難しいからこそ、日頃から「何を守りたいのか」「どこまでを許容できるのか」をお客様と共に整理しておくことが、結局は最も現実的で誠実な備えになるのだと思いました。

野村さんはシステム障害対応における日本のトップレベルの専門家です。長年の現場経験を通じて「障害対応」という領域を体系化し、それをサービスに昇華することで多くの企業が “助け合える仕組み” をつくろうとされています。その姿勢には深い敬意を抱きますし、私たち富士ソフトアメリカにとっても大きな学びとなりました。本当にありがとうございました。

私たちはこれからもお客様と同じ目線で、そして野村さんのような素晴らしいエキスパートから助言を頂きながら、「止まっても立ち上がれるシステム」「人と組織が共に強くなるIT運用」を追求していきます。

今回の対談が皆さんにとっても自社の備えを見直すきっかけになれば幸いです。

対談動画

野村社長との対談の様子は動画でもご覧いただけます。ぜひご覧ください。