「不具合」と書いて、「信頼の分岐点」と読む。～人は失敗で信頼を失うのではない。その後の対応で、信頼を失う。～

あるサービスのダッシュボードで、数値が正しく表示されない不具合が発生した。

私は状況を確認するため、運営側へ問い合わせた。そして、返信が届いた。

しかし、その内容を読んで、私は正直がっかりした。

不具合が起きたことに、ではない。
返信から、その出来事を重く受け止めている様子が伝わってこなかったからである。

まず、利用者に不便や不安を与えたことへの謝罪がない。次に、なぜ不具合が起きたのかという原因究明についての説明がない。さらに、今後どのように再発を防ぐのかという報告もない。

不具合が続いている間のアナウンスも見当たらなかった。

現在、何が起きているのか。
サービスを使い続けても問題はないのか。
いつ頃、正常な状態へ戻る見込みなのか。

利用者が知りたいのは、まさにそこだと思う。

もちろん、すぐに原因を特定できないことはある。復旧予定時刻を正確に示せない場合もあるだろう。

それでも、

「現在、原因を調査しています」
「復旧の見通しは、分かり次第お知らせします」
「次回は何時までに状況をご報告します」

と伝えることはできる。

分からないことを、分からないまま誠実に伝える。
それも、企業の重要な品質である。

私はOKI時代、品質保証の仕事を通じて、問題発生後の対応には順序があることを学んだ。

最初に行うのは、暫定処置である。

お客様への影響を最小限に抑え、被害の拡大を防ぐ。同時に、迷惑をかけた事実を認め、謝罪し、現在の状況を伝える。

システム障害であれば、代替手段を案内する。復旧まで時間がかかるなら、その見通しを知らせる。見通しが立たないなら、次に報告する時刻だけでも約束する。

暫定処置とは、単にシステムを一時的に動かすことではない。

利用者の不安を、それ以上広げないことでもある。

しかし、暫定処置だけでは品質保証とはいえない。

その次に必要なのが、原因究明である。

なぜ不具合が起きたのか。
なぜ事前に発見できなかったのか。
なぜ利用者への案内が遅れたのか。
なぜ最初の返信で、必要な説明ができなかったのか。

ここまで掘り下げて初めて、問題の全体像が見えてくる。

そして最後に、是正処置がある。

同じ問題を繰り返さないために、仕組みをどう変えるのか。監視方法を変えるのか。確認手順を追加するのか。連絡体制や判断基準を見直すのか。

原因を調べただけでは、問題は解決していない。

原因から学び、再発しにくい仕組みに変えてこそ、失敗は組織の財産になる。

私はJUKOh塾で、こんな言葉を伝えている。

「人は失敗で信頼を失うのではない。失敗を学びに変えなかったときに、信頼を失う。」

これは、人だけでなく、企業にも当てはまる。

どれほど優れたサービスでも、不具合を完全にゼロにすることは難しい。人がつくり、人が運営している以上、想定外のことは起こる。

だから私は、不具合が起きたという一点だけで、その企業を評価したくはない。

私が見ているのは、その後である。

すぐに事実を知らせたか。
利用者へ率直に謝罪したか。
分かっていることと、分かっていないことを区別して伝えたか。
原因を究明し、再発防止策を示したか。
そして、最後まで利用者へ報告したか。

この一連の姿勢に、その企業の本当の品質が表れる。

今回、私が返信に感じた失望は、厳しすぎる評価なのかもしれない。

しかし、私は批判したいわけではない。

むしろ、ここを信頼回復の出発点にしてほしいと思っている。

まず謝罪する。
現状を知らせる。
原因を調べる。
再発防止策を講じる。
そして、結果を利用者へ報告する。

当たり前に見えることを、問題が起きたときに確実に行う。それが難しいからこそ、組織の文化と日頃の準備が問われる。

不具合は、企業にとって痛手である。

しかし同時に、自分たちが利用者とどう向き合っているのかを示す機会でもある。

対応を誤れば、不具合は信頼を失う出来事になる。
誠実に向き合えば、不具合は信頼を深める契機にもなり得る。

「不具合」と書いて、「信頼の分岐点」と読む。

失敗したかどうかではない。
その失敗を、次の品質へつなげられるか。

利用者は、そこを見ている。