だが、それはいずれも間違いだ。「まず最初に、真摯に謝る姿勢を見せないと、ユーザーは無責任だと思ってしまう」。大手銀行のシステム担当者として多くのプロジェクトに携わった経験を持つBさんは、謝らない愚かさをこう指摘する。

 非を認めて謝るメリットは多い。Bさんは「謝ると、不満や怒りを受け止めたことがユーザーに伝わり、ユーザーに冷静になってもらえる」と説明する。

 冒頭のAさんも「謝ることに抵抗感を持つ人もいるかもしれないが、上手に謝れればユーザーとより密な協力関係を築けるし、問題を解決できれば信頼も厚くなる」と話す。つまり、「謝ること」を問題解決の手段と考えるべきなのだ。

 この特集では、トラブル発生時に、ユーザー企業のシステム担当者やシステム利用者といった「ユーザー」に対して、ITエンジニアがプロジェクトチームの一員として謝る技術を紹介する。謝る技術は、「謝るに徹する」「不満を聞き事実を確認する」「状況・解決策を示す」の3ステップに分かれていることが取材を通して明らかになった。

 次回から、各ステップでのポイントや、やってはいけない謝り方を解説しよう。

トラブル発生時に謝る技術の3ステップ
[画像のクリックで拡大表示]
出典:日経SYSTEMS、2008年7月号 pp.48-55 「トラブルを最小限にする 謝る技術」を改題し本文を再編集
記事は執筆時の情報に基づいており、現在では異なる場合があります。