弊社メールマガジンで配信した「コンサルタントのつぶやき」です。
IT利活用のトレンドやお役立ち情報をメールマガジンでお届けしています。
ITシステムの開発や運用においては、しばしば大きな問題が発生することがあります。
最たるものはバグや作業ミスによるシステム障害です。
みなさんも関わったことがあるのではないでしょうか。
システム障害時については、以前、その際の行動原則をコラムにまとめました。
さて、今回はシステム障害復旧後のお話です。
ホッとして、「喉元過ぎれば熱さを忘れる」になってはいないでしょうか。
鉄は熱いうちに打て。すぐに「ふりかえり」を行い、同じ問題を繰り返さぬように対策を検討しましょう。
■１．最初に宣言する
ふりかえりはシステム障害に関わる関係者が集まって調査、原因分析、対策検討を行います。
ここで大切なのは、
・責任追及の場ではない／謝罪は不要
・二度目を防ぐことが目的
ということです。
まずはこれを宣言しましょう。
調査は事象を正確に把握することから始まります。
問題を起こした当事者が、萎縮せず、流されず、誤魔化さず、正直に発言できる場を作りましょう。
また、追及する側・追及される側に分かれることは活発な議論を妨げます。
より良い対策を導き出し、同じ過ちを繰り返さないようにすることが目的です。
それに向けて、参加者全員がフラットな立場で前向きに議論できる場を作りましょう。
■２．起こった事象を正確に把握する
いきなり根本原因や対策を論じ始める場合も見受けられますが、ちょっと待ってください。
まずは起こった事象を時系列に整理し、正確に把握しましょう。
これが出来ていないと、肝心のスタート地点を見誤り、議論が明後日の方向に進みかねません。
それが出来たら、問題が発生した直接原因を見極めましょう。
・プログラムのバグであれば、「プログラムの設計の問題点」
・本番環境へのリリース作業の失敗であれば、「作業手順の問題点」
などです。
■３．２つの視点で原因分析する
直接原因となる問題点が分かったら、その根本原因を深堀します。
深堀にはなぜなぜ分析を用いるとよいでしょう。
なぜなぜ分析についてはこちらをご参照ください。
また、問題が起こった過程は、
「問題の混入」⇒「問題の見過ごし」⇒「問題の顕在化（システム障害発生など）」
となりますから、以下の２つの視点で根本原因を探ると良いでしょう。
（１）問題が混入した原因
問題が混入した根本原因を深堀します。
「プログラムの設計」に問題があったのなら、なぜその問題を埋め込んだかです。
例：
「プログラムの設計が誤っていた」
↓なぜ？
「設計がルール通り行われていなかった」
↓なぜ？
「設計者がルールを知らなかった」
↓なぜ？
「設計者へのルールの説明が徹底されていなかった」（根本原因）
（２）問題を見過ごした原因
問題を見過ごした根本原因を深堀します。
「プログラムの設計」に問題があったのなら、なぜその問題を発見できなかったかです。
例：
「設計レビューで誤りを見過ごした」
↓なぜ？
「レビュアが気が付かなかった」
↓なぜ？
「レビュアが経験則でレビューを行っていた」
↓なぜ？
「設計レビューの基準(チェックリスト等)が無かった」（根本原因）
※ 途中で枝分かれし複数の根本原因に至る場合もあります。
■４．対策を検討し、仕組化する
根本原因が分かったら、各々の対策を検討します。
例：
(根本原因)「設計レビューが標準化されておらず、基準(チェックリスト等)が無かった」
↓
(対策)「設計レビュー用の標準チェックリストを定め、設計書とペアで必須の成果物とする」
それらの対策は、必ず行われるよう、
・業務フロー
・チェックリスト
・手順を自動化
などのルーティンに組み込みましょう。それらが無ければ作りましょう。
■５．終わりに
ここまでやれば完璧！ではありません。
対策は頭で考えたものですから、形骸化し効果の無いものになってしまう可能性もあるからです。
施行後に折を見て、対策が期待した効果を発揮しているか評価しましょう。
プロジェクトやシステム運用で発生する問題を全て未然に防ぐことは不可能に近いですが、このようにして二度目を防ぐことは可能なのです。
2024年10月14日 (月)
青山システムコンサルティング株式会社
山口 晃司
