継続的な改善

システム障害対応の改善は続かない

システム障害対応の改善はなかなか進まないものです。
実際現場からはこのような声が聞こえてきます。

「予算がない」：そもそも保守担当の予算は少ない
「モチベーションがない」：システム障害が起きなければモチベーションがわかない
「効果がわかりづらい」：いつ起きるかわからないシステム障害の改善の効果が理解しづらい

ただ、ひとたび大規模障害が起きたり、保守運用原価削減の要請がされると最初に改善対象になります。

どうやれば改善が続くのか？

改善をするためには一般的にISO9001品質マネジメントシステムの一般企画の中でも「監視、測定、分析及び評価」が謡われております。
jqa.jp/service_list/management/service/iso9001/

「可視化・見える化が重要」と聞きまし、確かに必要なことだと思います。
ただこれは「管理者・マネージャー」にとって必要なもので、この数値をもとに「現場担当者・メンバー」に目標に達してないから改善しようね。というためのものだと思っています。

100以上のシステム障害対応に関する改善を見てきた私が思う、システム障害対応の改善が続く最大のポイントは「適した役割分担」です。

適した役割分担とは？

BPRのコンサルティングで行われる手法の１つに
組織の役割分担を責任（Responsibility）、権限（Authority）、専門性（Expertise）、実行（Work）をもとに整理をする手法があります。

うまく改善が進まない組織のほとんどが権限（Authority）と実行（Work）がばらけることによって改善が進みません。

具体的には、事業会社とシステム会社で保守運用をする際に、事業会社がアラーム対処方法を決める「権限」を持っているが、実際そのアラーム対応の「実行」をするのがシステム会社である場合です。

この場合は、システム会社はアラーム対応の内容をよりよくするために改善をしようとしても、権限が事業会社にあり、わざわざ改善提案を時間をかけてわかるように説明して許可をとってから、改善を進める必要があります。

これだとハードルが高く改善が進みません。

他にも、保守運用と開発のチームが分かれている場合、不要なアラームを「対処不要」とする「権限」は開発が持ち、不要なメッセージでも必ずエスカレーション電話をして伺う「実行」は運用が持ちます。

運用からは不要なアラームが多いのでアラームを減らしてほしい、もしくはこのメッセージは対処不要としたい、と伝えても、開発担当は苦しんでいないので対応が後回しになり改善が進みません。

権限移譲と自動化によって権限無き実行をなくすべし

事業会社とシステム会社が一緒に保守運用をしている場合

事業会社とシステム会社で保守運用をする場合は、9週目から12週目にあったような事業会社とシステム会社で事前合意をすることで権限移譲をしたり、一定の範囲内ならばシステム会社に権限を与えるなどをしましょう。

多くの場合、事業会社はすべての権限を持ちたがりすぎます無駄で、システム会社は自分たちは権限が持てないもの、すべて事業会社に伺いを立てなければいけないもの、と思ってしまっています。

権限移譲・一定範囲の権限を認めることで、システム会社自身でも「自分でやっていいんだ」というこを理解した上で独自の改善を進めてくれます。

保守運用と開発組織が分かれている場合

保守運用と開発組織が分かれている場合、かつ運用引継ぎがしっかり行われる組織でない限りは、保守運用からのエスカレーションの電話・メールなどは必ず自動化をして、開発組織が抑止条件の設定を簡易化して、不要なメッセージは設定をしっかりしないと多くのエスカレーション電話・メールが来てしまう状況を作りましょう。

ハレーションが起きるのでは？と心配される方もいらっしゃるかと思いますが、過去数チームで同じ役割変更をしましたが問題になったことは実は1度もありません。

理由は、開発担当としては、もともとの保守運用担当からクレームを受けながら対処不要の調整をするよりも、簡易に自分でメッセージを抑止をできるほうが楽になるからです。

もちろん保守運用担当も開発担当の初期のアラーム抑止設定に協力をしたり、条件提示されれば設定変更を請け負ってあげるなど、協力体制を申し出る必要はありますが、「意味がない対処不要のアラートをただエスカレーションする」という業務から解放されると、保守運用と開発の関係もよくなります。