Belong Engineering Hub
HomeAboutCareersGitHub

Belong での Postmortem について

Author:ke-noke-no
2025-09-03

はじめに

こんにちは。Belong でバックエンドエンジニアをしている ke-no です。

サービスを運営するにあたり、インシデントというのは避けて通れないものです。
ヒューマンエラーによるもの、システムの障害、外部からの攻撃など様々な要因でインシデントは発生します。
大切なのは可能な限り早い復旧と、同じインシデントを繰り返さないための振り返りと対策です。

本記事では、インシデント発生時の振り返りで Belong が全社的に行っている Postmortem の取り組みについて紹介します。

※ プロジェクトマネジメントの分野でも、プロジェクトの終了後に行う振り返りで Postmortem という同じ言葉を使用しますが、事後検証という意味では概ね同じです。

忙しい方向けまとめ

  • サービスを運用する以上、インシデントは避けて通れません。的確な対処、対策を行うためには発生後の振り返りが重要です
  • 振り返りで大切なのは個人の責任を追及するのではなく、インシデントが発生してしまったシステムの仕組みやチーム体制などの改善に繋がる議論を行うことです
  • Belong では振り返りに Postmortem という仕組みを導入しています。インシデントの詳細や影響範囲、原因、対応策などをドキュメント化し、組織全体で共有することで再発防止とサービス改善に努めています

Postmortem とは

Postmortem は「事後検証」という意味の言葉で、インシデントや障害が発生した後にその原因や影響を分析し、再発防止策を検討するプロセスを指します。

Postmortem の目的は一例として以下のようなものがあります。

  • インシデントの詳細な記録と分析
  • 再発防止策の検討と実施
  • 組織全体での知識共有

そして、Postmortem を行う上で特に重要とされているのが、Blameless（非難のない）という考え方です。
これは、誰がミスを犯したかではなくシステム構成やチーム体制など、どのような要因でインシデントが発生したかに焦点を当てるアプローチです。

Postmortem を実施するにあたって、決まったフォーマットはありません。運用するサービスの特性やチーム、組織の文化によって 最適な形式が異なるためです。
ただし、組織内で指標やフォーマットをある程度統一することで共有や議論が行いやすくなるため、それぞれが最善の形を模索することが重要です。

Google の公開しているサンプル Postmortem

Belong での取り組み

弊社 Belong では、にこスマを代表に、社内外で日々様々なシステムが稼働し、多くのオペレーションが行われます。 2019 年の設立から現在にかけて、ヒヤリハットで終わったものからサービスダウンなど大規模なインシデントまで、様々なインシデントが発生してきました。

それらのインシデントについて、Belong では早い段階から Postmortem の取り組みを組織的な文化として行ってきました。
個々の振り返りの内容は Google Docs や Notion を用いてドキュメント化し、組織全体で共有しています。

記載する際に気をつけないといけないのは、Engineering チーム外のメンバーも内容を確認する前提で書くことです。 自分が担当しているシステムやサービスのことで自明であっても、チーム外のメンバーには伝わらないものも多くあるため、極力全てのメンバーが理解できるように記載することが重要です。

ドキュメントとして記録している内容としては以下のようなものがあります。
これをベースとした上で、チームやサービスごとで必要な情報を付け足しているイメージです。

  • 概要
    • インシデントの内容をまとめたものです
    • 概要を見ただけでいつ発生していたのか、どのようなインシデントだったのかがわかるように記載します
  • 影響
    • どのサービスやユーザーに影響があったかの範囲やその規模・具体的な数字を記載します
    • 特定のページ・機能だけなのか、サービス全体に影響するのかなども記載すると良いです
    • 機能について触れる場合は、それによるユーザーへの影響まで明記するとチーム外の人にも理解しやすくなります
      • 「A 機能の停止により社内システムとの連携でエラーが発生した」の場合は、「結果、取引 B のステータス更新に遅延が発生しユーザーへの通知が遅延した」など具体的な影響まで書けるとより良いです
  • 原因
    • インシデントの原因となった要因を記載します
    • システムのバグやヒューマンエラー、インフラ関連の課題など要因は様々ですが、可能な限り詳細に記載します
  • 引き金
    • 原因を踏まえ、インシデントが発生するに至ったきっかけを記載します
    • 一例として、特定の操作を行なったことやリリース、外部サービスの仕様変更などが挙げられます
      • 操作者などを記載する場合は、Blameless の考え方に基づき個人名ではなくチーム名や役割名で記載することを推奨します
  • 解決策
    • インシデントの解決に向けて行った対応や、復旧までの手順を記載します
    • 対応の中には必ずしも有効でなかったものも含まれるかもしれませんが、「解決策」として復旧に向けてどのような対応を行ったかを記録することが重要です
      • 有効だった手順を優先して書き、有効でなかった対応はその理由も含めて分けて記載すると後から見た際に分かりやすいです
  • 発見
    • インシデントの発生をどう検知したかを記載します
    • 監視の仕組みが導入されている場合はシステムアラートなどがメインになります
  • 対策
    • インシデントの再発防止に向けて行うべき対策を記載します
    • 具体案まで記載することが望ましいですが、アーキテクチャの見直しなど大きな対策が必要な場合は、この方針で見直しを検討といった形で記載することもあります
    • ここに記載する内容はアクションアイテムになります。実施されない、実施できないものは意味がないためその点に注意が必要です。
      • 対応用のチケットを作成し、各対策にチケットへのリンクを記載しておくことを推奨します
  • 振り返り
    • インシデント対応全体や原因などを振り返り、上手くいったことや上手くいかなかったことを記載します
    • 客観的な視点で振り返り、チームや組織全体での改善点を見つけることが重要です
  • 時系列
    • インシデントの発生から復旧までの時系列を記載します
    • 時系列での対応の流れを細かく記載することで、インシデントの全体像を把握しやすくなります
    • 時系列を後から追うために、対応の進捗は適宜 Slack で投稿したり自分のメモなどに残しておくと良いです
      • Belong では専用の Slack チャンネルが自動で作成されるので、そこに進捗を投稿するようにしています
  • その他関連情報
    • 補足情報として、関連するドキュメントやリンク、参考情報などを記載します
    • 各大項目に記載するには長すぎる内容などをここに記載し、詳細は関連情報を参照〜といった形で記載する場合もあります

長くなってしまいましたが、Postmortem の内容はこのような形で記載しています。
これを組織全体で共有し、PjM/PdM や組織長との振り返りを行い、再発防止やサービス改善に繋げています。

Belong のサンプル Postmortem

他社事例

重要なのは、フォーマットはそれぞれ違えど各組織が Postmortem の取り組みを行い、インシデントの振り返りを行なっているということです。 仕組みを作り、それを文化とするのは簡単ではありませんが、サービスそして組織を成長させるためには欠かせない取り組みです。

おわりに

本記事では、Postmortem の概要と、Belong での取り組みについて紹介しました。
インシデント対応は決して楽しいものではありませんが、個人、そして組織・サービスの成長のきっかけにもなります。
Belong は日々成長しているため、今回紹介した内容も少しずつ変わっていくでしょうが、ベースとなる考えは変わりません。
自社の誇れる文化が一つの事例としてご参考になれば嬉しいです。

弊社 Belong ではこういった文化の中で一緒に働くエンジニアを募集しています。
興味がある方は Belong Engineering Careers ページ をご覧いただけると幸いです。