以下の内容はhttps://blog.topotal.tech/entry/2026/03/17/110000より取得しました。


ポストモーテム活用とオンコール改善で障害対応を組織化する方法

『SREの知識地図』の著者を招いてお送りするSREの旅 Road4

Topotalの宮里です。 2026年2月に開催したオンラインイベントのレポートをブログにまとめました。

今回は、SREの知識地図の著者・渡部龍一さん(@ryuichi_1208)をゲストにお招きし、書籍第4章「障害を学びにつなげる」 / 第5章「障害対応のプロセスや体制を作る」についてのオンラインイベントを開催しました。

深夜のアラート対応でメンバーが疲弊していく、ポストモーテムが反省文になってしまう、再発防止策が誰も実施しない。こういったお悩みを持ったことはありませんか?今回のトークはそのモヤモヤを解消するヒントが詰まっていました。内容をギュッとまとめてお届けします!


2つの章で伝えたかったこと

渡部さんがこの章を書いたのは、「現場で本当に困ることって、難しい技術的課題よりも人と組織の問題の方が大きい」という経験からだそうです。

  • 深夜3時に誰がどう判断すればいいか分からない
  • 乗り越えた障害をすぐ忘れて、同じ障害を繰り返してしまう
  • エンジニアの頑張りで回そうとして、組織が破綻していく

「障害対応を個人のスキルに依存せず、誰がやっても再現できる形に落とし込むことがテーマです。4章は文化、5章は制度という側面からアプローチしています」


オンコールと燃え尽き症候群 - なくせないけど、減らせる

燃え尽き症候群は完全になくせるのか?という問いに対して、渡部さんの答えは...

「なくせないとは思っています。でもどうにかして減らしていきたいというのはずっと思っているところで」

燃え尽きの主な原因はアラートの大量発生。また、オンコール自体が辛いというよりもいつ呼ばれるか分からない状態が辛い、という声も紹介されています。そういった場合は1on1でローテーションからの一時離脱を提案するだけで効果があったとのことです。

オンコールを誰が持つべきかという話では、最終的にはアプリケーションエンジニアも含めた全員で対応することが良い、という考え方が紹介されました。ビジネスロジックに踏み込んだ障害になると、SREチームだけでは対応しきれないケースが多いためです。

ただし、慣れていないメンバーに急に渡すのではなく、ツールの使い方からトレーニングする、SREと一緒にランブックを整備する、しばらくはダブルアサインするといった段階的なオンボーディングが重要とのこと。


障害対応を “楽しめるよう” になるには

渡部さんご自身は、楽しんで障害対応をするタイプと仰っていましたが、最初からそうだったわけではないとのこと。緊張をほぐすためにやっていたのが あらゆる障害に顔を突っ込む でした。

「100本やりましょうみたいな話になっちゃうんですけど(笑)。緊張を緩和して早く対応できればユーザーが幸せになるんだって思いながら取り組んでいたら、楽しめるようになっていきましたね」

また、定期的な障害対応訓練も有効です。渡部さんの会社では、今の開発状況を見てヤバそうなポイントを仕込んでステージング環境で訓練するシナリオベースの方法を採用。参加者から「障害対応が怖いものという印象が変わった」という声が上がっており、狙い通りだと感じているそうです。過去のポストモーテムを再現する訓練は新メンバーのオンボーディングにも効果的とのことでした。


ポストモーテムは反省文じゃない

第4章の核心テーマです。渡部さんが特に伝えたかったのはこの一点でした。

「ポストモーテムは誰かを責める作業ではありません。なぜそのミスを防げなかったのか、なぜ後から気づけなかったのかを分析するプロセスです。未来の障害を減らすための設計図であり、組織の記憶に変えるものです」

うまく書けない・書かれないという課題に対してはモブポストモーテムが効果的だと紹介されました。対応した人たちを集めて、画面共有しながら一緒に書き進めるモブプロ形式です。1人に任せると書かれないことが多いので、場ごと設計してしまうのがポイントとのこと。

AIで書かせた経験もあったそうですが、自動生成されたものは読まれなくなったという反省も。タイムラインなど時系列整理はAIに任せて、再発防止策など「人間が本当に考えるべき部分」は人間が担うハイブリッドが理想だという話でした。


再発防止策 ”やらない勇気” を持つ

最後に出てきたのが、一番難しいテーマかもしれない再発防止策が実施されない問題です。渡部さんが最近意識しているのが やらない勇気を醸成すること。

「発生確率が年1回で、復旧に20分しかかからないものを防ぐために2週間かかる対策をやるみたいな話は、リスクを許容してやらないと決める。エラーバジェットを許容するというSREの考え方にかなり近いと思っています」

合わせて紹介されていたのが放置されたタスクを自動クローズする仕組み。1ヶ月ほど動きのないタスクは自動でクローズされる運用で、塩漬けタスクが溜まらない状態を作っています。

「やらないんだったらないのと一緒。バックログに大量に残っているのは精神衛生上も良くないので」


まとめ

今回のオンラインイベントを通じて、渡部さんが伝えていたことはこの3つです。

ポストモーテムは未来への投資: 過去の犯人探しではなく、組織を強くするためのもの

オンコールの大変さは個人の問題じゃない: 鳴り止まないアラートはシステムからの「改善してくれ」という悲鳴。人の頑張りで蓋をしてはいけない

決断のコストを下げる: Runbookで迷いを減らし、やらないことを決める勇気を持つ。それがエンジニアを守り、サービスの信頼性を守ることにつながる

「あの人がいれば治る」「みんなで徹夜すればなんとかなる」という状態から抜け出すためのヒントが、書籍の第4章・第5章にぎっしり詰まっています。ぜひアーカイブ動画と合わせてご確認ください。

終わりに

SREの知識地図 第4章と第5章のアーカイブ動画は以下よりご確認ください〜

🎥 アーカイブ動画はこちら

📩 次回のイベント通知を受け取りたい方はConnpassでフォローをお願いします〜




以上の内容はhttps://blog.topotal.tech/entry/2026/03/17/110000より取得しました。
このページはhttp://font.textar.tv/のウェブフォントを使用してます

不具合報告/要望等はこちらへお願いします。
モバイルやる夫Viewer Ver0.14