« 「大人のための読書法」 | トップページ | 「業務性能」 »

2005年10月18日

トラブル対応の基本プロセス(1) ゴール設定

ソフトウェアに限らず、ビジネスにトラブルはつきもの。トラブルが起きないように手を打っていても、予想外の事態はかならず起きる。逃げていてもしょうがない。雨降って地固まるという言葉もあるように、うまく解決できれば、それまで以上の信頼を得ることも可能だ。この記事では、カスタマーサポートのマネージャの経験から、トラブル解決で守るべき基本プロセスを4回に分けて述べる。

なお、以下の記事では、トラブルを問い合わせてきた人を「ユーザ」、それを受け付ける人・部署を「サポート」と表現するが、この内容はカスタマーサポート部門に限った話ではない。システムインテグレータの現場SE(フィールドSE)や、ソフトウェアベンダーのプロフェッショナルサービスがトラブル対応する場合も、基本的に同じだ。また、技術的なプロセスを述べた部分以外は、営業やコンサルタントの仕事にも当てはまるだろう。

さて、トラブルを解決するために、現状把握力や製品知識、技術力が必要なのは当然だが、それよりも大切なことがある。それは「ゴール設定」だ。ゴールとは、そもそも「ユーザは何を達成したいのか」ということである。これを明確にしてユーザと意識を合わせておかなければ、いくら技術力があってもトラブルは収束しない。

「ユーザが達成したいこと」は、いままさにユーザが問い合わせてきているトラブルを解決することだと思うかもしれないが、それは早計だ。ユーザは、ビジネス上の要件を達成したくてその製品を使い、その過程でトラブルに遭遇して問い合わせてきている。したがって、「ユーザが達成したいこと」は、トラブルの背後に隠れている。まずそれを聞き出し、それを達成できるような解決策を提示するようにすべきだ。それができれば、単に問い合わせてきたトラブルを受動的に受け付けて解決したときに比べて、ユーザの満足度は高くなり、信頼を得られる。

別のケースもある。ユーザ自身がトラブルを解決しようといろいろ試してみて、そのあとで問い合わせてくるケースだ。製品が期待したとおりに動かないので別の操作をやってみたり、設定を試行錯誤したりし、「これが原因だろう」と推測して問い合わせてくる。問題は、その推測が当たっているかどうかだ。推測が外れている場合、そこに力をつぎ込んでも徒労に終わる。

トラブルを解決しようとして、別のトラブルに遭遇したケースも要注意だ。たとえば、別の設定を試したら新たな現象が発生してしまったケースや、再現テスト環境を作ろうとしたときに別のトラブルが発生するといったケースだ。そのトラブルに深入りすると、本来の問題が置いてけぼりにされてしまう。細かい部分をきっちりやるSEほど、その罠に陥りやすい。

したがって、トラブルの連絡を受けたら、現状を聞くとともに、「最終的に何を達成したいか」というゴールを確認する必要がある。そして、問い合わせ内容がゴールへの軌道上にあるか、それとも横道に逸れつつあるかを判断しなければならない。もし逸れているなら、いまやっていることをいったん白紙に戻して、何をすべきかを最初から考え直すといった軌道修正が必要である。木ばかりを見ていると、森の出口がわからなくなる。鳥瞰の視点を持つ必要がある。

とはいえ、現場でトラブルに忙殺されていると、なかなかそこまで頭が回らないのが現実だ。そういった場合は、同僚やリーダー、マネージャが第三者の視点でレビューすると効果的だ。そして「森を見る」ことを指導すれば、SEが成長するきっかけになる。

(続く)

|

« 「大人のための読書法」 | トップページ | 「業務性能」 »

コメント

この記事へのコメントは終了しました。