ITの現場にはトラブルがつきもの。時として「謝る」場面がある。しかし謝り方を間違えると、かえって火に油を注ぎかねない。4日間で、上手な謝り方をマスターしよう。

 トラブルが発生したときにITエンジニアがまず行うべきは「謝るに徹する」ことだ。謝る際、すぐに原因を説明したくなるのが人情だが、それは逆効果と考えた方がいい。「どんなに説明が理路整然としていても、謝りながら原因を説明すると、他者に責任転嫁しているように見えてしまう。原因説明は謝った後、互いに冷静になってから始めるとよい」と、プロジェクトマネジャー経験が豊富なCさんは助言する。

 今回は、相手を逆なでする駄目なパターンとともに、上手な誤り方を紹介しよう。

謝るのと同じタイミングでの原因・状況説明は逆効果
[画像のクリックで拡大表示]

 トラブルの非がITエンジニア側にあることが分かっているときは「ユーザーが不満に感じているミス」を具体的に示した上で謝る。例えば「対応が遅れた件について深くお詫びいたします」のように、具体的に何に対して謝っているかを示さないと「『誠意が感じられない』と思われ、ユーザーの不満は解消されない」と大手銀行のIT部門に所属するDさんは説明する。

ユーザーの不快感について謝る

 また、前出・Cさんは、ユーザーの不満や怒りをクールダウンさせるためにも「トラブル発生によってユーザーが抱いている不快感や不満、謝る相手の状況を踏まえて、謝るとよい」とアドバイスする。

ユーザーが不満に感じていることを踏まえて謝るに徹する
[画像のクリックで拡大表示]

 謝る相手の状況とは例えば「エンドユーザーに例外的な事務処理を依頼する必要がある」といったことだ。トラブルの原因が特定できないときやITエンジニア側に非が認められないときにも、ITエンジニア自身がユーザーの心情を察していることを伝えられるので、このアドバイスは有効だ。

 ここで注意してほしいのが「非を認めて謝ってしまうと損害賠償を請求されたり、無理な要求がユーザーから出されたりしないだろうか」と考えて、謝るのをためらってしまうことだ。システム開発プロジェクトを多く経験してきた中堅SIerのE社長は「欧米では裁判例などがあるようだが、国内ではほとんど聞いたことがない」と指摘する。

 Cさんも「謝ることと損害賠償は全く関係ない」と話す。トラブルが発生したら、まず謝ることに集中しよう。原因説明はその後だ。