トラブル対応の基本プロセス（４、完） 次のアクションの合意）

トラブルが一回のやりとりで解決しない場合、ユーザと何回か連絡を取ることになる。その場合に双方が意識すべきなのは、「次のアクション」である。「いつ・誰が・何を・どんな手段で・どこで」実施するかを合意する必要がある。たとえば、ユーザがデバッグ情報を採取して今週末までにベンダーに送付するとか、ベンダーがログを解析して結果を明日までに連絡するとかいうように、具体的に決める。

製品のトラブルのときは、基本的にユーザが強い立場にあるため、次のアクションをユーザの言いなりに決めてしまうことが多い。２回目に述べた「期日」と同じく、無理な約束をしてもしょうがない。約束を果たせず、迷惑をかけるだけだ。自分の現在の負荷を十分考慮し、現実的な「次のアクション」を逆提案しよう。

別のトラブルが同じユーザや別のユーザから入ってくるといった状況の変化はいつでもあり得るし、思ったより現象が複雑で、約束した期日までに解析結果が出せないこともある。こういった場合に、約束した結果が出ていないからと何も連絡しないのはよくない。とにかく一報を入れる必要がある。もし少しでも解析が進んでいるのなら、それを報告すればいいし、何もわかっていない場合でも、どういう観点で調査を進めているか、どの部分が怪しいと考えているのか（つまり仮説）を伝えれば、満足しないまでも、ある程度納得してもらえるだろう。要は、調査が先に進んでいるのを伝えることだ。

できれば、「次のアクション」を合意するとともに、「次の次のアクション」を用意しておいた方がよい。ここまで要求するユーザはあまり多くないが、たまにお目にかかる。その意図は、行き当たりばったりで計画性のない調査ではだめだということである。最初の仮説が外れたらどうするつもりなのかを考えておくことは、こういう厳しいユーザの対策としてだけでなく、自分の精神衛生上もメリットがある。仮説が外れたときは、がっくりして次のことが考えられなくなるものだ。次の一手を用意しておけば、すぐに次のステップに取りかかれる。

トラブル調査では、タイムマネジメントが非常に重要である。ひとつのトラブルにかかりっきりになって、他のトラブルをおろそかにしていると、重要でなかったものがやがて火を噴くようになる。こういったことにならないよう、自分の時間をきちんとマネジメントする必要がある。「次のアクション」を合意したら、それを達成するために、いつ何をやるべきかをあらかじめスケジュールしてしまうとよいだろ。「タイムマネジメント」で書いた佐々木かをり氏のやり方である。もちろん、いつも予定通りに事が運ぶわけではない。新たに緊急の要件が入ることは日常茶飯事。その場合は、予定を見直す。日々のタイムマネジメントが鍵だ。