はじめに
ポストモーテムとは、事後検証を意味する言葉で、システム障害やインシデントなどの問題を分析して再発防止策を検討するプロセスです。
(GoogleGemini)
IT業界に限らず、様々な業種で重要な役割を果たしています。医療現場でのインシデントレポートや、製造業での不具合報告書など、形は違えど同じような文書を目にする機会は多いでしょう。
その内容例は、こういったものです。
ポストモーテムの例
* 発生日時: 2025年03月24日 17:41 JST
* 影響範囲: ユーザーログイン機能
* エラー内容: ログイン時に「500 Internal Server Error」が発生
* 影響ユーザー数：約1000人
**対応:**
1. 10:05: サーバーログを確認し、データベース接続エラーが発生していることを確認。
2. 10:10: データベースサーバーを再起動。
3. 10:15: ログイン機能が復旧したことを確認。
**原因:**
* データベースサーバーのメモリ不足により、接続がタイムアウトした。
**再発防止策:**
* データベースサーバーのメモリを増強する。
* データベース接続プールの設定を最適化する。
* データベースの監視を強化する。
**教訓:**
* メモリ不足によるデータベース接続エラーは、事前に検知することが難しい。
* データベースの監視体制を強化する必要がある。
* 障害発生時のエスカレーションフローを明確にする。
開発現場において、ポストモーテムは単なる問題分析の記録以上の価値を持ちます。それは、チーム全体の知見を蓄積し、同様の問題に対する効率的な解決策を提供する重要なツールです。
しかし、この有用な文化が十分に根付きにくいアンチパターンの一例には、エンジニアの心理的な壁が存在するといった要因があるかもしれません。
アンチパターンの仮説
特に懸念されるのは、エンジニアのプライドが障壁となるケースです。デグレード・副作用による問題であっても、それを自身の技術力不足と結びつけてしまい、評価への影響を恐れてポストモーテムの作成を躊躇してしまう―――このような心理は、開発現場では珍しくないのは無いでしょうか。
解決策となりうる視点
この課題に対して、二つの重要な視点を提示したいと思います。これらはこの後さらに詳しく述べます。
まず、①「文学的な価値観」の導入 です。科学的アプローチが再現性や普遍性を重視するのに対し、文学的アプローチは個別の経験や文脈を大切にします。この視点は、問題を「失敗」として断罪するのではなく、固有の経験として記録し、共有する価値があることを教えてくれます。
次に、②Googleのような一流企業の実例 です。彼らは、サービス停止という事態に直面したエンジニアに対し、その迅速な対応を称賛し、むしろ積極的に評価しました。これは、問題の発生自体ではなく、その対処と学びのプロセスこそが重要だという価値観を示しています。
これらの視点は、「失敗を隠す」という防衛的な姿勢 から、「経験を共有し、成長につなげる」 という建設的な文化への転換を促します。ポストモーテムは、個人の評価のためではなく、チーム全体の知恵を育むための場なのです。
このように、文学的価値観の理解と、先進的な企業文化の例を知ることは、開発現場における心理的な障壁を取り除き、より健全なポストモーテム文化の醸成につながるのではないでしょうか。
1.文学的な価値観の存在
エンジニアリングの世界では、しばしば科学的・論理的なアプローチが重視されます。「同じ事で悩まない」という考え方も、まさにその典型と言えるでしょう。しかし、システム開発の現場において、純粋な科学的アプローチだけでは捉えきれない現実が存在することも、私たちは知っています。
科学のアプローチは"ある一つの条件の変化に従属する事象の変化を観察する為に、他の条件を同じに揃える。或いは同じとみなして考察します。"
小学校の子供達が理科の実験で、試験管にあるもの同士を混ぜるとき、何種類か比較するのに「同じ量の液体」が入っている。これは「液体に入っているものの種類による効果の違い」を比較する為にある。
一方、文学的アプローチは、その瞬間の体験全体を包括的に捉えようとします。
先程の理科の実験に例えれば、「変色した試験管に映る窓越しの校庭の景色がフィルム🎞️のようで綺麗だった。」「色がどれも透明であった上にお昼ご飯の後で眠たかった為、実験の途中でどれにどれが溶けていたか忘れてしまった。」といった、一回性の体験として記述されます。
ポストモーテムには書式があり、この文学的視点は、一見するとエンジニアリングの世界では場違いに思えるかもしれません。しかし、特にシステム開発において、この視点は意外にも重要な役割を果たします。なぜなら、システムの振る舞いは、単純な因果関係だけでは説明できない複雑さを持っているからです。
例えば、インクリメンタルなアップデートを行う際、「以前と同じ条件」だと思い込むことは危険です。2025年3月24日17時41分という特定の時点で、特定の場所で発生した問題は、まさに一回性の出来事かもしれません。システムの状態は、時間とともに常に変化しているのです。
興味深いことに、文学的アプローチで記述された経験は、後に科学的な改善につながることもあります。理科実験での生徒の体験が、授業改善のヒント(窓際で実験中の試験管の写真を撮影しプロジェクターで公開し、興味を引く等)になるように、ポストモーテムにおいても、個々の具体的な体験の記述が、システムの改善につながる気付きを生むことがあります。
このように、科学と文学は、相反する視点ではなく、相補的な関係にあるとも言えるかもしれません。 エンジニアリングの現場で、この両方の視点を持つことは、より豊かな問題解決と、より深い理解につながるのではないでしょうか。
2.ケース「失敗から学ぶ文化」
2014年、シリコンバレーの一室で興味深い出来事がありました。Googleの全社会議の場で、一人のエンジニアの経験が、企業文化の真髄を映し出す鏡となったのです。
One SRE discussed a release he had recently pushed; despite thorough testing, an unexpected interaction inadvertently took down a critical service for four minutes. The incident only lasted four minutes because the SRE had the presence of mind to roll back the change immediately, averting a much longer and larger-scale outage. Not only did this engineer receive two peer bonuses immediately afterward in recognition of his quick and level-headed handling of the incident, but he also received a huge round of applause from the TGIF audience, which included the company’s founders and an audience of Googlers numbering in the thousands.
(引用:Best Practice: Visibly Reward People for Doing the Right Thing
https://sre.google/sre-book/postmortem-culture/ )
その日、Larry Page氏とSergey Brin氏という二人の創業者の前で語られたのは、一見すると失敗とも取れる出来事でした。入念なテストを重ねたにも関わらず、予期せぬ相互作用により、重要なサービスがダウンしてしまったのです。
しかし、この「失敗」の物語には、重要な転換点がありました。そのエンジニアは冷静さを保ち、即座に判断を下してシステムをロールバックしたのです。その結果、サービスの停止時間はわずか4分間で済みました。 より大規模な障害を未然に防いだこの迅速な対応は、まさに危機管理の模範といえるものでした。
興味深いのは、この出来事に対するGoogleの反応です。 エンジニアは2件の特別ボーナスを受け取っただけでなく、数千人規模の会場から大きな拍手が沸き起こったのです。これは単なる褒賞以上の意味を持っています。
この事例は、世界をリードするテクノロジー企業の価値観を如実に表しています。彼らは「失敗」そのものではなく、その後の対応と学びを重視する文化を育んでいるのです。 新しい挑戦には常にリスクが伴います。過度に厳格なSLA(サービスレベルアグリーメント)を設けることは、むしろイノベーションの足かせとなりかねません。
Googleの姿勢は、現代のテクノロジー開発における重要な教訓を私たちに示しています。それは、完璧を求めすぎるのではなく、失敗から学び、素早く適切に対応できる能力こそが、真の価値を生み出すという事実です。