システム障害が発生した場合、それが利用ユーザーに影響を及ぼす場合、ユーザーにWebサイトなり、詫状なりでお知らせすることは一般的だと思う。
※参考までに、「システム障害 お詫び」検索したらでてきたサイト
重要なお知らせ 「キャッシングサービスの内容について」および「キャッシングサービス内容のお知らせ」記載内容不備に関するお知らせとお詫び | アプラス 新生銀行グループ
こんな簡素な文書の裏には、何名かのシステムエンジニアの屍が潜んでいるように思える。少なくとも私の会社であれば、大事になっている。
これは、私の会社の文化というよりかは、金融系という業種が特別面倒なのではないかと思っているが、話を続けたい。
ここでいう大事とは、障害復旧にかかる作業（影響範囲の特定や、障害対応策）ではない。
その後の敗戦処理である。
障害がなぜ起きたのかを事細かに役職のある方々に説明し、根本的な原因を説明し、再発防止策を考案する必要がある。
そしてなにより厄介なのが、この再発防止策である。
再発防止策は障害の根本的原因に対応する形で考えるものかと思うが、この障害の根本的原因っていうのは、根本的というだけあって根が深い。
ユーザーコントロールができなくて、変更仕様が相次いだ結果、開発期間が短くなったとか、チーム作りがうまくいかなくって効率的に開発できなかったとか、各部門の連携に問題があったとか、ことマネジメントっぽい領域に入ってくると、それに対応する再発防止策っていうのは非常に難しい。
管理者側からすれば、マネジメントに問題があるといわれるよりかは、システム開発者に責任があるといったほうがもちろん楽である。
結果的に、根本的原因を隠蔽し、それよりかすこし浅い層、例えばレアケースをあげることができなかったとし、チェックシートを作って、システム開発時には毎回それを見ようみたいな、形骸化するゴミみたいな文書が作成されることになる。
もちろん、障害が起こりやすいとある業務において、障害が発生しやすいパターンというものはたしかにあるので、一概に上記対応が無駄というわけではない。
ただできれば、そういった特殊な業務は、そもそも業務設計としてなくすべきなんじゃないかと思う。
それを常に考慮してシステムが対応していく、ということが間違っている気がする。
腐った業務からは、腐ったシステムしか生まれない。
話がそれた。
こうして、障害が発生した場合、お偉い方に説明を行い、意味のない再発防止策に頭を悩ませなければいけない。
特に我が社では、お偉い方の説明のための打ち合わせみたいなのが頻繁に行われるだけあって、かなりの時間を取られるのである。
こういったことをしていると、そもそもこの障害は誰に迷惑をかけたのだろうか、損失はどれくらいあるのだろうか、と考えてしまう。
障害によって発生する大半の事象は、顧客にとってどうでもいいことのような気がする。
極一部のユーザーからは、非難されるかもしれないが、そういった非難が起こらないようにするシステム投資と、そのユーザーを切って、浮いたお金で、もっと大多数を幸せにするシステム投資とではどちらを取るべきかなんてのは明白な気がする。
ようは、０％から９０％まで対応するのは簡単だけれども、９０％から１００％にするのは途端に難しくなるっていう話と一緒だと思う。
これは、サービスを提供する側の視点であるが、完璧なシステムを作るのではなく、目的をある程度達成できるゆるいシステムが許容されるサービスっていいなって思う。
なので、自分がサービスを利用する際は、ある程度の不具合は穏やかな気持ちで受け入れたいと思う。
なので、ムラムラして自宅に帰った夜にDMMの月額アダルト動画になぜかログインできなくっても決してイライラはしない。
