相手を怒らせない説明

みなさんは日頃、誰かに怒られることがありますか？

私は怒られない仕事を日頃から心掛けていますし、実際「怒られない仕事ぶりだよね？」と慎重に確認しながら進めるので、あまり怒られたことがありません。まだまだ未熟だった若年層の頃に少々あったくらいでしょうか。

だからといって、日々褒められているわけでもありませんが。

ですが、相手が怒っているビジネスシーンに駆り出され、防壁扱いされることはよくあります。

そもそも不完全な存在の「人間」がすることですから、失敗やミスは誰にでもあるでしょう。問題が大きくなることだってあるかもしれません。しかし、それだけで必ずしも相手は怒るというわけではありません。怒るのもエネルギーがいります。それでも怒るのは、怒るだけの理由をこちら側が与えてしまっているからです（ハラスメント上司等はここでは除外します）。

問題が発生した際、相手を怒らせるパターンのほぼ大半を占めるのは「結論後回し型」です。これは、大事なことを後回しにして、何を言いたいのか分からない言動を指します。

意図が読めなければ読めないほど、相手はこちらが逃げ腰になっているように見えてしまい、より相手の怒りゲージが上昇するのです。

　「『話は長くないし、要点もきちんと説明しているつもりだ』
　　と、主観でしか見ようとせず、他人事のように扱わない方がいい」

私は常に周囲にそう言って聞かせてきました。

どんなつもりであっても、受け手にそう聞こえていなければ、受け手から見る事実は異なるからです。実際、ベテランのエンジニアやマネージャーであっても、このパターンに陥る人が意外に多いような気がします。

短く要点をわかりやすく説明しているつもりでも、相手にとってはそれが長いと感じることがあり、常に相手ベースで評価が始まることを忘れてはなりません。そして、こうしたことに陥る最大の理由は、相手の知りたいことを後回しにして説明しているからです。

謝罪で相手をさらに怒らせる

身近な例を挙げれば、報道番組などでよく見る謝罪会見があります。

不祥事や問題があると、経営者や責任者らは懸命に説明するも、聞いている側、見ている側としてどうもイライラすることがあったりしませんか？

もしも、個人情報の漏洩などで自分の情報も漏洩したかもしれない！？と言ったケースと仮定すると、テレビの向こうで謝っているのに、むしろ当初よりも怒りが増すと言う人が大半と言う話を聞いたことがあります。

その理由は、話し手の説明（釈明）の内容と、聞き手の知りたい内容の間でミスマッチが起きていることを話し手側の人たちが理解していないからです。

「自分(聞き手)にとって不利益なことは何か、この先どうなるのか。
　聞き手はそれが知りたいのに、責任逃れとも取れる発言を繰り返す」

わけです。そして「これでは相手を怒らせても仕方がない」と言い切られても仕方ありません。

同じようなことが、ＩＴの事故現場でもよく起こります。
（たまたまそういうシーンに立ち会うことが多いだけかもしれませんが）

たとえば、システム障害や進捗遅れが発生したときの説明です。

　「自分たちのリスクを、相手のリスクよりも優先して説明すると、
　　たとえ説明が短くても相手はだらだら話していると感じる。
　　そうして結論は何なんだと怒りだすことが少なくない」

と言うことになるわけです。

少なくとも、トラブルプロジェクトなどに関わり、私がその解決にあたった際、品質保証の立場、あるいは第三者検証の立場として、プロジェクトチームの替わりに謝ると言うことはまずしません。会社を代表して説明に伺ったとしても、絶対に無条件に謝ると言うことはないでしょう。

なぜなら、私が赴くときは100%まだ未解決な状態だからです。

謝っても解決は絶対しないし、
たった５文字「すいません」と謝ってる間も着々と問題は悪化している。
ゆえに、謝ってる時間があれば１分１秒でも早く解決させていただくべき

で、ユーザーから見れば、問題の解決以上に優先度の高い謝罪など存在しません。全てが解決した後に、「この度は弊社がご迷惑をおかけしました」と括ることはあります。しかし、問題が解決する前から謝ると言うのは、相手から見ると

　「謝ったら許さなくてはならないのか？」
　「謝ったら解決するのか？」

と言う潜在的な怒りが滲んでくるだけで、火に油を注ぐこととなります。
ですから、問題解決の渦中に突撃する際、謝るシナリオと言うのは用意しないのです。

もっと言えば、「この度は弊社がご迷惑をおかけしました」と括ることもそうそうありません。そんな中身のない言葉を並べるくらいなら

　「次からはこうした手順と仕組みによって再発を確実に防ぎます」

と粋に締め括りたいところです（まぁ実際には次も仕事をいただけるかわかりませんし、その際に開発メンバーたちは問題を起こさないと言い切れもしないのですが）。

問題発生時に何から説明するか

最も重要なのは

　相手の知りたいことの優先順位を汲み取り、その順番で説明する

ということです。

私なら、「影響の大きさ」「復旧の見通し」「復旧に必要となる条件」を説明するでしょうか。「復旧に必要となる条件」は、ユーザーにも協力いただく最低条件です。たとえば、ユーザー資産を操作しなければならないケースでは、「その際、どなたか１名立ち会っていただけますでしょうか」と言った話をします。

もしもその時「なぜそんな手続きの必要があるんだ？」と言われたら、「発生の原因」や「復旧手順」の詳細等を説明し、ご理解いただくようにします。

何一つ解決できていない状況にあっては、謝罪を含め、これら以外の話を持っていくのはタブーではないでしょうか。特に私が今までやってきた現場では、システムが稼働していないがために業務が停止中になっているなど、起きている問題の影響が大きい場合は、相当怒らせることになると思います。そんななかでユーザー、中でも経営層が最も知りたいのは

・発生の原因や影響の大きさ
・復旧の見通しと手順

です。今まさに問題を起こし、かつ継続中となっているシステム開発に対し、これを解決するためのアレコレ以上に優先すべきことは他にありません。これを後回しにして責任の所在や障害の経緯を先に説明すると、相手はイライラすることになります。

よく現場では、問題が起きるまで状況がまるで把握できていない、問題が起きてからも情報の整理ができていない、その割に調査も進んでいない状態であたふたしているプロジェクトマネージャーを見かけることがあります。

ですが、ユーザーの心象が悪くなる一方なので、いざと言うときの指揮や調整をつつがなく行うためにも、日頃の状況把握は必ず行っておきましょう。

言いづらい情報から先に説明しよう

ネガティブ情報は「伝えるタイミングが難しい」と思う人も多く、最後までカードを使えない状況に追い込まれる人もいますが、私に言わせれば考え方が逆です。通常の"報連相"の「報告」と同じく、悪い報告ほど早々に提出するべきです。

新人の時に学ぶ"報連相"の「報告」では、

・報告は、事実のみとし、主観や意見は含めない。
・どうしても含める場合は最後に添える程度とする。
・期日が長い場合は「中間報告」も活用し、指示を仰げる機会を設ける。
・ただし、悪い報告は即座に行うこと。

と言うのが一般的だったかと思います。

問題が発生した時に行うべき内容と全く同じ扱いです。問題発生時のユーザーへの説明は、"報連相"の「報告」そのものですから、当然同じになっていなければなりません。

これを後回しにすればするほど相手を不快にさせて、余計な不信感を買い、無意味な怒りを誘うことになるかもしれません。あるいは、後回しにすればするほど相手をぬか喜びさせて、後で真実を知った際にショックが大きく、その反発で大激怒に至るかもしれません。安易に予測できてしまうことからも、後回しにすれば反感を買うのは、当たり前のフィードバックであると言えるでしょう。

こういった際には、私たちが一般消費者の立場に立って、購入した"少々大型の商品（たとえば車とか、家とか）"が不良品だった時のことをイメージしてみるといいかもしれません。

・店側にどう対応してもらいたいと思いますか？
・謝って済む問題ですか？
・言い訳を延々と聞きたいですか？

問題が発生して困っているユーザーの立場を「自分事」として捉えると、どう対応するのが最も良い方法なのかは自ずと見えてくるでしょう。