Player Unknown’s Bug: 原因不明の問題を記録すれば成長できるのか？
(engineering.ab180.co)偶然のきっかけで作ったイシューページを通じて、チームの心理的安全性を高め、情報共有を増やし、より堅牢な組織とサービスを作っていく話を共有します。
開発をしていると、原因不明の問題に遭遇することがあります。
特にWebフロントエンドは、サーバーなどの状態だけでなく、ブラウザの種類やバージョン、Chrome拡張機能など、数多くの外部要因の影響を受けます。
もし問題の原因がわからない、あるいは問題の原因が私たちにないのなら、ポストモーテムだけで堅牢な構造を作れるのか、ふと疑問に思いました（十分ではないのではないか？）。
きっかけ
原因不明のイシューを報告され、クローズするまでに9時間かかったことがありました。
イシューのデバッグに4時間を費やしてようやく、問題の原因が内部コードやインフラではなく、ユーザーのChrome拡張機能のバグによって発生していたことがわかりました。
問題の原因がどこにあるのかを把握するのも難しかったのですが、原因が外部にあると把握するまでに実に4〜5時間もかかったことに、自分自身に腹が立ちました。
Notionに「Player Unknown’s Bug(PUB)」というページを作り、怒りとともにイシュー対応で試したこと、惜しかったこと、補完するとよさそうなことなどを整理しました。
文化としての定着、そして発展
振り返りをしながら、イシューの原因、調べる中で追加でわかったこと、判断を誤ったポイントなどを話しました。チームメンバーは疑問点や改善するとよさそうな点を指摘してくれ、その内容を集めて障害対応プロセスを整備しました。
このプロセスがよかったのは、イシュー対応の過程で感じた難しさにチームメンバーが共感してくれたこと、そして新しく知ったことを共有する楽しさがあったことです。また、チェックリストを作ることで、似た状況が来たときにより素早く問題を把握できるようになりました。チームに提案し、正式な文化として採用されました。
AB180の開発組織では、基本的に「ポストモーテム」を行っています。社内ポストモーテムがResolutionとAction Items中心だとすれば、PUBの目的は、Lesson Learn、イシュー対応に対する心理的安全性の形成、そして原因不明の問題で最初に確認すべき要因を整理することです。
情報を自発的に共有する文化
チームに定着するにつれて、ほかのチームメンバーが対応したイシューも一つ二つと蓄積され始めました。
振り返りの中で知らなかった点を話し、さらに深く掘り下げる時間が、小さいながらも自発的な「知識共有セッション」のように運営され始めました。
この文化をもう少し育てるために、学んだことやわかったことを随時共有するSlackチャンネルを運営しています。今のところうまく回っています。
Lesson Learn
- 障害対応を行ったチーム全体の心理的安全性を高める必要があり、そのためにはより多くの対話が必要だ。
- そうでなければ、問題は繰り返され、組織の中に「問題 = 口にしてはいけないこと」という考えが根付く。
- 情報共有を通じて、組織の心理的安全性を作り、さらには高めることさえできる。
- そして、このような情報共有の文化は、思ったより些細なことから始められるのかもしれない。
5件のコメント
私は逆に今日、特定の外部要因が原因だと非常にはっきりしているものの、内部事情ですぐには対処できないと思い込んでただただやきもきしていた障害が、実は設定ファイルの1行を変えるだけで解決するケースだった、という事案に一日中振り回されて退勤しました。この記事を見ると本当に参考になります。
今日も一日本当にお疲れさまでした。それでも問題を解決できたとのことでよかったです。上の文章に書いていた問題も、たまに思い出すことがあります。そのときは大変でしたが、今では楽しく受け止められている気がします。
kunggomさんが今日経験したつらいことも、時間が過ぎれば楽しく思い返せるようになるのではないでしょうか。ふふ
拙い私の文章を読んでくださってありがとうございました。
実のところ、昔も今も障害対応のつらさを楽しいと思ったことはありません。
たとえば今日対応した障害も、よりによって私たちのチームでは本番サーバーへの直接アクセスが遮断されていたプロダクトで発生したため、障害を見つけて現象の把握を進めていた序盤と、どうにかサーバーアクセス権限を得られた終盤を除けば、比較的無力感を覚えざるを得ませんでした。私たちのチームがこういう対応をしてほしいと依頼しても、サーバー運用チームには向こうの事情があって拒否されたのです。そんな無力感を楽しく受け止めることはできません。
だから退勤前までポストモーテム文書を書きながら感じたのは、むしろ「腹が立つからでも次からはこんなミスはしない！」に近かった気がします。
お話を伺うと、とてもおつらかったのだろうと思います。おっしゃる通り、同じミスをしないようになりながら、少しずつ良くなっていくほかないのでしょう… うう
実のところ、その製品はかなり古いレガシー製品で、引き継ぎを受けてからまだそれほど経っておらず、受け取ってすぐに機能変更の対応が入ったため最近コードを修正したことはありましたが、今日発生した障害とはまったく関係のない部分でした。ですから、実際に問題になった箇所は私が直接書いた内容ではありませんでしたが、その製品をもっと隅々まで理解していれば、さらに早く問題を解決できたのでしょう。そこが本当に悔しいです。
そして、そもそも全面的な障害状況を確認したあと、最初に確信していた原因の推定は、実は半分しか合っていなかったのです。その推定への確信こそが、今日の本当のミスだったのではないかと思います。