新人が育つ現場は障害から学ぶ。インフラのブレームレス・ポストモーテムを新人育成に組み込む設計

こんにちは、インフラエンジニアのryuです。

「昨日の障害、あれって結局、誰のミスだったんですか？」──新人からこう聞かれたとき、あなたの現場は、なんと答えているでしょうか。

答え方ひとつで、新人の伸び方は驚くほど変わります。担当者の名前を挙げて説明すれば、その新人は次から萎縮して手を動かさなくなります。逆に、「あの障害から何がわかって、次に何を仕込んだか」を淡々と話せる現場では、新人はむしろ障害を「勉強のチャンス」として自分から覗きに来るようになります。

この差を生んでいるのが、いま多くの現場で導入が進んでいるブレームレス・ポストモーテムという考え方です。GoogleのSRE Book 第15章で有名になった、「障害を人ではなく仕組みの問題として振り返る」文化のことです。

今日は、この考え方を「SREの上級テクニック」で終わらせず、新人インフラの育成プロセスにそのまま組み込む方法を、法人研修や現場OJTを設計する立場の方向けに具体的に書いていきます。

そもそもポストモーテムって、何をやるの？¶

「ポストモーテム（postmortem）」というと医療用語のイメージが強いですが、IT業界では障害が起きたあとに、原因と対応を文書にまとめて共有する振り返りを指します。日本語では「障害報告書」「事後分析」と訳されることが多いですね。

ただ、私たちが現場で書いている「障害報告書」と、SRE文脈で言うポストモーテムには、決定的に違うところがあります。それは、責任者を特定するために書くのか、次の再発を防ぐために書くのかという目的の違いです。

原因を「人」に置くと、報告書は謝罪と反省文になります。原因を「仕組み」に置くと、報告書は改善タスクの一覧になります。前者はハンコを押されて棚に眠りますが、後者は次の障害を1件減らします。

GoogleのSRE Workbookでは、ポストモーテムの主な目的をこう整理しています。

• 何が起きたかを事実として記録する
• 根本原因（root cause）を全員が理解できるまで書き下す
• 再発の可能性と影響を減らす具体的な予防策を残す

つまりポストモーテムは、書くこと自体がゴールではなく、次の一手を仕込むためのメモなんですね。

「ブレームレス（blameless）」の本当の意味¶

ここで大事な言葉が、ブレームレスです。直訳すると「非難しない」ですが、これを「誰も悪くない」と受け取ってしまうと、話がおかしくなります。

Googleが定義しているブレームレスは、もう少し正確にはこういう意味です。

インシデントに関わったすべての人は、その時点で持っていた情報の中で善意で最善を尽くした、という前提から議論を始める。

つまり、「担当者は最善を尽くしたのに、なぜミスに至れる仕組みが残っていたのか？」を問うのがブレームレスです。ミスした担当者を守るためではなく、次の担当者が同じ落とし穴に落ちないようにするための姿勢なんですね。

安全学の分野では、これに近い考え方を「Just Culture（公正な文化）」と呼びます。航空業界で長く研究してきたSidney Dekker教授は、Just Cultureを「信頼と学習と説明責任の文化」と表現していて、正直に報告した人を罰しない代わりに、意図的な違反や重大な怠慢だけを責任として切り出すという整理をしています。

日本の現場で「非難しない」と言うと、なあなあの馴れ合いに聞こえがちですが、ブレームレスはむしろ厳しい姿勢です。人を責める代わりに、仕組みを容赦なく責める。この線引きが、育成にそのまま効いてきます。

なぜ、新人育成に一番効くのか¶

ここが本題です。ブレームレス・ポストモーテムは、実は新人育成の教材として最強クラスです。理由は3つあります。

1つ目は、現場で本当に起きた本物のケースだから。研修で作った演習問題より、社内で先週起きた障害のほうが、リアリティも情報量も桁違いです。

2つ目は、先輩たちの思考プロセスがまるごと見えるから。誰がどのログを見て、どんな仮説を立て、どう切り分けたのか。この「調査の順番」こそ、新人が一番学びたい部分です。手順書を読んでも身につかない、暗黙知そのものですね。

3つ目は、「失敗しても晒し者にはならない」という安心感を新人に与えられるから。ブレームレスな振り返りをやっている現場を新人に見せることは、「あなたも将来ミスするだろうけど、この現場では吊し上げないよ」という無言のメッセージになります。心理的安全性が学習速度を上げる、というのはインフラエンジニアに必要なスキルを身につけていく上でも、じわじわ効いてきます。

私が過去に支援した現場では、新人が独り立ちするまでの期間を、ポストモーテムの読み会だけで平均1.5ヶ月ほど縮められた例もあります。障害のトラブルシューティングは、机上では学びきれない領域なので、当然といえば当然の効果です。

ポストモーテムの基本構成（テンプレート）¶

具体的にどう書くかを見てみましょう。SRE Book で紹介されているポストモーテムは、だいたい次のような構成になっています。多くの現場は、これを社内テンプレート化して使っています。

大事なのは、すべての項目が「事実」または「仕組みの改善」に紐づいていることです。「担当者Aの確認不足」ではなく、「本番反映前のダブルチェックが仕組み化されていなかった」と書きます。

補足として、こんな粒度で書けると理想的です。

直接原因: 本番DBに向けて DROP TABLE users_tmp を実行したが、_tmp サフィックスの命名規則が徹底されておらず、実体は本番の users テーブルを指すシノニムだった。 仕組みの原因: 本番のDDLに対する承認フローがなく、シノニムの一覧を可視化する仕組みもなかった。

「担当者が慌てていた」で終わらせず、そこまで書き切るのがブレームレスの流儀ですね。

新人研修に組み込む3ステップ¶

では、これをどう新人育成のフローに組み込むか。私が実際に法人研修で提案しているのは、次の3ステップです。

ステップ1：既存のポストモーテムを「読む」¶

いきなり書かせるのは無理です。まずは過去1年分の社内ポストモーテムをアーカイブして、新人に読み物として渡します。

読むだけでもかなり学べます。「うちの会社はこういう障害が多いんだ」「復旧の判断ってこの人に相談するんだ」「監視ってここが穴だったのか」──こうした暗黙知を、雑談やOJTより早く吸収できます。

読み方には少し工夫を入れます。「もし自分がこの障害の当日、当直だったらどこで手が止まるか」を書き出させるんですね。当事者の視点で読むと、単なる読書が擬似的なインシデント演習になります。

ステップ2：先輩のポストモーテム作成に「同席」する¶

次のステップは、実際にポストモーテム会議に同席させることです。発言はしなくていい、議事録も取らなくていい。ただ議論を聞くだけです。

これは以前ご紹介した、新人インフラのOJTを仕組みに変えるトレーナー制度とも相性が良いやり方です。トレーナーが同席し、会議の後で15分だけ「なぜあの質問をしたか」「なぜあの選択肢を捨てたか」を解説してもらう。ここで一気に、思考プロセスの解像度が上がります。

ステップ3：小さな事象で「自分で書いてみる」¶

最後のステップは、新人自身にポストモーテムを書かせることです。ただし、いきなり大障害を任せるわけにはいきません。

おすすめは、「ヒヤリハット」や「準障害」レベルの小さな事象からです。たとえばこんなものです。

• 検証環境で誤ってサービスを止めてしまった
• 手順書どおりにやったのに、コマンドが1回失敗した
• アラートは鳴ったが、実害はなかった

こういう「ちょっとしたやらかし」を、本人にテンプレートで書いてもらい、トレーナーがブレームレスな観点でレビューします。書き直しは何度でもOK。「担当者Aの操作ミス」を「操作ミスを許した仕組みの穴」に翻訳する練習を、繰り返し積んでもらうのが目的です。

現場に定着させるためのコツ¶

ここまで読んで、「うちの現場でこれをやるのは無理そう」と思った方もいるかもしれません。日本の現場では、どうしても「誰の責任か」を最初に問う空気があります。

でも、いくつか押さえておけば、少しずつ根付かせることはできます。

まず、マネジメント側が最初に発言のトーンを決めること。マネージャーが「誰がやった」の話から入ってしまうと、その1回で場は死にます。「この障害から何を学ぼうか」で始める。それだけで空気が変わります。

次に、ポストモーテム作成の時間を業務として認めること。「勤務時間外に反省文を書いてこい」では、正直に書ける文化は絶対に育ちません。障害から1〜2営業日以内に、レビューを含めて業務として時間を確保するのが、現実的な運用です。

そして、Action Itemを必ずチケット化して追跡すること。ポストモーテムを書いたのに再発防止タスクが放置されていると、書くこと自体が「儀式」に見えてきて、書き手のモチベーションが下がります。JiraでもBacklogでも、必ずチケット化して、レビューで残タスクをちゃんと詰めましょう。

これは属人化の解消にも直結します。この観点は以前、インフラの属人化を解消する育成とナレッジ継承の記事でも扱いました。ポストモーテムは、まさに「あの人しか知らない障害対応の思考」を組織の資産に変える装置です。

「うちにSREなんていない」現場でも始められる¶

「Google SRE の話でしょう？うちにはSREチームもないし……」と思うかもしれません。でも、ポストモーテムはSREチームがいない現場でも、明日から始められるプラクティスです。

必要なのは、大きく分けて次の3つだけ。

1) 障害の翌日〜2営業日以内に30分だけ振り返りを開く
2) テンプレート（Markdownで十分）に沿って議事を残す
3) Action Item を必ずチケット化する

たったこれだけです。ツールはNotionでもConfluenceでも、なんならGitHubのIssueでも構いません。仕組みが小さいほど、続きやすいんですね。

社内に体系的なインフラ研修が無い、ポストモーテムどころか障害報告書のフォーマットすら統一されていない──そういう組織の場合は、まず外部のカリキュラムを利用してインフラ運用の共通言語を作るところから始めるのも有効です。InfraAcademyの法人プランでは、ネットワーク・Linux・クラウドの基礎から、監視や障害対応の考え方まで、体系的に新人へインプットできます。ポストモーテムを読むにも書くにも、まずこの共通言語がないと議論が噛み合わないんですよね。

よくある失敗パターン¶

最後に、私がこれまで見てきた「せっかく始めたのに続かないポストモーテム」の失敗パターンを共有します。

• 「原因は担当者の注意不足」で締めてしまう。これが1件でも通ってしまうと、以降のポストモーテムは全部このパターンになります。
• Action Itemが「気をつける」「意識する」で終わる。これは仕組みの改善ではなく精神論なので、次の障害を1件も減らしません。
• ポストモーテムが役員に上げる資料になる。読者が変わると、書き手は事実より体裁を優先し始めます。ポストモーテムはまず現場のためのメモです。
• 「うちの障害は特殊だから共有できない」と抱え込む。他部署が同じ落とし穴に落ちる確率が上がるだけです。少なくとも社内には全公開が原則。

こういう落とし穴を避けるだけで、続きやすさはぐっと変わります。運用の考え方そのものについては、SREの信頼性設計やオブザーバビリティの記事もあわせて読んでいただくと、ポストモーテムが「単なる反省会」ではなく、システム改善のサイクルの中心にあることが見えてくると思います。

まとめ¶

障害は、起きないほうがもちろんいい。でも、起きたあとに何を残せるかで、組織の学習スピードは何倍にも変わります。

• ポストモーテムは、責任者を特定するための儀式ではなく、次の障害を1件減らすためのメモ
• ブレームレスとは「誰も悪くない」ではなく、「善意の担当者を落とし穴に落とした仕組みを容赦なく責める」姿勢
• 新人育成には、読む → 同席する → 書くの3ステップで組み込むと、独り立ちまでの期間を目に見えて縮められる
• 続けるコツは、マネジメントの発言トーン、業務時間としての確保、Action Itemのチケット化

「うちは障害が多くて大変で……」という声はよく聞きます。でも、その障害の一つひとつが新人にとっては教科書の何倍もの教材でもあります。責める文化から学ぶ文化へ、今日の1件から少しずつ、切り替えていきましょう。

参考¶

• Postmortem Culture: Learning from Failure — Google SRE Book, Chapter 15
• Postmortem Culture — Google SRE Workbook
• How to run a blameless postmortem — Atlassian
• Post-incident review best practices — Atlassian（Jira Service Management）
• Just Culture — Sidney Dekker
• 良いポストモーテムを執筆するために必要な5つのポイント — 株式会社スリーシェイク