ここを見に来る人には、俺の後輩が少なからずいる。ちょっと思いだしたことがあるので、タイトルについて語りたい。というのも、トラブル対応の力が、最近のエンジニアは落ちている気がするからだ。虎の巻風に書く。
１．まず謝る
ここは日本だ。責任論の前にお客のトランザクションが止まっているならば、謝る。仮にお客が１００％悪くても、謝って同じ船に乗り、トラブルの解決に向かう。費用の話は後ですること。
２．現象をタイムテーブルにまとめる
みんなが見えるところに、時系列で事実を書き、共通理解とすること。事実がぶれると見当はずれの対応をあちこちで取り始めて収束に向かわない。
３．回復手順書があるならば、まずやってみる
ヘンにトラブルの場所を、その場の勘で推測して回復処置をやらないこと。手順書を作った時は冷静な頭で時間をかけて作ったはずだ。まず、その手順を行うこと。勘で行うと、ますます傷口を広げる可能性のほうが高い。
４．パワーオンリセットから可能なら、やってみる
一見、ソフトウェアのトラブルに見えてもなんでも、電源を落とし、そこから回復処理をするということが最も回復の可能性が高い。
５．エラーメッセージを分担して調査する
ほとんどのエラーメッセージは最上位のプログラム（アプリケーション）から遡っていくことになろう。時間をもとに各コンポーネントの担当者が調査するしかない。金融機関ではそのために、トラブルが起きると全員がとにかく集合する。
６．原因がわかったら、とにかく今、治せることをする
抜本的対応は時間が絶対にかかる。代替手段で逃げられるだけ逃げ、トランザクションの続行を目指す。特異なデータゆえうまくいかないのであれば、手作業対応してでもシステムをへんにいじらない。
７．トラブルの原因報告と再発防止対応策を提出する
ここからは、ちょっと時間がかかる時の対応である。きちんとしたお客さんでは、この二点の報告書が出なければトラブル対応は終わったといわない。放置するベンダーが多いことに驚く。
お客の運用とは再発防止策の集合体だといっても過言ではないのに。
８．原因調査が長引いている時は定期的に報告
「進捗がないから報告しない」はダメ。開発元でプログラムの調査をしているならいるで、引き続き行っている、ということも立派な報告。
もし、調査時間が必要な場合はウソをつかずにどれくらい必要かを伝えること。一週間かかるところを「一週間です」というとお客は感情的に怒るかも知れない。しかし、一度怒られるだけですむ。「あと二日」「あと二日」「あと二日」と3回ウソをついてしまう結果になったら、お客の信頼を失う。
９．再発防止策が実効しているか定期的に調査
普段出入りしているお客に対して、そこまでやってこそベンダー
７、８、９の中で初めて誰の責任かの議論と、費用が発生したのであれば、その請求が行われる。
この項目を基本にトラブルの対応をすれば、取り返しのつかないことにはならないはずだ。銀行の勘定系のトラブルを切り抜けてきた私の経験則。
