以前のブログでわたしは、謝罪はITエンジニアの仕事をする上で避けて通れない仕事だと書きました。
しかし、謝罪はしなければしないに越したことがないと思います。
今回は謝罪がITエンジニアの仕事をするうえで、問題になることを3つの視点で書きたいと思います。
ひとつめは謝罪をすることで仕事をするための条件が不利になってしまうことです。
むかし某アパレル会社に販売管理システムを導入したことがありました。システムのコアな部分はSAP社のパッケージを使いましたが、帳票系はカスタムメイドが必要でした。お客様よりもともと、使っている帳票のサンプルを10種類ほど頂き、帳票を作っていきました。帳票は上代(商品を小売業者が販売するときの価格)の実績を見るものや、下代(商品を仕入れるときの取引価格)を基準とした受払表など、一般的なものなのですが、部門単位、商品のカテゴリー単位で集計する欄を作らなかったのです。そのことをお客様に指摘された際、わたしはこのように発言しました。
確かに帳票設計の考慮が不足していましたが、お客様より頂いたサンプルに存在していない項目ですので、今後はサンプルに条件を記載をいただけるとありがたいです。
この言葉がお客様の導火線に火をつけてしまったのです。お客様は「そもそも部門や商品カテゴリーが変わる段階で小計を入れるのは、帳票として当たり前のことでしょ!素人じゃあるまいし、なにもかもいちいち言わなければ、あなたは何もできないのですか!?」と、烈火のごとく怒ったのです。こちらは怒りをしずめようと、謝罪を繰り返したのですが、、結果としてより多くの帳票を不利な条件で提供する方向に追い込まれたのです。
冷静になって考えると、あのときのお客様の怒りは価格交渉を有利に持っていくための戦略だったのではないかと思ったのです。
ふたつめは謝罪がなかなか決着しないと、本当にやるべき仕事ができなくなるジレンマに陥ることです。
仕事の優先順位を決めるのはなかなかむつかしいのですが、下図のように仕事を分けると優先順位を決める参考になります。
謝罪はクレーム対応の一環ですので優先順位のカテゴリーAに該当します。何もよりも優先して対応するべき仕事です。
しかし、ITエンジニアが本当にやるべき仕事はカテゴリーAではありません。そのとなり、緊急性は低いが、重要な仕事であるカテゴリーBが、エンジニアとして本来やるべき仕事です。
システムが障害を起こしたら、謝罪し、応急措置を施すのは当たり前のことです。しかし、障害の根本原因を突き止めると、新たにやるべき仕事が出てきます。それは作業手順書の改善であったり、オペレーションの自動化であったりです。ITエンジニアはあらたにやるべき仕事に一刻も早く工数を割くべきなのですが、謝罪が決着せず、長引くと、本来やるべき仕事ができなくなってくるのです。
みっつめはITエンジニアの仕事をするうえで、謝罪は欠かせないにも関わらず、謝罪を体系的に学習する機会が存在しないことです。
いま、ITエンジニアの仕事をする人はその登竜門とされるIPAの基本情報処理試験をクリアすることが半ば必須となっています。基本情報処理試験をクリアしたら、報奨金がもらえたり、給与がアップするIT会社も多いと思います。
その基本情報処理試験は細かくシラパスが公開されているのですが、ここには謝罪力をつけるために必要な技能の記述が全くありません。
- 「基本情報技術者試験(レベル2)」シラバス(Ver.7.2)https://www.jitec.ipa.go.jp/1_13download/syllabus_fe_ver7_2.pdf
では、応用情報処理試験や高度情報処理試験に謝罪力の知見が必要かといえば、それも全く要求されていません。
資格試験だけではありません。大学の授業でも謝罪について体系的に学ぶカリキュラムは、ほぼ存在しないと思います。ですので謝罪は、いざその場面に直面したら、ITエンジニアは、理論的ノウハウを持たないまま、ぶっつけ本番で挑むしかないのです。
このことが前述した「謝罪により仕事をするための条件が不利になる」「謝罪が決着しないと、本当にやるべき仕事ができなくなるジレンマに陥る」ことの要因になっていると考えます。
謝罪は相手の心理にズバッと直接的な影響を与えます。そして、単に「すいません」と、謝るだけでは意味がなく、セットで解決策をシンプルに相手に提示する必要があります。すなわち、謝罪とは、心理学であると同時にロジカルシンキング(論理的思考力。筋道だった合理的な思考様式やその方法論。)の能力も必要なのです。
そう考えると、謝罪する能力は、一種の専門職なのかと思ったりします。