障害管理はこれで完璧（2/2）

はい、先日の続きです。

4.対策方法の特定

ここは「3.問題原因の特定」で特定できた原因がとても重要になってきます。特に"技術的要因"となるものが是正の必要としている個所であり、是正の必要な内容となります。

ここで求められるのは

　・最小限のコストで済む
　・品質上の問題が解決できる
　・影響範囲が小さい

という３つの条件を満たせる対策であることです。もちろん不具合の内容によってはそれが難しいこともあるでしょうが、この３つの条件を極力満たせるよう知恵を働かせる努力は求められます。ここで苦労したくないのであれば、設計時点で「シンプル」「最小化」「疎結合」な構造のモジュール群を設計しておく必要があります。

ちなみにこのタイミングではまだ修正してはなりません。

修正するのは「5.影響範囲の特定」が完了し、作業見積りを終えてスケジュールの見直しが完了した後です。発作のようにただ修正すればいいというものではありません。マネジメントの邪魔をしたくないのであればかならずスケジュールの調整が終わるまで待つようにしましょう。

そうしないエンジニアの結末が、よくある「修正中で〇日遅れです」という進捗報告フレーズとなるのです。