クレーム対処について

はてな匿名ダイアリー

2012-02-22

■クレーム 対処について

クレームに正しく対処するためには、そのクレームに対して「正しく恐れる」ことが大切になる。

恐れかたは、少なすぎても、多すぎても、トラブルを生む。正統なクレームに「毅然とした対処」を行うことはトラブルを生むけれど、ちょっとしたクレームに対して大きすぎる反応を返すこともまた、同じぐらいに間違っている。クレームを恐れることは大切だけれど、必要な大きさだけ正しく恐れて、恐れた大きさに見合った対処を行わなくてはいけない。

不快には種類がある

同じ不快の表明であっても、それが技術者の人格や、現場の対応に対する不快なのか、あるいは技術者の技量や開発方針に対する不快なのかで、対応は異なってくる。

技術者の人格や対応に対する不快が表明された場合には、まずはその不快に対して謝意を表明しないといけない。不快に対して最小限の妥協を遅滞なく行った後、「その状況を維持します」と表明するのが正しい対処になる。不快を突っぱねれば間違いなくトラブルになるし、こうした不快に対して大きく反応しすぎると、今度は開発ができなくなってしまう。

技術者の技量や、開発方針に対する不快が表明された場合には、一切の妥協してはいけない。開発者は常に「ベストを尽くしている」ことが前提であって、ここで妥協を表明することは、開発側が「ベストを尽くしていなかった」と受け止められてしまう。開発側は常にベストを尽くしており、それに対して不快や不安が表明されたのなら、その人と交渉を続けることは間違いなくトラブルに結びつく。開発に対する不快が表明された際には、速やかに他のソリューションを当たってもらうように誘導しなくてはいけない。

進捗の説明や、開発それ自体に関する説明は、丁寧に行わなくてはいけない。進捗自体に関する説明は、それがどれだけ面倒であっても必ず有限で、丁寧に対処すればいつか終わる。際限もなく終わらない可能性にいらだってしまうと、相手を不快にしてしまう。たとえばデスマプロジェクトを5つ受け持てば、炎上の話を5回繰り返すことになるけれど、これは我慢して同じ話を丁寧に繰り返さなくてはいけない。

何らかの譲歩を求めて、「とりあえず不快を表明する」タイプの人は難しい。不満が無くても瑕疵を探索するし、瑕疵を見つければ譲歩を求める。どこに突っ込まれるのか予測できない。譲歩を求める相手に対して心がけることは、一刻も早い「妥協の表明」になる。「特別扱いしろ」という相手に対して、「特別扱いをさせていただきます」と速やかに表明してみせなくてはいけない。ごくわずかだけ下がってみせることで、相手の瑕疵追求の意志が和らぐ。下がりながら応対して、その後また元の場所に戻る。下がり続けてはいけない。追い詰められてしまう。

知らないことには「知らない」と返答する

自分の現場ではやっていない、あるいは不得意な開発について、客先担当さんやマネージャから「この開発手法はできないのですか？」と問われた場合には、「できません」と答えなくてはいけない。「それはよくない手法です」とか、「やってやれないことはありません」といった答えかたは危ない。

やっていないことに詳しい人は少ない。詳しくないことに対して、開発者が「専門家の言葉」としてあやふやな感想を述べてしまうと、言葉が一人歩きをはじめてしまう。もしも何かのトラブルに巻き込まれてしまうと、そうしたあやふやな感想が、「あの開発者はプロダクトを囲い込んで開発工数を奪った」といったトラブルの種になってしまう。

情報工学の範囲を超えた、精神論を強く希望するお客さんと話すときにも、注意すべきことは変わらない。自身がどれだけ情報工学に詳しくても、対峙する精神論がどれだけいい加減なものに見えても、知らないことに対して git push する人間があやふやな感想を述べてしまうと、将来的にトラブルを招く。「自分はそれに対してこう考える」を述べる際には、「これは個人としての感想ですが」のような前置きを入れて、技術者としての立場を明示的に遮断してから「こうだと思います」を表明しなくてはいけない。

リスクは近くで対処する

相手を怖いと感覚した人間は、相手に「恐ろしさに見合った賢明さ」を期待してしまう。それがトラブルの種を生む。

原因がよく分からないトラブルに対応した担当者は、分からないその状況を、恐ろしいと感じる。「恐ろしいから」バグレポートを上げる決断をためらって、「この問題はマジやばくなったらだれかが見つけてくれるだろう」と、自分以外の人間にある種の賢明さを期待する。結果としてシステムは、「専門家である技術者」から端末を切断されて、書かれたコードを信じて、状態が悪くなるまで通常に稼動してしまう。