システムというのは基本的にはトラブルもの。正確には動いている時にはありがたみがなくて、トラブった時だけ注目を浴びるもの。
やれアジャイルだ、ウォーターフォールだと、開発手法に関してはいろいろ話題にはなるが、謝罪方法を語る人があまりいない。
だが謝罪にはメソッドがある。
経緯書の書き方
謝罪の経緯書はだいたいこういうフォーマット。
- トラブルの概要
- 時系列
- サービスに対する影響範囲
- 直近の対応
- 原因
- 根本対応
- 組織としての対応
こんな感じ。そんなもん最初からやっておけというお叱りもあるのを承知。がんばりますという対応は駄目なんだけど、がんばりますというのがないというのも良くない。
謝罪のゴールはこちらがペースを握るということ
一番つらいのは、こちらの今後のタスクを先方に切られるというのが一番つらい。経緯書の「今後の対策」は、あくまで自分達が実行可能なタスクにすべき。やりたくないけどやるというのは良くなくて、「これあった方が絶対楽だよなぁ」と自分達でも思える対策が必要。システムトラブルに対する検知ツールのチューニングとかはあった方がいい。
時系列での報告の意味
時系列でのトラブル報告は、「どうやってトラブルが発覚したのか？」「それを伝達するルートはどうなのか？」「対応できる人までたどりついたのか？」をあとで振り返るのに有効。
発覚が自社というのが一番いいが、先方からの指摘で発覚するケースもある。その場合は窓口が動き始めるまでの初動が早いとまぁいい。実際に想定外のことが起こった場合には、回復までに時間がかかるのは仕方ない。ポイントは着手までの時間がどうかということ。
サービスに対する影響範囲
サービスダウンしてましたという場合には、その影響を数で出す。私達はサービスの重要性を分かっていますという姿勢が大事。
直近の対応
その場しのぎでサービスが継続するならいい。新しいシステムのリリースでトラブった場合には旧バージョンに切り戻しというのもありえる。原因不明でサーバが高負荷の場合にはサーバー再起動で収まるかもしれない。理想的なシステム構成は後回しでも、泥臭くともサービスを継続しようとしておりますというのは、ビジネスシーンでは大事。
原因
ここに、バグの原因と、そのバグが見つからずにリリースされた経緯などを記入する。どっかのモジュールがバージョンアップしてその影響でこんなンなっちゃいましたとか。
根本対応
システムのトラブルはシステムの改修で対応する。ログが溢れましたとかお粗末なトラブルならログローテートしますとか、ログサーバーに転送しますとかそういう改修。当然ないよりは合ったほうがいい。
あと、根本対応で駄目なのは、運用ミスでダブルでチェックしますとかレビューを徹底しますとかそういうやつ。ありがちなんだど、システムのトラブルでシステムで解消しないというのは、コンピューターリテラシーなさすぎる。
さらにもう一声
対応にもう一声あるとしたら、「類似トラブルの調査」という観点。こういうミスをやらかすんだから、類似のミスをしでかしていていもおかしくないだろうということ。システム改善のためのタスクをむこう数週間くらいギチギチに入れておく。トラブルが起こる前よりもよりスマートなシステムにする。志を高くもつ。
