たとえシステムが落ちても“社内には”謝罪するべきではない理由。あるいは”反省”と”対策”にフォーカスしようという話
こんなことを書くと怒られそうなんですが、自分の一つのポリシーとして、システムが落ちたり障害が起きたりバグが発生したことについて、基本的に“社内には”謝罪しないことにしています(もちろん例外は度々あります)。
という概念は広まるべきだなと思っていて、紹介したいと思います。
こんなこと言うと、ビジネスサイドの人からは怒られると思うんですけど。。。
前提
- 自分の勤めるJX通信社は、自社開発している企業であり、ベンチャー企業です。外注はしていません。
- 自分の立場は、エンジニアですが、固い言葉で言うと中間管理職とも言える立場でもあります(チームリーダーとかっこよく言えるほど職責を果たせているとは思えないので、そういう言い方をします)
理由１：システムは落ちるときは落ちる。バグるときはバグる
最初から諦めていて申し訳ないのですが、まず第一に、システムは落ちるときには落ちます。バグるときはバグります。システムを落ちづらくしたり、バグりづらい開発体制を敷いたりすることはできますが、100％24時間365日落ちないシステムというのは基本的にはできません。(こういうことを言ってしまうと、仕事に対するスタンスとして当然不適切なのですが)
具体的な事例を出すと、僕みたいなポンポコリンより数百倍すごいエンジニアを集めたGithubでも、落ちます。Githubは有償プランを持っていますが、それでも落ちます。AWSですら障害は起きます。
理由２：ほぼ落ちないシステムはあるかもしれない。けど、コストとスピードが見合わない
落ちないシステムを作るとしたら、たとえば次のような「品質担保」の段階が考えられるでしょう。次の例は、AWSを使っている企業が落ちないシステムを作るための話です。
- ソフトウェアが落ちても自動復旧する設計にする → 負荷が高まって、無理かもしれない
- オートスケールする設計にする → リージョン全体で障害が起きるかもしれない
- マルチリージョン構成にする → AWS自体で障害が起きるかもしれない
- ハイブリッドクラウドや、GCPなどその他のクラウドサービスを併用する
加えて、パフォーマンステストみたいなものを時間を取って行なうといった作業も必要になるでしょう。ソフトウェアまで踏み込むと、厳重なコードレビューをしたり、カバレッジ100％なテストなども必要かもしれません。
システムを他社に卸す企業ならまだしも、自社新規サービスやエンジニア数が限られていたら一層、これらはコスト的に見合うものではありません。要は、リスクマネジメント＝いわゆる「程度の問題」です。
ただ、一つ考えておかないといけないのは、「もしこの障害が起きたとき、どう対応するか？」というのは検討しておくべきなように思います。
理由３：謝罪しても何も解決しない
謝罪をすれば責任者の溜飲は下がるかもしれませんが、それ以上に何も生産しません。責任者が怒ってなければ(“怒る”責任者じゃないことを期待しますが)、なお一層無意味な振る舞いです。
代案：反省しよう！
とはいえ、十分にシステムに対してやるべきことをできているとは思いません。やるべきことがないとも思いません。日々精進、日々改善です。
そこで代案として提案したいのは、謝罪しない代わりに、障害対応報告は必ず書いて反省しましょう、です(※そこに「申し訳ございませんでした」を書く必要はない)。
弊社の場合、次のような障害対応報告テンプレートがあり、それに則って書くようにしています。これは、システム障害にかぎらず、ソフトウェアバグに関しても使うことがあります。
# 障害概要 # 発生原因 # 対応内容 # 再発防止策
自分の場合は「どういう調査をしたか」というのも書くようにしています。これは、また同じような障害が起きたとき、自分以外の人がその調査フローをなぞって切り分けできるようになるためです。
また、再発防止策は、具体的で、過剰な時間をかけずに一定の品質を担保し、直近取ることのできる策であることが特に大事なので、それを意識しています。
まとめ
- 謝罪をするのはやめよう
- 代わりに、反省をして、具体的な対策を考えよう
- 日々精進
