挑戦し続けるエンジニア組織はポストモーテムによる振り返りでピンチをチャンスに変えろ！
こんにちは！ユートニックの衛藤です。
2023年も不定期ですがユートニック内部の開発事情について投稿していきますので、どうぞお付き合いくださいませ！
さて、今回のお話は技術の話ではなく品質・文化・組織についての内容です。すでに様々な企業で実践されているポストモーテムの導入について記して行こうかと思います。
ポストモーテムとは
すでに取り組んでいる組織にとってはおなじみの言葉ですが、ポストモーテム（postmortem）で検索すると、「検視」とか「死体解剖」といった意味が出てきます。他には「事後分析」という意味もあり、この文字通り障害発生後の振り返り・再発防止の文脈で使われる言葉です。
同じような言葉で「障害報告」もありますが、似ているようで違います。
障害報告
主に障害に対する説明責任を果たす
ポストモーテム
障害の現象に焦点を当て、振り返り、再発防止策を検討する
ポストモーテムについては、Webで調べると素晴らしい記事がたくさん出てきますので、細かいところは割愛します。以下のGoogleの記事にもまとめられており、テンプレートも用意されているため、参考にしてみてください。なお、今回は触れておりませんが、このリンク内で言及されているプレモーテムも失敗リスクの高いプロジェクト等では効果を発揮しそうです。
本記事ではユートニックの障害に対する向き合いと取り組み方を紹介出来ればと思います。
障害についての向き合い方
障害が出ることは仕方のないことですし、そもそも障害の発生しないシステムを作るということは不可能です。
大事なのは障害・不具合に対してどう向き合うか。特にスタートアップは開発・リリースの速度がめちゃくちゃ早く、フットワーク軽く常にフルアクセルでガンガン飛ばして行けるところもスタートアップの魅力ではありつつも、その分障害や不具合も出やすくなってしまうのが事実です。
もちろん障害が発生した際には、いち早く事態を収拾出来るよう最優先で動きます。
そして、ここから先の考え方がチーム・組織の明暗を分けることになると思っています。それは発生した障害・失敗から何を学び・そして同じような過ちを発生させないためにどうするか、これをチームで話し合い成長していくことが重要です。
どんどん失敗しても良い。ただし、失敗から必ず学ぶこと。
挑戦し続ける人・組織に失敗はつきものです。むしろ、失敗が多いほど経験値も溜まり、大きく成長します。勉強や練習ももちろん大事です。しかし、失敗からの学びは比べ物にならないほど大きく、確実に自分や組織の成長の糧になります。
ユートニックの組織はまだ小さいですが、組織文化を作るのも今のうちだと思っています。大きい組織になってからメスを入れるのではなく、小さいうちに良い文化を作ってしまえ、ということですね。
たくさん挑戦し、たくさん失敗する、そして大きく学んで成長するような組織文化を醸成したいと考えています。
ただし、ここで重要なのは、必ず「失敗から学ぶ」のが大前提です。そもそも何も学ばずに同じ過ちを何度も繰り返してしまうのはまた違う話です。
そこで取り入れたのがポストモーテムを実施するということです。
ポストモーテムの実施
ユートニックの開発チームでは、1週間Sprintでのスクラム開発をしています。そして1週間の終わりのレトロスペクティブでその週に発生した障害や失敗についてポストモーテムの会を実施するようにしています。
内容は至ってシンプルなポストモーテムで、ルールもほとんど一般的なものに則り以下のようにしています。
ドキュメントはしっかり残し、社内でオープンにする
謝罪、言い訳、責任追及が並ぶ意味のない文書にしない
アクション事項は責任を持ってチームでやり遂げる
現象に焦点をあてる
ピンチはチャンス
ドキュメントについてはドキュメントツールを使って全社開放しますが、対応状況がひと目で分かるよう、終わったものは ✅ を付けることで、責任を持って完了までもっていけるようにします。
最後のルールは独自のもので、私が一番大事にしていることです。一番大事なので後述で細かく記載します。
ピンチはチャンス
一番大事にしていることは「ピンチはチャンスに変えられる」と思って取り組むこと。ひとたび障害が発生すると、個人にとってもチームにとっても暗い雰囲気にもなり、とても悔しく、落ち込んでしまうことも多々あります。
ただ、その「悔しい思い」も重要で、その気持ちが障害などの失敗をプラスに変える原動力にもなると思っています。
単純に「障害を元の状態に戻すこと」だけを考えるのか「障害を絶対にプラスに変えてやる」と思って取り組むだけでも違いは出てきます。
例えばこんな経験はないでしょうか？
障害の復旧のために頑張って作業を進める中で、不具合部分に非効率な処理があることが発覚。最優先の障害対応の後、該当部分をリファクタしたら思いのほか処理が軽くなり、結果的にアプリの使い勝手が良くなった
ヒューマンミスを無くすための仕組みを作ったら、ミスが無くなるどころか時間を食っていた非エンジニアのオペレーションがなくなり、全体的にコストが下がった
これが「ピンチがチャンスに変わった状態」ということです。障害が発生し、暗い気持ちになっているところに、突如差し込む眩いばかりの光・・・！
気持ち的に明るくなれるとともに、サービスや組織にとても良い効果をもたらすこともあるのです。そして、それは失敗を超えて評価されるべきことでもあり、対応した暁にはエンジニア・組織が大きく飛躍成長するきっかけになります。さらに、このプラスの部分を数値として示せることが出来れば満点以上の結果が示せるのではないでしょうか。
ユートニックのポストモーテムの会では、必ず一番最後に「この失敗から学んだことにより出せたプラスの価値」をチーム全員で考えて締めくくることにしています。どれだけピンチをチャンスに変えられたのか、どんな価値を組織にもたらすことが出来たのか、どんな小さなことでも良いので必ず出して終わります。失敗のネガティブな雰囲気の振り返り会を最後の最後にポジティブな考え方に変えることで、少しでも前向きになって締められればという思いからこのような取り組みをしています。
なお、今回は障害に焦点を当てていましたが、障害となり得る前の状態（いわゆるヒヤリハット）にも効果的です。ポストモーテムドキュメントは多いほど良いので、チームが主体となりガンガン改善を回していくことが重要です。
最後に
失敗は悪いことばかりではなく、むしろそれをバネに大きく飛躍することさえ可能です。もしまだ組織でポストモーテムをやっていないところがあれば、取り入れてみてはいかがでしょうか。
合言葉は「ピンチはチャンス！」です。
最後まで読んでいただきありがとうございました！
この記事が気に入ったらサポートをしてみませんか？