はじめに
システム障害が発生した際、本来であれば原因を究明し、その原因に対して恒久対策を打つのが筋です。
しかし現場では「原因が分からないまま、恒久対策だけを先に決めてしまう」という理不尽な進め方がまかり通ることがあります。
この物語では、原因究明を後回しにしたまま恒久対策を求められたことで、現場がどのように混乱していったのかを描きます。
本記事は、エンジニアや企業を貶めることを目的としたものではありません。情報収集が困難な業界内情を提供し、今後のキャリアに役立てていただくこと、そして業界への監査を行うことを目的としています。
「原因究明してないけど恒久対策」
これは、国内大手SIer企業のA社での出来事。
とあるクラウドシステムにおいて、顧客のデータが消失するという重大障害が発生した。
再現性の低い事象で原因調査は難航し、一方で顧客への障害報告を早期に実施する必要がある。
チームには、重い緊張感が漂っていた。
今後の方針を決めるため、チーム内で打合せが開かれた。
- 課長 😤 「本件、時間をかけるわけにはいかないので、原因究明はしないけど、恒久対策は打つことにします。」
- メンバーA 😳 「え!? 原因分かってないのに恒久対策ですか?」
- 課長 😐 「そうです。まずは、顧客に説明する障害原因と恒久対策をブレストで提案して。」
メンバーたちが次々と手を挙げる。
-
メンバーB 🙂 「クラウドベンダーのサービス障害が原因で。」
-
メンバーC 🙂 「デバイスのハードウェア障害が原因で。」
-
メンバーA 😣 「いや、ベンダーから障害通知出てないですよね? ハードウェアもこの件と因果関係ないんじゃ……。」
-
課長 😐 「いや、ブレストで一旦説明案出したいだけだから、指摘しなくていいよ。」
-
メンバーA 😩 「はあ……。」
-
メンバーD 😆 「んじゃ、TCP/IPの世界をパケットが彷徨ったことが原因で。」
-
課長 😃 「それ採用で。」
-
メンバーA 😶 (TCP/IPの世界を彷徨うってなんだ……?)
まともな検証をしていない思いつきが、あっさり採用された。
その後、「有識者会議」という名目で、プロジェクト外部のメンバーを含めた恒久対策の打合せが開かれることになった。
なぜかこの会議からは、システム保守をしていてシステムの内情に詳しいメンバーAなどが外された。
- 課長 🙂 「この対策で問題ないと思いますか?」
- 有識者たち 😑 「問題ないんじゃないですか。」(原因究明してないのに聞かれても答えようないし。。。)
内情を知る人間が同席していないまま、対策の妥当性が「なんとなく」承認されていく。
そして、なぜかブレーンストーミングで出した「顧客への説明案」が、そのまま恒久対策として実施されるという結論に至った。
実施された対策は、当然ながら本質的な恒久対策になっておらず、同一の障害が再発した。
- 課長 😱 「どうしてなんだ!?」
- メンバーA 😑 「当たり前だろ……。」

解説
原因究明をしていない以上、そもそも「対策案」など出せるはずがありません。
出てくるのはあくまで思いつき、ジャストアイディアに過ぎないのです。
さらに、障害原因の検討に「ブレーンストーミング」という方針を掛けてしまったことで、各メンバーが批判的な指摘を出しづらい空気が生まれ、案の妥当性が誰にも検証されないまま進んでしまいました。
また、内情を知るメンバーを有識者会議から外してしまうという判断も、結果的に的外れな対策がそのまま通ってしまう一因になっています。
こうしたコミュニケーションのすれ違いや意思決定プロセスの不備が積み重なり、ブレストで出したジャストアイディアが恒久対策として実施され、障害の再発という結果を招いてしまいました。
おわりに
原因究明よりも「早期の説明」を優先し、検証されないアイディアが恒久対策として通ってしまう組織は、現実に存在します。
こうした意思決定プロセスの甘さは、AIの台頭により今後さらにリスクとして表面化していく可能性があります。
このような発注元・現場と関わり続けることに違和感を覚えたら、取引先を見直したり、転職やフリーランスとして独立したりして、環境を変える選択肢を検討してみるのも良いかもしれません。