第２話 午前４時１０分 初動対応
システムログから、動いているところと、動いてないところを切り分けていった。病院の救命救急で体全身をチェックするように、コンピュータシステムのどこに不調があるのか、探っていった。
武藤は直感で、システムメンテナンス時に入れ替えを行ったプログラムに原因があると予想した。プログラムに変更を加えると、その部分は動くが、他の部分が正常に動かなくなることが、よくある。このため、新しい機能を追加する対応でも、運用現場では「プログラム変更＝やっかいもの」と扱われてしまう。
システムエンジニアやプログラマは変更による不具合が発生しないよう、設計書やプログラムのソースコードをレビューし、開発環境でプログラムを動かして仕様どおりに動くが確認するテストを実施している。
プログラムにはどうしてもバグ（誤り）が作り込まれてしまう。プログラムの構造は巨大な迷路や樹木、血管に似ている。色々な道順があり、幹から枝、さらにその先の枝と階層が深くなっていく。末端の細部まで、全ての細部を正しく作り、そして、全体が機能するために、各々の役割がある。全てを完璧に作りあげることは至難の業である。
武藤は仕様変更を行ったときに作り込まれてしまったバグが原因ではないかと予想した。「今日のメンテ中に、入れ替えたプログラムとその理由を教えて」と早口で指示を出しながら、他の可能性も考え続けていた。
武藤は半年前にシステム部から経営企画室へ異動していた。そのため、今回のプログラム変更案件やそのリスク情報が頭の中になかった。元部下の田畑が現在のシステム部のリーダー。緊急事態に陥り、武藤に助けを求めた。
田畑は手短に、今日実施した作業内容を武藤へ電話で説明した。５つの案件でシステム変更を行っていた。
案件① 消費増税に伴う税率変更
案件② ＩＣカード利用時の可否判定条件の変更
案件③ 不正カード利用状況の監視強化（過去トラブルの恒久対応）
案件④ 外部センターとの通信プロトコルの一部設定変更
案件⑤ 商品コードテーブルの洗い替え
ベテランエンジニアの武藤でも、案件名だけでは、さすがに原因究明ができなかった。武藤は復旧まで長時間かかってしまうことを予測をし、覚悟を決めた。「電話をスピーカーにしよう。そっちも、こっちも」
時間は午前４時１５分。残り４５分。まだ、原因特定もできていない。
