ポストモーテムをどのように進めるべきか、で私が参考にしている、Jeli が公開しているガイド「 Howie: The Post-Incident Guide 」の"ナラティブ"について考えてみます。

Howie Guide は、ポストモーテムに代わる Learning Review のプロセスを8ステップで提示している。その中で重要視されているのが、インシデントの記述を単純なタイムラインではなくナラティブとして構築することです。

Howie Guide の簡単な紹介

Howie は "How We Got Here"(どうやってここに至ったか)の略で、インシデント発生後からの8ステップで構成されている。

準備

  1. Assign: 調査者の任命

  2. Identify: データソースの特定・収集

  3. Analyze: タグ付け・ナラティブ・タイムライン作成

  4. Interview: 関係者へのインタビュー

  5. Calibrate: 関係者との認識すり合わせ

本会議

  1. Meet: Learning Review の実施

会議後

  1. Report: 「How we got here」レポート作成

  2. Distribute: 学びの組織内共有

従来のポストモーテム文化との差は、

  • "post-mortem"(検死)ではなく "learning review"(学習レビュー)

  • "blameless"(非難なし)から "blame-aware"(非難への気付き)

  • "Root cause"(単一根本原因)を求めず、複数の寄与要因として捉える

  • エラー削減(Error reduction)だけでなくインサイト生成も重視する

ナラティブ

Howie Guide はナラティブを次のように定義している。

A deeper analysis goes beyond simply recounting what happened in a basic chronological timeline. Instead, try to recreate the event as it happened, walking through the progression of the event and identifying what made it challenging or easy to diagnose and resolve. Investigators who recreate the timeline by creating a narrative about what happened tell a story that allows for complexities and confusions to become apparent. This allows readers of a post-incident report (or participants in a learning review meeting) to get more actively engaged with the investigation since it tells a richer, more compelling account. Readers can imagine the situation the way it happened, not in hindsight when the outcome was known and it is easily understood what should have happened. Learning becomes clearer when you go beyond a simple timeline.
— What is the narrative?

深い分析とは、単に何が起きたかを基本的な時系列のタイムラインで列挙するだけにとどまりません。そうではなく、出来事を実際に起きたとおりに再構築し、事象の進行を追いながら、診断と解決を困難にした（あるいは容易にした）要因を特定することを目指します。何が起きたかについてのナラティブを組み立てることでタイムラインを再現する調査者は、複雑さや混乱が浮かび上がるようなストーリーを語ります。これにより、ポストインシデントレポートの読者（あるいはラーニングレビューミーティングの参加者）は、より豊かで引き込まれる記述に触れることになり、調査内容に対してより能動的に関与できるようになります。読者は、結果が判明したあとに「何をすべきだったか」が容易に理解できる後知恵の視点ではなく、実際にその出来事が起きたとおりに状況を思い描くことができます。単純なタイムラインを超えたとき、学びはより明確なものになるのです。

つまり、インシデントが当時どう体験されたかを、当事者の認識のまま再構築した物語と言える。

ナラティブ作成時に「避けるもの」

避けるもの該当箇所内容

hindsight

Analyze

結末がわかった上での後知恵

counterfactuals

Interview, Meet

「もし～していれば」という反実仮想

one-dimensional, single point of view

Report

単一視点の一次元的なレポート

clean, forward progression between 'detect, diagnose, and repair'

Analyze

「検知 → 診断 → 修復のクリーンな進行」という単純化

具体例

ナラティブではない書き方(単なるタイムライン)
14:00 アラート発火
14:15 エンジニアＡが原因をDB接続と特定
14:30 修正デプロイ完了
ナラティブな書き方
14:00 APIレイテンシのアラートが発火した。
      エンジニアAが最初に応答したが、ダッシュボードを見る限りデータベースは正常に見えたため、
      最初の仮説はCDNの問題だった。
      エンジニアBが参加し、別のダッシュボードでDB接続プールの異常を指摘したが、
      Aはその直前に別のインシデントでCDN起因の類似症状を見ていたため、当初は半信半疑だった。
14:15 Bが具体的なログを共有したことでAの認識が変わり、
      原因がデータベース側にあるという仮説に収束した。

ナラティブの作成方法

1. Identify - データ収集

客観的に揺るがない記録の収集をする。

例

  • チャット記録(transcripts)

  • 組織図(organizational charts)

  • 関係者の情報 (誰がどのチームか、勤続期間、誰と通常一緒に働いているか、どのシステムを担当しているか、当該システムのオンコール期間)

  • アラートログ

  • オンコールスケジュール

  • ダッシュボード

インシデントデータは複数のチャンネルに分散していることが多い。主要チャンネルからキープレイヤーと役割を追跡し、関連チャンネルもスキャンする。

2. Analyze - Tagging - タグ付け

組織内で標準化されたタグセットを使う

タグの種類は分析の深さに応じて調整する(軽い分析なら 検知・原因調査中・復旧完了 の3つ程度。深い分析なら仮説の提示・検証・ステークホルダーへの更新・システム挙動の急変・影響緩和のためのアクションなど)

2つの基本タグ
narrative

起きた出来事をどう物語るかに関連するメッセージやイベント

participant follow-up

イベントに関わった人に質問したい箇所

このタグ付けは質的調査におけるアノテーション作業にあたる。収集したデータに対して調査官の見解を付与していく。

3. Analyze - ナラティブを深化するための3つの観点

観点1 : インシデントの冒頭で何が起きていたか

  • 対応者は何が起きていると思ったか?

  • 誰が呼ばれた/参加したか?

  • どんな情報が利用可能だったか?

  • 何が不確実/曖昧だったか?

  • 誰が問い、誰が答えたか?

観点2 : チームはどのように問題を診断していたか

  • どんな仮説が提示されたか? (複数の仮説、消えた仮説、無視された仮説も含む)

  • 誰が仮説を提示したか? (participant follow-up タグ候補)

  • 誰が仮説の証明/反証を助けたか? (ダッシュボード、ログ、専門知識など)

  • どんなアクションが、誰によって取られたか?

  • 何が起きているかについて曖昧さや混乱はあったか?

観点3 : インシデント中、チームはどう協働していたか

  • 異なる関係者間でうまく協調できた例はどこか?

  • チームは誰の助けが必要かを先回りして予測し、スムーズに連携できたか？?

  • コミュニケーションの破綻はどこで起きていたか? 対応者は情報を素早く簡単に共有できていたか?

4. Creating timelines - タイムライン作成

  • テキストベースのタイムラインを超えて、視覚的な表現を作る

  • 時間があれば複数のタイムラインを作成する

false-starts と red herrings

検知 → 診断 → 復旧のクリーンな進行を作ってしまうことを避けるために使う

false-starts:

空振り、誤った出だし。やってみたけれど、役に立たなかった対応・調査のこと

red herrings:

偽の手がかり、ミスリード。本当の原因と関係ないのに、原因らしく見えてしまう情報や兆候

タイムラインの要素

  • 出来事

  • キーワード

  • 特定の参加者

  • 異なるデータタイプ

5. Making notes メモと残課題の整理

タグ付け中に出てきた疑問点を、フォローアップのために整理する。

「実は $SOFTWARE が関係していると思うので、その変更をロールバックすれば直るはずです」

このようなメッセージは、narrative と participant follow-up タグの両方を付け、自分用のメモとして以下のような質問を残す可能性が高い。

(なぜ $SOFTWARE だと分かったか? 原因らしいと思わせたものは何か? なぜロールバックを提案したか?)
よくある質問の例

  • この技術はどう動いているか? この組織におけるその技術の歴史は?

  • この作業はどこで始まったか?

  • ビジネス上の理由は何だったか?

  • この専門家にコンタクトすべきだとどうやって知ったか?

  • どうやってこの情報を見つけたか?

  • 対応者はどんなプレッシャー下にあったか?

  • この略語/絵文字リアクションの意味は何か?

  • 他に誰がこれを知っているか?

6. Interview - 複数視点を引き出す

関係者一人ひとりと個別に話すことで、認識の delta が明らかになる。delta が最も生産的なレビューに活用される

対象者の選定基準

  • イベントのキープレイヤー

  • 非難を感じうる人(主観を正確に反映するため)

  • 想定外に関与した人(オンコールでなかった人)

  • 単独行動した人(lone wolves)

  • 孤立した知識の持ち主(islands of knowledge)

  • 影響を受けたシステムの所有者(または前所有者)

  • 関連するサブジェクトマター・エキスパート

  • 変更のきっかけとなったチケットを書いた人

  • その変更を実装した人

  • 組織に新しく加わった人(隠れた前提や矛盾を表面化させる)

インタビュー開始時の典型的な質問

  • どのようにしてイベントに最初に関わったか?

  • 関わり始めた時点での状況理解はどうだったか?

  • あなたの視点から、インシデントで何が起きたかを説明してもらえるか?

深掘りの質問例

  • どのようにしてこのインシデントの通知を受けたか?

  • $X とはどういう意味だったか?

  • 出来事の順序を教えてほしい

  • ある時点で「$X」と発言していたが、これはどういう意味だったか?

  • どの時点で $POTENTIAL_MITIGATOR / $POTENTIAL_TRIGGER を発見したか?

  • どのダッシュボードを見ていたか? ログ/ダッシュボードで何を探していたか? 見せてもらえるか?

  • 状況評価への自信の度合いはどうだったか? どのくらいここにいるか? どのように物事が行われているのを見てきたか?

  • $X について頻繁にオンコール対応しているか? 誰がオンコールか? どう感じたか?

  • このインシデントで何に驚いたか?

  • インシデント対応はどのような形を取って進んだか?

  • インタビュー対象者が意見やカウンターファクチュアルを共有した場合は、さらなる明確化を求める

$X, $POTENTIAL_MITIGATOR, $POTENTIAL_TRIGGER はそれぞれプレースホルダー、MITIGATORは被害を抑えたもの、TRIGGERは事態を引き起こした要因

7. Calibrate - キャリブレーション・ドキュメント作成

キャリブレーション・ドキュメントには以下を含める:

  • これまでにレビューしたデータの情報

  • インタビューした人の情報

  • この取り組みから浮かび上がったテーマ

3種類の集約

1.テーマの集約

調査官は何に驚いたか、他者が知るべきだと思うこと、他のインシデントと共有されることを集約する

2.データの視覚的表現としての集約
point-of-view timelines

異なる対応者がイベントをどう体験したかを示す複数の視点別タイムライン

narrative timeline

イベントの主要な瞬間を示すタイムライン(最初のアラート、メジャーインシデントへのエスカレーション、専門家の招集、トラブルシューティングのステップ、仮説の発展や反証、影響の認識や変化など)

3.書面としての集約

ドラフト文書を作成し、レビュー会議の前に参加者に共有してフィードバックを得る

キャリブレーション時の具体的な質問例

  • この部分を正しく捉えているか確認したい。レビューして意見をくれるか?

  • このドキュメントに含めて議論すべき抜けている項目はあるか?

  • この技術的詳細は正しいか?

ナラティブを民族誌学的調査とNVCの観点から考察する

Howie Guideのプロセスは、民族誌学的調査・NVCの観点からアップデートの方向性を捉えることが出来る。

Triangulation(三角測量, 方法論的複眼)

質的調査におけるトライアンギュレーションとは、単一の情報を真実とせず、所謂裏を取っていく作業をすること。これらはナラティブの作成時に単なるタイムラインとしないために、使われているように見える。

Table 1. triangulationの種類
種類説明

Data triangulation

データーそのもの多元化する三角測量

Investigator triangulation

調査者を複数化するという三角測量

Theory triangulation

分析につかう理論の多元化

Methodological triangulation

方法論の多元化

Thick Description

ナラティブの書き方は機械的論理的な書き方というより、民族誌学調査の thick description （厚い記述） を想起させます。 何かを学ぶための過去への理解の記述として、 thick description が参考にされた可能性が高いと考えています。 ただし、完全に thick description にしてしまうと可読性が下がってしまうので、あくまで影響を受けただけだと考えています。

Thin description

14:05、Ａが CDN ダッシュボードを開いた

Thick description

14:05、Ａは直前の類似インシデントの記憶から CDN を疑ってダッシュボードを開いたが、 グラフが紛らわしく確信は持てなかった。同時刻に Ｂは別の角度から データベースログを見ており、 二人の間で仮説の合意はまだ形成されていなかった。

NVCの文化の影響

NVC(非暴力コミニケーション)の影響も考えられる。

blame-less から blame-aware

これは、元々、Etsy ガイドだと blame-less（非難しない）だったものが、 Howie ガイドでは blame-aware（非難に気付く）となっている箇所です。

懲罰的世界観から修復的世界観への転換のように見えます。～すべき、～してはいけないの世界観である懲罰的世界観の blame-less から、いかにして間違いを超えて修復していくかの、blame-aware への転換と私は見ています。

observation / feel / needs / request との親和性

NVCではごちゃっとした普段のやりとりを上記のフレームワークに従って整理整頓していきます。

このやり方を直接使っているというよりは、このような整理整頓を常に心がけていると、ナラティブを書き起こす時の主観・客観の情報の抜き出しが楽になるように見えます。特に NVC の observation では観測者の評価判断を極力取り除くことを練習しますので、相性がいいと思います。

ナラティブがなぜ必要か

  • 単純なタイムラインより、学びが明確になる

  • 曖昧さと混乱を保存することで、それが対応者の能力不足だけではなく、当時の状況の困難さを理解する助けになる

  • 「検知→診断→修復」という単純化を防ぎ、組織の学びに貢献する

  • 単一視点の一次元的なレポートを防ぎ、組織の学びに貢献する

  • エンジニア以外の役割(カスタマーサポートなど)にも学びを提供しやすくなる

まとめ

従来のポストモーテムをラーニングレビューへとアップデートするための Howie Guide の中で、ナラティブはその中心的存在だと感じています。

単純なタイムラインだけでは、結末から逆算した「何をすべきだったか」の物語に収束しやすく、当時の認識・揺れ・混乱が削ぎ落とされてしまいます。ナラティブは、その時その場で対応者が何を見て、何を疑い、どう判断していたかを残すための有用な道具になるでしょう。