ＩＴ業務に従事して40数年経ちましたが、前回のコラムで触れたバックアップリカバリーと共にもう一つ心に残っている事象があります。それは情報システムの障害（以下、システム障害）に関する取り組みです。
　システム障害が発生すると、利用者に多大な影響をもたらします。管理する情報システム部門もサービス供給責任部署として、最前線で早急な回復措置の実施、原因分析と恒久対策、対策の水平展開などを最優先で進めていく必要があります。
　つまり、情報システムの利用者と管理側の両方に多大な影響があり「百害あって一利なし」の状況となるのです。
　筆者は、ベンダー側のシステムエンジニア、エンドユーザ側の情報システム担当者・責任者、グループＩＴ子会社の経営者など、様々な立場でシステム障害に関して取り組んできましたが、大変根が深く結果は満足できる状況ではありませんでした。対応に関して心残りがある現在に至っている状況ではありますが、情報システム部門として重要なポイントについてお話しします。

　最初に、システム障害が発生した際に情報システム部門はどのような対応が必要かを整理すると表1のような内容になります。

＜表１.システム障害発生時の対応事項＞

　最優先は復旧してサービスを再開することですが、重要なポイントは初動(特に①)と事後対応(⑧)の２点と思っており、今回はその２点について考察します。

(1)初動における重要ポイント

　自社担当やＩＴベンダー担当のどの立場であれ、システム障害を検知すれば即座に組織エスカレーションを行う必要があります。最も避けるべきは、障害を検知した担当者が調査・情報収集(③)や復旧対応(⑤)を実施しようとして抱きかかえてしまい、情報が閉じられて時間が経過することです。そのような状況が生じると被害は拡大し、利用者に速やかにアナウンスができず混乱を発生させ、事態を大きくしてしまいます。従って、障害を検知すれば速やかに組織エスカレーションを行い、対応体制を強化し、被害や影響を最小限に抑える措置をとり、速やかに利用者にアナウンスして混乱を防ぐことが最も重要です。
　そのためには、障害検知後に速やかに報告される業務プロセス(統制フロー)と徹底した教育・訓練が必要です。定着を図るには、報告が即座に上がるように定期的に教育・訓練を実施して統制フローの検証と定着を図っていく必要があります。

(2)障害発生元／発生責任の分類

　システム障害発生の原因元（責任元）は次の２点です。

　1) 自社の社員（派遣社員含む）による内製化対応責任のケース
　2) 外部のＩＴベンダー責任のケース

　まず1)の内製化責任の場合ですが、発生元の状況の把握や原因の分析により、対策として仕事の流れや標準化等の制度・ルールの見直しや教育・育成を実施するなど、直接的な再発防止対応を取ることができます。
　2)の外部ＩＴベンダー責任のケースでは、該当ベンダーにおける再発防止策（再発防止責任はＩＴベンダー）の立案と実施となりますので、該当ベンダー次第となります。
　従ってＩＴベンダーに対して顛末、原因、再発防止策/恒久対策を求めて報告を受け、今後の対策を講じていくことになりますが、報告された対策が如何に有効に働くかが最大のポイントです。
　今回は、ＩＴベンダー責任で行われる再発防止策・恒久対策が有効に行われるかという点に的を絞り考察します。

(3)障害発生の原因

　恒久対策について語るうえで、システム障害の発生原因について考えたいと思います。原因は次の３つの角度から見る必要があります。

　(ア) 発生した箇所（ロジックや機能の不良、環境の設定不良など）
　(イ) 発生した事象・状況（テスト不足、仕様齟齬、確認やレビューの不足・漏れなど）
　(ウ) なぜ発生したのか？の根本の原因（スキル不足、 標準手順の徹底不足、勘違いなど）

(4)事後処理における重要な事項

　事後処理で最も重要なことは再発や類似事象の発生を防ぐ恒久対策です。
　ＩＴベンダーから報告書として恒久対策を提示されますが、筆者の経験上で印象的なのは、根本原因に触れずに障害を発生させた事象・状況が原因として書かれていることです。(例：テスト不足・漏れ、確認不足・漏れなど)
　さらに対策についても、レビューの徹底、テストの徹底、チェックの二重化、標準化手順の見直しと履行の徹底、教育の徹底実施などの提示が多いです。（筆者はこれらを５点セットと呼んでいました）
　重要なことは、提示された再発防止策・恒久対策が本当に機能して、障害がなくなるかどうかです。つまり、この提示された内容を受け入れる側として腹落ちすることです。
　例えばテスト不足が原因で徹底して実施するといっても、なぜテストが不足していたのかが明確でなければ、どのようにテストを徹底するのかがわかりません。重要なのはなぜテスト不足になったのかです。
　発注者側が立ち入る領域ではありませんが、ベンダーやＩＴ子会社としてサービスを提供してきた筆者の経験からすれば、「担当エンジニアの知識やスキル不足？」「手順の理解が浅い？（教育不足）」「テスト仕様書のレビューが十分でない？」「テスト仕様の見立てが甘かった？」など真の問題点が重要と思います。
　更に発生状況として最も注視すべきケースはデグレードです。つまり機能変更した際に今まで正常だった機能で不具合が生じるケースです。デグレードを防ぐためのテストの網羅性が焦点となります。
　ＩＴベンダーとは契約の関係であるため、先に述べた根本原因には関われずＩＴベンダー次第となりますが、少なくとも報告書で提示された再発防止策・恒久対策について「その有効性」や「対策の検証がなされたか？」について確認して腹落ちしていくことが最も大事です。

(5)恒久対策の総括

　長年の経験を総括すると最も重要なのは確認・テスト・検証に尽きると思います。プログラミングを例に挙げると、プログラムの仕様の妥当性、テスト仕様書とテストデータの妥当性、プログラムの動作、システム全体の動作について如何に漏れなく、適切にテスト・検証を実施するかです。
　この数年ＡＩがサポートしたテスト自動化のソリューションが登場しており、テストの効率化には効果があると考えているものの、実際の利用シーンを想定したテスト仕様やテストデータの妥当性、結果の最終確認などの人が行う要素については、きちんと人手の検証を実施する必要があると考えています。

　今回は、システム障害の初動と恒久対策に焦点を充てて考察しましたが、少しでも参考になれば幸いです。

※番外編

　冒頭でシステム障害は「百害あって一利なし」と述べましたが、振り返ると一つだけプラスの要素がありました。それは、育成に寄与したことです。障害発生により、初動の重要性を認識し、現場部門の影響を理解したことで業務面での知見となり、回復作業においては様々な技術を取得することができました。今日の自分があるのは様々な障害対応を体験し学んできたことが大きいと感じています。