ＩＴエンジニアの仕事と謝罪の影響

以前のブログでわたしは、謝罪はＩＴエンジニアの仕事をする上で避けて通れない仕事だと書きました。

しかし、謝罪はしなければしないに越したことがないと思います。

今回は謝罪がＩＴエンジニアの仕事をするうえで、問題になることを３つの視点で書きたいと思います。

ひとつめは謝罪をすることで仕事をするための条件が不利になってしまうことです。

むかし某アパレル会社に販売管理システムを導入したことがありました。システムのコアな部分はSAP社のパッケージを使いましたが、帳票系はカスタムメイドが必要でした。お客様よりもともと、使っている帳票のサンプルを１０種類ほど頂き、帳票を作っていきました。帳票は上代（商品を小売業者が販売するときの価格）の実績を見るものや、下代（商品を仕入れるときの取引価格）を基準とした受払表など、一般的なものなのですが、部門単位、商品のカテゴリー単位で集計する欄を作らなかったのです。そのことをお客様に指摘された際、わたしはこのように発言しました。

確かに帳票設計の考慮が不足していましたが、お客様より頂いたサンプルに存在していない項目ですので、今後はサンプルに条件を記載をいただけるとありがたいです。

この言葉がお客様の導火線に火をつけてしまったのです。お客様は「そもそも部門や商品カテゴリーが変わる段階で小計を入れるのは、帳票として当たり前のことでしょ！素人じゃあるまいし、なにもかもいちいち言わなければ、あなたは何もできないのですか！？」

と、烈火のごとく怒ったのです。こちらは怒りをしずめようと、謝罪を繰り返したのですが、、結果としてより多くの帳票を不利な条件で提供する方向に追い込まれたのです。

冷静になって考えると、あのときのお客様の怒りは価格交渉を有利に持っていくための戦略だったのではないかと思ったのです。

ふたつめは謝罪がなかなか決着しないと、本当にやるべき仕事ができなくなるジレンマに陥ることです。

仕事の優先順位を決めるのはなかなかむつかしいのですが、下図のように仕事を分けると優先順位を決める参考になります。

謝罪はクレーム対応の一環ですので優先順位のカテゴリーＡに該当します。何もよりも優先して対応するべき仕事です。

しかし、ＩＴエンジニアが本当にやるべき仕事はカテゴリーＡではありません。そのとなり、緊急性は低いが、重要な仕事であるカテゴリーＢが、エンジニアとして本来やるべき仕事です。

システムが障害を起こしたら、謝罪し、応急措置を施すのは当たり前のことです。しかし、障害の根本原因を突き止めると、新たにやるべき仕事が出てきます。それは作業手順書の改善であったり、オペレーションの自動化であったりです。ＩＴエンジニアはあらたにやるべき仕事に一刻も早く工数を割くべきなのですが、謝罪が決着せず、長引くと、本来やるべき仕事ができなくなってくるのです。

みっつめはＩＴエンジニアの仕事をするうえで、謝罪は欠かせないにも関わらず、謝罪を体系的に学習する機会が存在しないことです。

いま、ＩＴエンジニアの仕事をする人はその登竜門とされるＩＰＡの基本情報処理試験をクリアすることが半ば必須となっています。基本情報処理試験をクリアしたら、報奨金がもらえたり、給与がアップするＩＴ会社も多いと思います。

その基本情報処理試験は細かくシラパスが公開されているのですが、ここには謝罪力をつけるために必要な技能の記述が全くありません。