不満の中から事実を見極める

 不満を聞いている間に、事実を見極めることも重要だ。「ユーザーの発言の中には、何に一番困っているのか、ITエンジニアがまず何に対処すべきかということが隠れている」と、コンサルティング会社のFさんは話す。

 Fさんによると、不満を聞くポイントは2つある。1つは、不満の内容の中で、意見や感情と混在している事実を切り分けること。2つ目は、事実の中からITエンジニアが取り組むべき課題を見極めることだ。

 次の図の「強制終了が原因で他のファイルが消去されてしまった」トラブル例を見てほしい。ユーザーからのクレームは様々だが、「拡張子を間違えただけで強制終了するのはおかしい」「時間を返してほしい」というのは、あくまでユーザーの意見や感情だ。それにとらわれず「ファイル名を誤って指定したら、プログラムが強制終了した」という事実に着目するのである。

不満を聞いている間に実施しておきたい事実の見極め
[画像のクリックで拡大表示]

 とはいえ、事実確認の結果、トラブルの原因がプログラムにあることが分かったとしても、「ただのバグですね」と軽い感じで受け流すのは避けよう。「ITエンジニアにはたいしたことがないトラブルと思えても、ユーザーには深刻であるケースが少なくない。事実に対する深刻度まで含めて確認すべきだ」と、大手IT企業で統括部長を務めるIさんは指摘する。

 例えば、顧客サービスのシステムで「顧客に同じメールが2通送られる」といったトラブルが、プログラムのバグによるものだったとする。ITエンジニアは「プログラムを直せばすぐに解決できる」と考えて、重要度の低い問題と思いがちだ。しかし「ユーザーは顧客の信頼を失いかねない深刻な問題と重く受け止めていることが多い」とIさんは警告する。常にユーザーの立場でトラブルの深刻さを把握できるようにしたい。

ユーザー側の非を責めてはいけない

 トラブルの原因が、ユーザー側に一部あるときも、事実の伝え方に配慮しよう。「こちらにも非がありました」と謝りつつ、ユーザー側の問題を伝えるようにすると、ユーザーも納得しやすい。

 「仕様通りに開発したシステムを稼働させたところ、想定以上の負荷がかかって性能が低下してしまった」というケースで、そもそもユーザーの要求仕様の策定が甘かったという原因を、中堅SIerのE社長は次のようにして伝えるという。

 まず「仕様によると、負荷はこの数値の範囲であったので、その通りに開発しました」と、事実を伝える。同時に「ただ万一に備えて、私どもで負荷の数値がこの範囲を上回る可能性があるかどうかを確認しておくべきでした。確認せずにこういう状況になってしまい申し訳ございませんでした」と謝るのだ。こうすれば、「ユーザーから指摘される前に、先手を打って謝っているので、ユーザーの不満が和らぎやすい」とE社長は説明する。

出典:日経SYSTEMS、2008年7月号 pp.48-55 「トラブルを最小限にする 謝る技術」を改題し本文を再編集
記事は執筆時の情報に基づいており、現在では異なる場合があります。