こんにちは。ソフトウェアエンジニアのいもりです。
研修を終えた後*1、新卒OJTの一環として欠席連絡チームに所属しています。
先日、社内で「ポストモーテムを読む会」を開催しましたので、その様子をお伝えします。
ポストモーテムを読む会とは？
「ポストモーテムを読む会」とは、過去に発生した障害を記録した文書（ポストモーテム）を第三者である私が読み、その内容をもとに当事者と意見交換を行う場です。具体的には、ポストモーテムを読んだ感想を伝えたり、ネクストアクションについて質問したり、対応を通じて得られた教訓を共有してもらいます。
今回はClassiの欠席連絡機能に関するポストモーテムを取り上げ、その内容について当事者と話し合いました。
ポストモーテムの構成と注目したポイント
ポストモーテムは以下の構成でまとめられていました：
- 概要
- 対応メンバー
- 時系列まとめ
- 振り返り
- ネクストアクション
ポストモーテムの当事者と意見交換する場において、会を自分にとってもより充実した場とするために、ポストモーテムを読む際には以下の視点を意識しました：
1. 障害対応を通じて良かったアクション
どの行動が成功につながったのか、ポジティブな側面を見つけること。
2. 「良かった」とされる点への再検証
振り返りで「良かった」と評価された点が本当に効果的だったかを考えること。
3. ネクストアクションの実行状況の確認
記載されたネクストアクションが適切に進められているかを確認すること。
4. その他、率直な感想や疑問
素朴な感想や新たに浮かんだ疑問について投げかけること。
ポストモーテムの構成と注目したポイント
1. 障害発生に対する迅速な対応力
まず、メンバーの障害発生時の対応力が非常に高いと感じました。
今回の読む会で扱った障害では、調査開始からわずか10分で原因を特定し、収束に至っています。また、1時間後には障害発生のお知らせを公開しており、この迅速さには驚かされました。
背景には、エンジニアメンバーのアラートに対する高い意識があると考えられます。アラートチャンネルにログが流れた際、エンジニアメンバーはすぐに反応し、調査を始めています。興味深かったのは、初動のアクションが「確認します」など非常にシンプルな発信から始まることが多い点です。
会では「些細なことでいいからアラートに反応する習慣を身につけよう」という話題も挙がりました。些細な発信でも、アラートを認知している意思表示となり、その発信を見た詳しいメンバーが共に対応してくれる効果があります。これにより、アラート対応が特定の個人に依存せず、組織全体で支え合う仕組みが形成されていることが分かりました。
ちなみに、アラート対応に関連して「朝当番」という社内文化もありました。直近のブログ記事で詳しく紹介されているので、興味があればぜひ読んでみてください。
2. ドキュメントの透明性と活用の課題
もう一つ素晴らしいと感じた点は、失敗を風化させず、第三者でも気軽にアクセスできる形でドキュメントが共有されていることです。
今回読んだポストモーテムは社内ドキュメントツールであるesaに記載されており、社員であれば誰でも閲覧可能です。また、エンジニア組織の定例で直近で行われたポストモーテム事例の共有も行われています。過去の失敗や得られた教訓が組織全体の共有財産となることで、同じ過ちを繰り返さない取り組みが行われています。障害事例や過ちが公開されているということは、問題が新たに発生した場面において、問題を隠そう、小さく一部だけに伝わるようにしよう、といったネガティブな文化がほとんどないという環境だということです。
しかし一方で、課題も見えてきました。今回のような機会は頻繁に設けられているわけではなく、ポストモーテムを読むかどうかが個人の判断に委ねられている現状があるという指摘がありました。そのため、せっかくの知見が十分に活用されていないのでは、という課題感が共有されました。
当たり前のことに気づいていなかったのですが、ただポストモーテムを「読める場所に置いておくだけ」では不十分だということです。過去の障害や対応策を生かすためには、今回のようなイベントを継続的に実施し、知見を組織全体で活用する仕組みづくりが求められていると感じました。
3. リリースタイミングと対応における教訓
今回扱った障害は、金曜日に実行したDBマイグレーションが原因で、土曜日に発生したものでした。 幸い、休日にもかかわらずDB管理者をはじめ有志のエンジニアが迅速に対応してくださったため解決に至りましたが、もし誰も反応できなかった場合、休日の間中エラーが発生し続けていた可能性もありました。
リリース後に問題が発生した場合、すぐに対応できない状況だとトラブルが長引いてしまうリスクがあります。今回のような特に影響範囲が大きいDBのリリースについては、対応可能な時間帯を選定すること、リリースによる影響を把握しておくこと、リリース後のフォローアップ体制を整えて、仮にトラブルが発生しても被害を最小化できるように備えておくことが重要だと認識しました。
今回のDBマイグレーションの失敗を踏まえ、社内のドキュメントには新たに「マイグレーション実施時の注意点」という項目が追加されました。以下が実際に追加されたドキュメントです。根本的な解決には至らなくとも、できる対策をすぐに実践する姿勢は非常に学びがあると感じました。
会では「愚者は経験から学び、賢者は歴史から学ぶ」という言葉を引用しながら、DBに関しては特に「考古学」の視点が重要だという話がありました。過去の失敗から学び、未来に生かす姿勢を持ってほしい、というアドバイスが印象的でした。
今回の会を通じて、ポストモーテムなどの過去の事例から学ぶことの重要性を改めて意識するようになりました。また、リリースに対して対応できる時間や影響範囲について意識できるようになりました。まだ自分の失敗から学ぶことが多い日々ですが、少しずつ「歴史から学べる賢者」を目指して成長していきたいと思います。
おまけ
余談ですが、「ポストモーテムを読む会」を計画していた当日の午後に、偶然障害が発生しました。エラー発生手順を調査して社内に報告したところ、「良いアクションだった」と褒めていただけました。
結果的に、障害の原因は私が報告したエラー発生手順と関係ありませんでしたが、その時褒めてもらえたことで、自分自身も「次も主体性を持ってアラートに向き合おう」という意識が育まれた気がします。
Classiでは、「良かったことを素直に褒める」文化が根付いています。褒められた側はもちろん、褒めた側もお互いが「次も頑張ろう」という前向きな気持ちが生まれ、仕事の中で良いサイクルを実感しています。
これからも、社内で良い影響を与えられるよう、日々小さなことから積み重ねていきたいと思います。
*1:新卒研修のブログ記事はコチラ https://tech.classi.jp/entry/2024/09/06/163000
