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

 ITエンジニアがユーザーに対して事実を確認しながら謝っても、まだユーザーの不満は解消されてはいない。トラブルの原因究明が途中だったり、解決策が提示されていなかったりしているからだ。そこで、ユーザーの不満を解消するためにも、「状況・解決策を示す」ことが重要だ。

 ITエンジニアがこの段階で犯しやすいミスは、「まだ原因を特定できていない」「この方法で解決できるかどうか自信がない」という理由で、原因究明の進捗状況や解決策の提示を遅らせてしまうことだ。

 ユーザー企業向けのヘルプデスク業務を担当した経験を持つJさんは「完全な対応を求めすぎて状況の報告や解決策の提示が遅れると、何とかしてほしいと思っているユーザーは不満を募らせる」と指摘する。

 状況を報告する上で気をつけたいのは、原因究明や復旧までの期間がどれくらいかを伝えることだ。それをちゃんと伝えないと、ユーザーは「保身のために隠しているのではないか」と疑ってしまう。分からない場合は推測でも構わないので、数日かかるのか、1週間以上かかるのかといったことをユーザーに伝えるようにしよう。

 原因や解決策の検討で、進展があったときだけユーザーに報告しようと考えるのも禁物だ。頻繁に報告しないとユーザーは「ほったらかしにされているのではないか」と不安になってしまう。「昨日と状況が変わらなくても日々忘れずに報告すること」と、中堅SIerのE社長はアドバイスする。

恒久対策と併せて暫定策を示す

 ITエンジニアは、トラブルを完全に解決して2度と発生しないようにする恒久的な対策を提案しがちだ。だが、本格的な恒久対策を施すには、1週間や1カ月といった長い期間がかかる場合も少なくない。その間、システムを利用できない状況が続いたら、ユーザーには大打撃となる。

 そこで、ユーザーには根本原因に対する恒久対策だけでなく、恒久対策を講じるまでの暫定対策を示すとよい。恒久対策だけだと「すぐシステムを使えるようにしてほしいと思っているユーザーの不満はさらに増す」と、大手IT企業などでシステム開発プロジェクトの火消しを担当してきたKさんは指摘する。

 ユーザーに暫定対策を示すときには、トラブルの影響度をあらかじめ確認しておくとよい。ユーザー企業向けのシステム運用サービスに携わる、メーカー系システム子会社のLさんは、障害などのトラブルが発生したとき、欠かさず障害の影響度を確認している。