ストーリー
ミッション概要
| 項目 | 内容 |
|---|---|
| 演習タイトル | 失敗学習文化設計書 |
| 想定時間 | 90分 |
| 成果物 | 失敗学習文化設計書(現状分析 + ブレイムレス導入計画 + ポストモーテム制度 + 失敗共有の仕組み) |
| 対象組織 | ネクストシステム株式会社(Step 1から継続) |
前提条件
失敗対応の現状
| 項目 | 現状 |
|---|---|
| インシデント対応フロー | 障害発生 → 犯人特定 → 始末書提出 → 賞与減額 |
| 障害報告書 | 「原因者」の氏名を記載する様式 |
| ポストモーテム | 実施したことがない |
| 失敗共有 | 「恥」として扱われ、共有されない |
| 同一障害の再発率 | 40%(過去2年間のデータ) |
| 平均報告時間 | 障害認知から報告まで平均45分(隠そうとする傾向) |
| 直近1年のインシデント | 重大障害12件、軽微な障害48件、ニアミス報告ゼロ件 |
追加情報
| 項目 | 詳細 |
|---|---|
| 始末書のペナルティ | 年2回の始末書で賞与10%減額、3回で昇進見送り |
| 管理職の認識 | 「罰がないと緊張感がなくなる」が多数派 |
| 若手の声 | 「障害を起こしたら自分のキャリアが終わる」 |
| 中途入社者の声 | 「前職ではポストモーテムが当たり前だったのに…」 |
| 経営層の関心事 | 同一障害の再発によるクライアントへの信頼低下 |
Mission 1: 現状分析とブレイムレス移行計画
要件
- ブレイムカルチャーのコスト算出(現状の金銭的・非金銭的コスト)
- ブレイムレスへの移行ロードマップ(6ヶ月間)
- 管理職の意識変革プログラム
解答例
ブレイムカルチャーのコスト
| コスト項目 | 算出根拠 | 年間コスト |
|---|---|---|
| 同一障害の再発 | 再発率40% x 重大障害12件 x 復旧1件あたり500万円 | 約2,400万円 |
| 報告遅延による被害拡大 | 平均45分の遅延 x 障害60件 x 分あたり影響 | 約800万円 |
| 離職コスト | 「キャリアが終わる」と感じた若手の離職増分 | 約3,000万円 |
| ニアミスからの学び喪失 | 予防できたはずの障害(推定20件) | 約1,000万円 |
| 合計 | 約7,200万円/年 |
6ヶ月移行ロードマップ
| 月 | フェーズ | アクション |
|---|---|---|
| 1 | 宣言と教育 | 経営層がブレイムレスを宣言、管理職向けワークショップ |
| 2 | 制度見直し | 始末書制度の廃止、新インシデント対応フロー策定 |
| 3 | パイロット | 3チームでブレイムレスポストモーテムを初実施 |
| 4 | 拡大 | 10チームに展開、Failure Fridayを開始 |
| 5 | 全社展開 | 全チームで新フロー運用、ニアミス報告制度開始 |
| 6 | 定着 | 効果測定、制度の調整、四半期失敗レビュー開始 |
管理職意識変革プログラム
| 週 | テーマ | 内容 |
|---|---|---|
| 1 | ブレイムレスの理論 | スイスチーズモデル、ジャストカルチャーの講義 |
| 2 | 先行事例の学習 | Google、Etsy、航空業界の事例研究 |
| 3 | ロールプレイ | 障害発生時の対応をブレイムレスで実践 |
| 4 | 自分の経験の振り返り | 過去に自分が受けた非難の経験を共有 |
Mission 2: ポストモーテム制度の設計
要件
- ポストモーテムのテンプレートと運営ルール
- 実施基準(どのレベルのインシデントで実施するか)
- アクションアイテムの追跡と完了保証の仕組み
解答例
実施基準
| レベル | 基準 | ポストモーテム | 共有範囲 |
|---|---|---|---|
| P0(重大) | ユーザー影響1時間以上 or データ損失 | 必須、48時間以内 | 全社 |
| P1(中程度) | ユーザー影響30分以上 | 必須、1週間以内 | 部門 |
| P2(軽微) | ユーザー影響30分未満 | 推奨、チーム判断 | チーム |
| ニアミス | 障害に至らなかったがリスクあり | 任意、簡易版 | チーム |
運営ルール
| ルール | 内容 |
|---|---|
| ブレイムレス原則 | 個人名を原因として記載しない。「〜のプロセスが」「〜の仕組みが」で表現 |
| 48時間ルール | 重大インシデントは48時間以内にポストモーテムミーティングを開催 |
| 全社公開 | ポストモーテム文書はConfluenceで全社に公開 |
| アクション必須 | 最低1つの具体的なアクションアイテムを決定 |
| フォローアップ | アクションアイテムは月次で進捗を追跡 |
アクションアイテム追跡の仕組み
| 仕組み | 内容 |
|---|---|
| Jiraチケット化 | アクションアイテムをJiraチケットとして自動起票 |
| 月次レビュー | 改善推進委員が全アクションアイテムの進捗を月次でレビュー |
| ダッシュボード | 未完了アクションをリアルタイム表示 |
| エスカレーション | 期限超過のアクションは自動で上長にエスカレーション |
| 完了報告 | アクション完了時にポストモーテム文書に追記 |
Mission 3: 失敗共有の仕組みと効果測定
要件
- 失敗共有の3レイヤー設計(リアルタイム、定期イベント、アーカイブ)
- 失敗パターンカタログの初期設計(最低5パターン)
- 効果測定のKPIと目標値
解答例
失敗共有の3レイヤー
| レイヤー | 仕組み | 開始時期 | 担当 |
|---|---|---|---|
| リアルタイム | Slack #incident チャンネル | 1ヶ月目 | SREチーム |
| リアルタイム | ニアミス報告Bot | 3ヶ月目 | SREチーム |
| 定期イベント | Failure Friday(隔週) | 2ヶ月目 | 持ち回り |
| 定期イベント | 月次ポストモーテム共有会 | 3ヶ月目 | 改善推進委員 |
| 定期イベント | 四半期失敗レビュー | 4ヶ月目 | VPoE |
| アーカイブ | ポストモーテムアーカイブ(Confluence) | 2ヶ月目 | SREチーム |
| アーカイブ | 失敗パターンカタログ | 4ヶ月目 | テックリード |
失敗パターンカタログ(初期5パターン)
| パターン名 | 分類 | 過去の発生数 | 防御策 |
|---|---|---|---|
| 本番DB直接操作の罠 | 運用 | 年3件 | 本番アクセスにピアレビューを必須化 |
| 依存サービスの暗黙の前提 | アーキテクチャ | 年4件 | 依存関係のヘルスチェック自動化 |
| リリース前の負荷テスト忘れ | デプロイ | 年2件 | CIパイプラインに負荷テストを組み込み |
| 深夜メンテナンスの疲労エラー | 運用 | 年3件 | メンテナンス時間の日中移行、ペア作業必須化 |
| 設定ファイルの環境差異 | 設定管理 | 年5件 | 環境差異のCI自動チェック |
KPIと目標値
| 指標 | 現状 | 3ヶ月目標 | 6ヶ月目標 |
|---|---|---|---|
| インシデント報告時間 | 平均45分 | 15分以内 | 5分以内 |
| ポストモーテム実施率(P0/P1) | 0% | 80% | 100% |
| アクションアイテム完了率 | N/A | 70% | 90% |
| 同一原因再発率 | 40% | 25% | 10% |
| ニアミス報告数 | 0件/月 | 10件/月 | 30件/月 |
| 「失敗しても評価に悪影響はない」スコア | 1.8/5.0 | 2.5/5.0 | 3.5/5.0 |
| Failure Friday参加率 | N/A | 30% | 50% |
達成度チェック
| 観点 | 達成基準 |
|---|---|
| コスト分析 | ブレイムカルチャーのコストが定量的に算出されている |
| 移行計画 | 段階的かつ実行可能な6ヶ月のロードマップがある |
| 管理職変革 | 管理職の意識を変えるプログラムが設計されている |
| ポストモーテム | テンプレート、実施基準、運営ルールが具体的 |
| アクション追跡 | 「決めたけどやらない」を防ぐ仕組みがある |
| 失敗共有 | 3レイヤーの仕組みが設計されている |
| パターンカタログ | 実際のデータに基づいた初期パターンが定義されている |
| 効果測定 | 定量的なKPIと段階的な目標値が設定されている |
推定所要時間: 90分