なぜに他人事？

バッチジョブに障害が発生。原因はインフラチームのケアレスミス。環境が異なることを理由にインフラ面のチェックを怠ったため、に前提条件が成立せず、昨夜リリースしたインフラ系プログラムが落ちた。それによって間接的な業務障害が発生した（ただし幸運にもそれによる影響はほぼ皆無であった）。

直接の原因は、いわゆる「チェック漏れ」であるが、チェック漏れの原因がどこにあるのか、チェック漏れをなぜ見過ごしてしまったのかが問題。インフラチームリーダは属人的な問題であると主張するが、ワタシは、誤りをの混入をチェックできないプロセスに問題があり、問題のあるプロセスを定義したチームに問題があり、ゆえに、チームリーダがその責にある思う。

そもそも、昨夜リリースしたインフラ系プログラムは、年末の業務プログラムのリリースによって引き起こされた障害に対処するためのものである。業務プログラムの動作前提条件を変更するために、本来であれば、業務プログラムとインフラプログラムを同時にリリースすべきであったところをそれを怠った。なぜ怠ったのかはその必要性を把握していなかったため。なぜ把握していなかったかというと、本来のテスト環境ではないテスト環境で試験を済ませてしまったから。なぜあるべきテスト環境でテストをしなかったかというと、『まぁ似たような環境だからいいんじゃないの？』的な勝手な解釈があったから。
試験実施のための環境は、プロジェクト実施要領に従えば、インフラグループにより指定された試験環境で実施しなければならない。そのインフラグループが試験環境を用意していない。しかし環境の準備を待っていてはリリース日を守ることができない、よって手元にある環境で試験をするしかない。論理としては誤った判断が混ざっているのだが、それでも立場の弱い業務プログラムのメンテナンスチームであれば不利な環境に甘んじるしかあるまい。また反面、環境がないことを理由にテストをサボったという側面もあるだろうが・・・

そういう経緯があるという状況でまたもや障害が発生した。お客様から見れば、それは『二重（多重）障害』にしか見えない。一度目のミスならまだ弁解の余地もあるが二度目、三度目はそうも行くまい。チームの事情や作業負荷の問題もあろう、が、それはお客様から見れば関係のないことだし、それを理由に障害の発生を肯定する理由は見つかるはずもなかろう。
実際作業の負荷も高いのであることは組織全体が認識をしているわけで、だからこそ、環境が不十分であっても誰もが文句を言わず、できるだけうまくやりくりしようと協力をするわけであるし、それ以外にでも何かできることがないかと配慮を見せている。
だから、今日の障害の対応のためのアクションプランの調査や検討を統制することについても、業務メンテナンスグループが取り仕切ったわけである。本来はインフラグループがやるべき作業であるにも関わらずである。それはお客様にご迷惑をおかけしている状況であり、そのような状況で、『これは本来誰々の作業で・・・』などといっている場合ではないからである。にも関わらず、さも『障害なのだからメンテナンスチームが仕切るのは当然』の体は何なのか？よくも、まぁ第三者面できるものだなぁと、ただただ驚くばかりである。