ふと、過去に1度、ユーザーへわび状を提出したことを思い出しました。
複数システムを統合するプロジェクトのテスト中に曖昧な仕様になっているインターフェースが
見つかり、仕様を決めていない責任はこちらであり、ユーザーと他ベンダーに迷惑をかけたことと、
今後の対応を記したわび状の提出を要求されたことがあります。
今後のプロジェクトを円滑に進ためには必要なことだと頭ではわかっていたのですが、すべてが
こちらの落ち度ではないこともわかっている状況だったため提出することをためらったのですが、
結局わび状を提出しました。最終納期に遅れることなくプロジェクトは終了したが、思い返すと
けっこう危ないことをしたと考えます。
もしプロジェクトが終わらなかった場合、わび状を証拠として責任をとらされる可能性があったかも
しれないのです。
実際の裁判でわび状が証拠として使われたことがあると聞いたことがあります。
そうなってくると、相手との関係維持のため相手に都合の良い言葉を並べてしまったり、
相手から形だけでもいいから一筆書いてほしいと頼まれて、責任を感じていないのに提出するのは
危ないと考えます。
わび状を書く状況になった場合、まず、おわびをすべき事実を正しく捉えることが必要だと考えます。
ユーザーの怒りが大きい場合、とにかく何でもかんでも自分たちが悪いと、自身の体制や技術などを
否定する内容になりそうになります。が、実際に謝罪すべきは数点のはずです。
「管理の不行き届き」「技術不足」「作業品質の低さ」という言葉を並べがちになりますが、
これだと自分自身を全否定してしまい、謝罪の範囲が広くなり、会社への不信にもつながってしまいます。
事実を分析・深堀し、問題点をハッキリさせることで謝罪範囲を絞ることができます。
そして、問題点がハッキリすれば提示する対応策も具体的にできます。誰が何をすればいいのか
見えてきます。
謝罪する点と対策は、書き過ぎもだめだと考えますが、不足していてもだめだと考えます。
抜け漏れのある謝罪や対策は、かえって不信感を募らせるだけなので。
謝り過ぎず、やり過ぎず、しかし、今後の見通しだけはハッキリさせてユーザーの合意をとることが
大事ではないかと考えます。
入会申込
ログイン
