orangeitems’s diary

クラウドで働くエンジニアの日々の感想です(ほぼ毎日更新)。

ファクトチェック無しに謝るな、絶対にだ

f:id:orangeitems:20190312124709j:plain

 

まず謝れというのか

驚いた。こんな記事をうのみにするITエンジニアがいたらどうするんだろう。

 

tech.nikkeibp.co.jp

トラブルが起きたとき、ITエンジニアは「安易に謝らないのが得策である」と考えがちだ。確かに、明らかに自分に非がないのに謝るのは、気が進まないかもしれない。また「謝るより先に、解決するという姿勢を見せたい」と考えるかもしれない。

 

考察

顧客がまずやってほしいのは、話を聞いてもらうことだろう。徹底的に現状について話してもらい事実(ファクト)を徹底的に整理し確認する(チェック)。ファクトチェックだ。そうしたときに、誰が悪いのかを客観的に顧客と一緒に整理する。顧客は謝ってほしいわけではなく、プロジェクトが正しく機能してほしいだけだ。正しく機能しない状況で、新手のITエンジニアがやってきて、いきなり「プロジェクトを正しい方向に戻しましょう」って言ったところで、何も知らないのに何を言ってるんだとなるのは当然ではないか。だからといって、「すいませんでした」ではなかろう。どちらも落第点だ。必要なのは、事実を洗うこと。その情報処理をやるために火消し役として呼ばれたのだろうに。

火消しの時の初期段階で大事なのは、まず顧客と目的を同一とすること。ベンダー側にも顧客側にも接点を持ち、客観的に情報を整理すること。ベンダーと顧客はプロジェクトにおいて運命共同体なのだから、一方だけの話を聞いてもいけないし、両方の立場を尊重しなければいけない。このコーディネーターが、いきなり謝ることから入る???。

謝る根拠なしに謝ると、何が起きるか。明らかに「なめられる」。この人は押せば下がる。そうしたときに火消し役になれるどころか、火消し役にすべての責任が押し付けられるだけだ。彼は謝った、非があるのを認めているのだろう、と。

タフネゴシエーター、調整役として必要なのは、繰り返すが事実を大事にすること。事実の上で非があればスピード感をもって修正する態度であり、迷惑をかけたことがわかったのならすぐに謝れる器量だと思う。謝るのはファクトの後だ。絶対にだ。

 

補足

どうもこの記事、ここから連載らしい。

 

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

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

 

なんなんだ、ステップって。「謝るに徹する」なんてステップなど、ない。

仮にステップ化するなら、私ならこうする。

「目的を共有する」

「不満を聞き事実を確認する」

「自社に非があれば、原因と対策をセットで謝る」

「顧客に非があれば、ベンダー側で最大の努力をした後で、対応を依頼する」

「情報の整理が終わった後、顧客に包括的な状況報告と解決策を提案する」

何しろ、根拠なしに謝ると、人格を軽くみられる。そこから何を始めても全部マイナスの効果しかない。「この人は筋が通っていて、誠実で、顧客のこともベンダーのことも考えてくれている」、こんな評価を得るための火消し役は、高い人格こそバリューだ。もし目的を達することができたら、大変な信頼を得られる。そのためにも、ファクトチェック無しに謝るな。絶対にだ。