我々のシニアテクニカルコンサルタントの経験

私が思いだす故障は民間の銀行でシニアテクニカルリーダーとして従事していたCBS プロジェクトです。 1カ月程前に銀行が設立したばかりで、その後もサポートを行っていました。 設立して1日が過ぎた頃、定期預金の移動で問題が浮上しました。 発見後、銀行は問題解決のスクリプトを渡されました。 私どものチームは銀行に正しいスクリプトを特定の日時で実行するように送りました。 しかし1月24日、銀行はなぜかシステムが生きている状態で、スクリプトの実行を逃しました。

これがわかった時この間違いから引き起こるだろう結果を認識し、チームを招集して問題を説明しました。作られたスクリプトは日付が変わったため、次の日に適応するものではなかったからです。 私は二つの方策を提案し、チームに直ちに取りかかるよう指示しました。 可能な方策とは：

1) 結果を特定し、銀行にリストを送る。生きてる環境でマニュアルでアクションをとる方法。 しかし、システムの全域で結果を特定するというのは、時間のかかるプロセスでした。 しかし、その日の取引を進めたままの影響を考えるとより得策でした。

2) 問題解決するための新しいスクリプトを作る そのようなスクリプトを作成するのは大変手の込んだ作業ですが、問題解決が迅速にできます。しかし、日中の取引に影響を与えてしまうリスクがありました。

私は銀行に間違いとその結果から引き起こるだろう結果を伝えました。 緊急事態だと把握していたので、銀行はどの方法で問題解決をするか決定する会議に出席するように言ってきました。 会議が始まるまで、二つ目のアプローチとしてのスクリプトを用意しました。 会議でどちらの方策も提案しました。 銀行は新しいスクリプトを実行するリスクを孕みたくなかったため、時間がかかるが一つ目の方策に決めました。（スクリプトが問題解決をし、迅速だと言いましたが）

テスト環境で最初のアプローチがパスされるまですでに19時を回っていました。この遅れのため、銀行のEODサポート代表が次の日に生きている環境で残りの活動を行うよう延期を提案しましたが、更なる問題を起こす可能性があるとして私は同じ日に全て終わらせるよう主張しました。彼らをサポートし、全て終わった時は23時半を回っていました。レポートを作成し、確証要求をし、0時に帰宅しました。大変骨の折れる作業でしたが、安心感がありました。次の日の銀行の預金業務責任者が私のところへ来て次の日まで待たずに解決し、更なるトラブルを回避したという決定をしたことに感謝してくださいました。次のプロジェクトのUATの間にも自分の業務以外でこの問題を解決したことで、同僚からも大変感謝されました。