システム障害の改善はなぜ進まないのか(第二部)

第一部の「そもそもシステム障害対応の改善は必要なのか?」では、
システム障害の対応が長引くことで、以下の問題が発生することがわかりました。

  • BtoC企業は、システム障害の影響によりサービスが利用できないことで、「機会損失」が発生する。
  • BtoC企業への「印象悪化」によりエンドユーザーが離れることで、さらに利益が減少する問題が発生する。
  • サービス提供元の「対応稼働」が長くなり、想定外の運用コストが発生する。
  • サービスが提供できなかった損害を補填するためにサービス提供元は、BtoC企業へ「損害賠償」を支払う金額が高くなり想定外のコストが発生する。

そのため、「システム障害発生時は迅速かつ、短時間でのサービスを復旧させ、エンドユーザへの被害を最小限に抑えるための改善が必要」との結論にいたりました。

本記事では、「システム障害対応の改善が必要と考えている」皆様へ
改善方法が進まない理由から実際にどう改善すべきかを提案しています。 

システム障害対応の改善は何故進まないのか?

では、「第一部」のように大変なことになるのになぜ改善は進まないのでしょうか。
私が考える改善が進まない仮説は3つあります。

1.システム障害をみんながすぐに忘れてしまう

ひとたびシステム障害が起きて、売上が下がった、コストがかかったりするとみんな盛り上がってこうしたほうがよい、ああしたほうがよいとなりますが、なぜ、大変だったシステム障害を忘れてしまうのでしょうか。

忘れてしまう要素①企業として稼ぐことを優先するから

前回の記事「そもそもシステム障害対応の改善は必要なのか?」の理由のひとつとして「予定外のコストを抑えるため」と記載しました。
企業としてビジネスとして、「稼ぐ方に力を注ぐのが最優先」ビジネスを立ち上げ、推進している立場としても十分に理解できます。
企業としては、商品企画部門、商品開発部門、製造部門、営業部門、店舗部門などが主に売上、利益を上げるので、優先されてしまうと思います。

ただ100%の企業の力を稼ぐ事に向けず、損失を守る事、守る力(システム障害発生前の準備や整理)にも少し力をかけておく事が、結果として企業の稼ぐ力を上げる事になると考えています。
ひとたび障害が起きた際に「対応稼働」や「損害賠償」のコストがかかったりすると、「ああしたほうがいい」「こうしたほうがいい」と対策アイデアの声はたくさん挙がります。
暫定的な対処が済んで落ち着いてくると、声を上げていた方はご自身のメインとなる業務に戻ります。
そして問題管理として管理している部門が、企業やビジネスの中の1部門としてどの程度優先度が高いか次第で忘れ去られていきます。

忘れてしまう要素②時間がないから

当たり前の事ですが事実そうだと思います。
皆さんが改善内容を口頭で伝えた経験がある方は、最初は伝えた内容で実行できていても、ある程度時間が経つと元に戻る事を経験されている方は多いかと思います。
故障対応の改善が進めるプロセス設計+システム導入が必要と思っています。
ここは深く掘り下げませんが、もし改善した結果、1日10分でも空き時間を作れる場合、皆さんはそれを改善時間に充てようと思いますか?

私は故障対応のプロダクトを企画している中での話になり恐縮ですが、
障害対応のアラート検知から人に伝わるまで今まで15分かかっていたものを、5分に変えました。
この10分を大事に考えます。
数分早める事で、少しでも影響を抑えられる可能性が高くなるかもしれない。
また10分の稼働を削減する事で、発生回数×関係者人数×月間時間、年間時間 で考えるととても大きな時間を、他の優先事項に使えるからです。
数分でも改善する事が結果として企業やビジネスの稼ぐ力に使えると考えています。
そうはいっても、時間がなく忘れてしまうかと思います。

忘れてしまう要素③どれだけ大切な事か理解していない

なぜ必要かを理解しないと人は動かないものです。
前回の記事「そもそもシステム障害対応の改善は必要なのか?」の理由の一つとして「1.エンドユーザーが困らないため」と記載しました。
システム障害の改善をした結果、エンドユーザーがどのくらい困らなくなるかの理解していただく事が大事だと思います。
誰のためにどんな効果があるのか、それをどれだけ大切にするか理解しないまま、忙しい日々の流れの中で忘れてしまうのかもしれません。

また「7つの習慣」の中で「大切な事を優先する」という考え方があります。
(1989年の初版発売以降、44カ国語に翻訳され、全世界3,000万部、日本でも累計220万部を売り上げ、ビジネスパーソンなら1度は読んでおきたい本です。)

このマトリックスを見るとわかるように、活動を決める要因は、緊急度と重要度の二つあります。
人は「重要」かつ「緊急でない」事が大事だとわかっているにも関わらず、
毎日「緊急」かつ「重要」な事で9割、そこで抱えたストレスを解消するために「緊急でない」かつ「重要でない」事を1割して一日が終わっているともいわれています。
システム改善は、マトリクス上の「予防」「計画や準備」であると考え、それは「重要」かつ「緊急でない」事に入るため、忘れてしまうのかもしれません。

2.関連システムが増えて改善が進みづらくなった

昔は、組織内部・システム内部でシステム障害対応の改善が完結する傾向にありましたが、近年は、どんどん関連システムが増えてきており、システム障害の対応を改善するために必要な関連する人、巻き込む人が増えている傾向にあります。

関連システムが増えるとなぜ、改善が進まないのでしょうか。

進みづらくなる要素①自分たちのシステムに影響がなければ、特に改善が必要とは思わない

現在は、新システムが増えると部長層やPM層以外は新規メンバーをグループ会社や協力会社から募集することが多く、メンバーに必ずしも既存システムを知るメンバーが参画するとは限りません。お隣のシステムの担当者の顔が見えなければ他人事となり、自分たちのシステムに影響がなければ改善が必要とは思わない。

進みづらくなる要素②関連システム全量を把握するメンバーがいない

関連システムが増えることでシステムが煩雑になる一方、この業界は定期的に人が入れ替わることが多いため、関連システムまでを把握した人材を育てることが難しい傾向にあります。
人が入れ替わるたびにドキュメントが増えたり、最新のドキュメントがどれかがわからなくなり、それが正しいのかもわからない状態なるため、改善するために必要な人が増えます。

有識者の口伝だけのこともしばしば…

進みづらくなる要素③改善活動するためのコストが必要

「進みづらくなる要素②」で説明したようにドキュメントがなかったり、全量を把握したメンバーがいないため、関連システムへの協力を仰ぐ必要があるがあります。
これには、関連システムの承認が必要となり、関連システムの業務状況によってはすぐに承認されないことが多いです。そのため次クオーターや次年度などに改善コストを積み組織を構築しないと始まらず後回しになることが多いです。

こういったことから、システム障害で原因になった担当者やそれに携わった人は改善活動にやる気があるが、携わらなかった人との温度感に差があり、なかなか進まないようになりました。

3.関連システムや顧客との運用設計ができてないと進まない

「2.関連システムが増えて改善が進みづらくなった」で記載した内容に関係しますが、システム障害の対応を行う際に関係システムとの調整が増えてきており、関係者などの調整先の相手が「システム障害時こう対応しよう」というのが決まっていないと、自分たちの対応方法も決まらなくなってきます。

運用設計ができていないとなぜ、改善が進まないのでしょうか。

システム障害対応を想定した顧客視点での運用設計ができてないことによって、情報の不足やアクション決定の遅さなど、改善が進まないと考えております。

  • 運用設計できていない要素①「このシステム障害時に、誰に連絡しよう?どのような手段で連絡しよう?」
  • 運用設計できていない要素②「このシステム障害時に、どんな体制構築が必要か?どんな役割の人が必要か?各役割の方はどのくらい人数が必要か?」
  • 運用設計できていない要素③「このシステム障害時に、関係者が必要としてる情報は何か?どんな項目や数字が必要か?」
  • 運用設計できていない要素④「このシステム障害時に、私達が必要としてる情報は何か?どんな項目や数字が必要か?どのように収集するか?」
  • 運用設計できていない要素⑤「このシステム障害時に、関係者との役割や業務分担はどのようにしておくか?」

今までの業務経験から、多少決まっている事はありつつも、多くはシステム障害の対応時にその場で急いで決めていると感じており、この「顧客視点の運用設計」については、「第四部」で詳しくかきたいと思います。

では、この状態の真の原因は何なのでしょうか…?第三部に続く!

引用

  • 「7つの習慣」著者:スティーブン・R・コヴィー
野村 浩司

金融系システムを中心に開発・保守・運用を6年実施、その後、事業部・社内改善を5年しており、大規模障害時は300人ほどの障害対応の統括を実施、事業部の故障数を30%削減などに取り組んだ。 他にも、原価削減はBPRで8000万/年、システム監視改善で3600万/年、申込運用改善で2500万/年など実績あり。

The following two tabs change content below.

野村 浩司

金融系システムを中心に開発・保守・運用を6年実施、その後、事業部・社内改善を5年しており、大規模障害時は300人ほどの障害対応の統括を実施、事業部の故障数を30%削減などに取り組んだ。 他にも、原価削減はBPRで8000万/年、システム監視改善で3600万/年、申込運用改善で2500万/年など実績あり。
是非フォローお願いしますm(_ _)m
NO IMAGE