以下の記事などで既にかなり話題になっていますが、ぼくも触ってみました(使い方などの詳細はこちらの記事を参照してください)。

結論としては、マジすごくてかなり衝撃的です。すべてのホワイトカラーワーカーにとって、かなりディスラプティブなツールになるのではないでしょうか。
自分はコンサルタントでして、これまでにたくさんの資料を作ってきてスキルを磨いてきたつもりだったので、AIポン出しでここまでのものが出てきてしまうと、正直、人生について考えさせられちゃいますね。
この記事では、Napkinを使ってどういう資料ができたのか共有したいと思います。

ポストモーテムの勉強会をしたいなと思っていたので、まずはChatGPTで資料の骨子を出力し、それをNapkinに入力してみました。それで得られたのが、以下の資料です。

スライド1: タイトルスライド

タイトル: ポストモーテムの教科書
副題: SREにおける学びと改善のための実践ガイド
講師名、日付

スライド2: イントロダクション

目的: ポストモーテムの重要性を理解し、実践に必要な知識とスキルを習得する
内容の概要: SREとポストモーテムの基本、具体的な実施方法、文化としての定着法
目標: 受講後すぐにポストモーテムを導入し、継続的な改善サイクルを実現できる

スライド3: SREとは

定義: SRE（Site Reliability Engineering）は、システムの信頼性を高めるために開発と運用
を融合するエンジニアリング手法
SREの役割:
インシデント管理: 障害の早期発見と迅速な対応
信頼性の向上: SLO（Service Level Objective）達成のための継続的な改善
自動化の推進: 手作業の排除による運用効率化
SREのゴール: 信頼性を犠牲にせず、開発のスピードを維持し、継続的なサービス改善を実現

スライド4: ポストモーテムとは

ポストモーテムの定義: インシデント発生後に行う振り返り。原因分析と再発防止のため
の具体的な改善策を策定するプロセス
目的:
問題を再発防止につなげる
チーム全体で学び、次に活かす
システムとプロセスを継続的に進化させる
文化的要素: ブレームレス（責任追及をしない）で、建設的な学びの場を提供する

スライド5: 顧客向け障害報告書とポストモーテムの違い

顧客向け障害報告書:
目的: 障害が発生した事実とその対応を説明し、顧客への影響を報告する
フォーカス: 顧客への安心感の提供と事実報告
内容: インシデント概要、影響範囲、初期対応、復旧策
ポストモーテム:
目的: 根本原因を分析し、再発防止策を策定し、学びを共有する
フォーカス: 内部改善とプロセスの進化
内容: 詳細な原因分析、具体的な改善策の策定、チームでの学びの共有

スライド6: ポストモーテムと「なぜなぜ分析」の違い

なぜなぜ分析:
目的: 問題の根本原因を特定する
フォーカス: 問題の核心に到達すること
手法: 「なぜ?」を繰り返して原因を掘り下げる
ポストモーテム:
目的: 原因特定、改善策の実行、学びの共有を通じた継続的改善
フォーカス: 問題解決と次回への学びの反映
手法: なぜなぜ分析＋改善策策定＋学びの共有

スライド7: ポストモーテムの価値

学びの場の提供:
失敗からの学び: エラーや障害は単なる失敗でなく、学習機会
知識の共有: ポストモーテムを通じて得た知見をチーム全体で共有
継続的改善の推進:
プロセスの進化: ポストモーテムは単発ではなく、継続的なプロセス改善の一部
システムの信頼性向上: 同じ問題の再発を防ぎ、システムの進化を促す
心理的安全性の確保:
ブレームレス・カルチャー: 責任を追及せず、プロセスとシステムに焦点を当てる
オープンな議論: 問題を隠さず、率直に話し合える環境を作る

スライド8: ポストモーテム実施の第一歩

小さく始める:
最初のステップ: 小規模なインシデントから始める
シンプルなテンプレートの使用:
例: インシデント概要、タイムライン、影響範囲、原因分析、改善策
迅速な計画と実施:
タイミング: インシデント発生後、1週間以内に実施する
関係者の招集: 関与したメンバーと関連部門の代表者を集める

スライド9: ポストモーテムの具体的実施手順

インシデントの概要を記述:

ポイント: 客観的に事実を記録し、感情的な要素は排除
記述例: 「2024年9月1日、APIがダウンし、1,000ユーザーに影響」

タイムラインの作成:

目的: 発生から解決までの対応を時系列で記録し、改善点を見つける
記入例: 「10:00 障害発生、10:05 アラート通知、10:20 原因特定」

影響範囲の評価:

方法: 売上への影響、ユーザー体験への影響、システム全体への影響を具体的に評価
例: 「取引が500件失敗し、売上に20万円の影響」

スライド10: 根本原因の特定方法

5 Whys（なぜを5回問う）:
手法: 「なぜ?」を繰り返して根本原因に到達
例: 「なぜAPIがダウンしたのか? → サーバーが応答しなかった。なぜサーバーが応答し
なかったのか? → 高負荷が原因」
魚骨図の作成:
使い方: 原因をカテゴリ別に整理し、多角的な分析を行う
例: 人的要因、技術的要因、プロセスの欠陥を視覚化

スライド11: 改善アクションの策定と実行

具体的で実行可能な改善策:
策定方法: 抽象的な提案ではなく、具体的なアクションと実行計画を設定
例: 「アラート設定の見直し」「監視システムの自動化」「ドキュメントの更新」
担当者と期限の設定:
実行管理: 誰がいつまでに何を行うかを明確にし、フォローアップを実施
進捗確認: 定期的なミーティングやダッシュボードで実行状況を確認

スライド12: 学びの共有とフォローアップ

チーム全体での学びの共有:
共有方法: ポストモーテム報告書を共有フォルダに保存し、全員がアクセスできるように
する
振り返り: 改善策の進捗を定期的に確認し、次回のポストモーテムに反映
継続的なフィードバック:
フィードバックループの確立: 改善策の効果を定期的に評価し、プロセス自体も見直し続

スライド13: 主体性と自律的な改善の重要性

やらされ感を排除する:
自律性の促進: 改善策はメンバー自身が主体的に考え、実行することが重要
小さな成功を積み重ねる: 日々の小さな改善が大きな変革につながる
主体的な行動を促すための仕組み:
インセンティブ制度: 改善提案や実行に対して評価や報奨を導入
成功事例の共有: 成功した改善策を全体で共有し、参考にできる環境を整える

スライド14: 文化としてのポストモーテム定着法

ブレームレス・カルチャーの醸成:
トレーニングとワークショップ: 心理的安全性の重要性を学ぶ場を設ける
リーダーシップの重要性: リーダーが率先して学びと改善を推進する
学びを見える化する仕組み:
ダッシュボードの導入: 改善策の進捗や成功事例を可視化
共有とレビュー: ポストモーテムの成果を定期的に見直し、フィードバックを反映

スライド15: リーダーシップと文化の醸成

リーダーの模範行動:
率先して学ぶ姿勢を示す: リーダー自らがポストモーテムに参加し、オープンな姿勢を示
す- 学びと改善を奨励する: チーム全体での学びと改善を積極的にサポート
学びの推進:
継続的なフィードバックと調整: 改善策の進捗確認と必要な調整をリーダーがリード
評価と表彰: 成果を挙げたメンバーを評価し、学びと改善の重要性を強調

スライド16: ポストモーテムがもたらす具体的成果

システムの信頼性向上:
障害の再発を防ぎ、安定したサービスを提供
チームの成長とスキルアップ:
継続的な学びがメンバーのスキル向上を促し、チーム全体のパフォーマンスが向上
組織の進化:
ポストモーテムが日常業務に組み込まれ、組織全体の改善サイクルが確立

スライド17: 成功事例の共有

実際の成功事例:
例1: 小さなアラート改善が大規模障害を未然に防いだケース
例2: 改善策の自動化で運用コストを削減
成功事例からの学び:
成功した事例をテンプレートとして他のチームに展開し、全体の改善に活かす

スライド18: よくある失敗とその対策

形骸化のリスク:
ポストモーテムが形式的になり、実質的な改善につながらない
対策:
ファシリテーターの育成: 建設的な議論を促進し、改善策が実行される環境を作る
チェックリストの活用: 改善策の実行状況を定期的に確認し、形骸化を防ぐ

スライド19: まとめとQ&A

まとめ: ポストモーテムは、学びと改善を通じてシステムと組織を進化させるプロセス
次のステップ: 小さな成功を積み重ね、文化として定着させることから始める
質問の受付: 実践に向けた疑問や課題を共有し、次の行動に向けてアドバイスを提供

この入門資料は、ポストモーテムが単なる「反省会」ではなく、組織全体の成長とシステムの信頼性向上を実現するための包括的なプロセスであることを強調しています。学びの重要性、心理的安全性、主体性、自律的な改善、そしてこれらを組織文化として醸成するための具体的な手法を豊かに解説し、受講者がポストモーテムを実際に導入し、定着させるための具体的なガイドとして活用できる内容に仕上げています。

Discussion