障害が起きたときに誰が謝るのかという問題（社内サービス編）

今は社内の開発者向けにサービス開発をしていて、まぁまぁの人数に使ってもらっている。で、サービスはまだまだ発展途上なので、リリースしてからもたまにシステムメンテナンスなどを行うことがある。まぁそんな感じでちょいちょい本番系をイジることがあるわけだけど、今日はそのメンテナンスをきっかけに障害が発生した。

ここで問題なのは障害が発生したことではなくて（もちろん障害それ自体は問題なのだけど）、障害をどうハンドリングするかっていうこと。ここで言うハンドリングというのは、

1. 障害を調査し、解決すること
2. 障害を拡大させないために作業を指示すること
3. 障害の内容を利用者に説明すること

通常、これらをすべてうまくこなせるのは障害を起こした本人だったりする（もちろんそれなりに技術や知識があることを必要とする）。であるならば、障害を起こした人はどの作業に専念すべきだろうか？これは当然#1である。次に#2で、#3。ということで、対応の優先度は上から順番に行うべき。

とはいえ、実際のところ、それなりにいるユーザーたちからは苦情が上がってくるわけで、障害内容を説明しなければならない。で、この説明を考えるのはそれなりに難しい。もちろん嘘をつくのはダメだけど、とはいえ、どこまで内容を詳らかにするか。そして、正確に問題を説明できるのも障害を起こした本人。そして、なぜ#2を行わなければならないのかを説明できるのも障害を起こした本人。

こんな感じであらゆることが障害を起こした本人にのしかかってくる。ここでようやく本題に入るわけなんだけど、一番やりたくない（というか、やる必要性が無い）し、面倒なのは、問題を説明し謝ることじゃないかなと思う。それに、当事者が謝るべきという考え方だと失敗を責める文化ができてしまって挑戦的な試みができなくなる組織になる。

で、じゃあ他に誰が謝るのかということになる。謝るためには事態を正確に把握し、理解する必要があるけど、実際には無理。解決しようとする人を捕まえて、理解できるまで逐一説明させるとか自己満足でしかない。なので、（良い意味で）ごまかしが出来るセンスが必要になる。自分にはそういった感じのセンスがあるかなと思ってたけど、結局最後には障害を起こした本人に謝らせることになってしまった。まぁそれは本人が自主的にそうしたから、そうなったんだけど最後までちゃんと謝ることができなくて、ふがいないなーと思ったっていう、ただそれだけのために1000文字ぐらいをここに書いた。