前回の記事で、「問い合わせは言葉どおりに受け取ってはいけない」「表面の質問の奥には、本当の困りごとが別にある」と書いた。
実は、あの記事の裏には実体験があった。しかも、私自身の落ち度から始まった話だ。今回はその顛末を、隠さずに書いてみたい。
発端は、一件のデータ抽出依頼だった
お客様から、あるデータの抽出を依頼された。運用保守の現場では、よくある仕事だ。
私はデータを抽出し、結果をファイルにしてお渡しした。このとき、最終結果だけでなく、抽出の途中過程も含めてお渡しすることにした。
理由はふたつある。ひとつは、包み隠さず、どういう手順でこの結果に至ったのかを透明にしたかったから。もうひとつは、自分自身があとから「このとき、どういう状況で抽出したのか」をすぐに振り返れるようにしておきたかったからだ。
この方針そのものは、今でも間違っていなかったと思っている。
問題は、その中身だった。
N/Aのまま、提出してしまった
お渡ししたファイルの中に、Excelの「N/A」エラーが表示されたセルが、そのまま残っていたのだ。
最終のアウトプットに至る途中の過程で出ていたもので、結果そのものに影響はなかった。だが、エラー表示が残ったままのファイルを、お客様に提出してしまった。完全に、私の落ち度だ。
当然、お客様から質問が来た。
「なぜ、エラーになったのですか？」
仕組みの説明に、流れてしまった
私は丁寧に答えたつもりだった。N/Aがどういうときに表示されるのか、今回のデータのどの部分が、どう処理されてこうなったのか——エラーになった「仕組み」を、一生懸命に説明した。
おわかりだろうか。前回の記事で書いた「表面の質問に、言葉どおりに答えてしまう」を、私自身が、まさにやってしまっていたのだ。
「なぜエラーになったのか？」という言葉に対して、技術的な仕組みの説明で応えた。だが、説明を重ねても、問い合わせは終わらなかった。お客様はエラーの要因を、根掘り葉掘り確認してこられた。お客様が本当に知りたかったのは、仕組みではなかったのだ。
お詫びして、確かめて、見えた本当の懸念
私はまず、エラー表示のまま提出してしまったことをお詫びした。そのうえで、お客様が何を気にされているのかを、あらためて確かめた。
返ってきた言葉は、私の想像とは違っていた。
仕組みの説明をしたことを責めたいわけではない。むしろ、説明には感謝している。エラーのまま提供されたこと自体を、責めたいわけでもない。
本当の懸念は、別のところにあった。
「エラーの要因が、自分たちの業務に問題があったように受け取られるのではないか」——そして、「もし本当に業務に問題があるのなら、きちんと是正したい」。
お客様は、私を問い詰めたかったのではない。自分たちの業務が正しいのかどうかを、確かめたかったのだ。エラーの要因を根掘り葉掘り聞いてこられたのは、そういう思いからだった。
文書にして、説明して、ご理解いただいた
本当の懸念がわかれば、やるべきことは明確だった。
エラーがなぜ発生したのか。その要因は、お客様の業務に問題があったからなのか、そうではないのか。実態をきちんと文書にまとめて、ご説明した。
お客様には、ご理解いただけた。終わらないように見えた問い合わせは、そこでようやく終わった。
失敗の先で、関係が深まった
この一件で、私は自分の問い合わせ対応の未熟さを、あらためて感じた。
前回の記事であれだけ書いておきながら、いざ自分が当事者になると、質問の言葉に安易に流れてしまった。理屈で知っていることと、現場でできることの間には、距離がある。
ただ、この失敗には、思いがけない続きがあった。
この一件のあと、お客様の問い合わせの仕方が変わったのだ。ひとつの質問でも、その意図や背景——つまり本音を、きちんとちりばめて話してくださるようになった。表面の言葉の奥を、こちらが推し量る前に、お客様のほうから見せてくださるようになった。
きっかけは、ちょっとしたことだ。だが、お客様の困りごとに、できることを全力で、丁寧に対応する。その姿勢だけは崩さない——それが結局いちばん大事なのだと、再認識した出来事だった。
失敗は、できればしたくない。だが、失敗したあとの向き合い方次第で、お客様との関係はむしろ深くなる。そのことを、身をもって学んだ。
同じような現場に立つ方の、何かのヒントになれば嬉しい。記事へのご感想やご意見があれば、お問い合わせフォームからお寄せいただけると励みになる。
（このカテゴリでは、SAP運用保守の現場リアルをお届けしています。）
コメント