午前I問題
組織における失敗事例の分析と再発防止のあり方に関する記述として、最も適切なものはどれか。
ア）失敗の分析においては、原因となった個人の責任を明確にし、処分を決定することが最優先の目的である。
イ）失敗の分析では、個人の責任追及よりもプロセスやシステムの構造的な問題を明らかにすることが、再発防止の観点から重要である。
ウ）一度発生した失敗について分析・記録を行うことは、同じ担当者に心理的負担を与えるだけであり、実施すべきでない。
エ）失敗の分析結果は、関係者間で共有せず個別に保管することで、組織内の混乱を防ぐべきである。
午前I の解答・解説を見る
正解： イ
解説：
- ア）不正解。個人の処分を最優先の目的とすると、当事者が事実を隠蔽するインセンティブが生まれ、正確な原因究明を妨げる。
- イ）正解。構造的・プロセス的な問題（手順の欠如、ツールの不備、権限設計の誤り等）に焦点を当てることで、再発防止に直結する改善が可能になる。
- ウ）不正解。適切に設計された分析プロセス（非難を伴わない形式）は学習機会として組織の成熟度向上に寄与する。
- エ）不正解。分析結果を関係者間で共有し組織全体の教訓とすることが再発防止・ナレッジ蓄積の観点から重要である。
午前II問題
インシデント対応後の事後レビュー（ポストモーテム）に関する記述として、適切なものはどれか。
ア）Blameless（非難なし）ポストモーテムとは、インシデントの原因究明自体を行わず、関係者への配慮のみを目的とする活動である。
イ）Blamelessポストモーテムでは、「誰が間違えたか」ではなく「なぜそのような判断・行動が起こり得たか（システムや手順の問題）」に焦点を当てることで、対応者が率直に事実を報告しやすい環境をつくる。
ウ）根本原因分析（Root Cause Analysis）では、表面的な直接原因を1つ特定した時点で分析を終了し、それ以上の深掘りは不要である。
エ）ポストモーテムはインシデントの再発防止策を検討する場ではなく、対応チームの労をねぎらう場として位置づけられる。
午前II の解答・解説を見る
正解： イ
解説：
- ア）不正解。Blamelessポストモーテムは原因究明を放棄するものではなく、個人への非難を避けながら事実に基づいた原因究明を行う手法である。
- イ）正解。個人の責任追及ではなく「なぜその行動が合理的に見えたか」というシステム的要因（手順の曖昧さ、監視体制の不備等）に焦点を当てることで、心理的安全性を確保しつつ深い原因究明を可能にする。
- ウ）不正解。根本原因分析では「なぜなぜ分析（5 Whys）」等の手法を用い、直接原因のさらに背後にある構造的・組織的要因まで掘り下げることが求められる。
- エ）不正解。ポストモーテムの主目的は根本原因の特定と具体的な再発防止策（アクションアイテム）の策定であり、労いはその一部に過ぎない。
午後問題
N社では、顧客管理システムへの不正アクセスインシデントが発生し、対応完了後にCSIRTがポストモーテムを実施した。調査の結果、以下の経緯が判明した。
発端: 開発担当者Oが、検証環境用に発行したAPIキーを誤って本番環境のソースコードリポジトリに
コミットし、そのリポジトリが一時的に公開設定になっていたため、外部の第三者に
APIキーを取得され、顧客データへの不正アクセスが行われた。
追加調査で判明した事実:
・APIキーのコミット前チェック（シークレットスキャン）は導入されていなかった。
・リポジトリの公開設定は、別プロジェクトのテンプレートをコピーした際にデフォルトのまま
見落とされていた。
・APIキーには本来不要な「全顧客データの読み取り権限」が付与されていた。
・O氏は過去にも同様のヒヤリハット（軽微な設定ミス）を起こしていたが、正式な報告や
チーム内共有はされていなかった。CSIRTのリーダーであるP氏は、Blamelessの原則に基づき、O氏個人の責任を追及するのではなく、構造的な問題を特定する方針でレビューを進めることにした。
設問1
なぜweb記事は「Blameless（非難なし）」の原則に基づいてポストモーテムを実施することが、O氏個人を処罰する場合と比較して、再発防止の観点から効果的といえるか。過去のヒヤリハットが共有されなかった事実を踏まえて70字程度で述べよ。
設問1の解答・解説を見る
正解例： 個人を処罰する運用では、O氏のようにミスを起こした担当者が報告・共有を避けるようになり、過去のヒヤリハットのように問題の兆候が組織に共有されず、同種のリスクが放置されるため。（約88字）
解説： Blamelessの原則の核心は、処罰への恐れが「事実の隠蔽・報告回避」という二次的なリスクを生むことを防ぐ点にある。本事例では、まさに過去のヒヤリハットが共有されなかったことが、シークレットスキャン未導入等の構造的欠陥を放置する結果につながっており、非難文化の弊害を象徴している。
採点基準（計15点）：
| 採点項目 | キーワード | 配点 |
|---|---|---|
| 処罰が報告・共有の回避を招くという因果関係の説明 | 処罰への恐れ、報告回避、隠蔽 | 8点 |
| 過去のヒヤリハット未共有という事実との関連付け | ヒヤリハット、兆候の放置 | 5点 |
| 再発防止の効果という観点での結論 | 再発防止 | 2点 |
設問2
本インシデントの根本原因分析（Root Cause Analysis）を踏まえ、構造的な再発防止策を3つ、それぞれ異なる観点から具体的に述べよ。
設問2の解答・解説を見る
正解例：
- 技術的統制： ソースコードリポジトリへのコミット時にAPIキー等のシークレットを自動検出してブロックするシークレットスキャンツールをCI/CDパイプラインに導入する。
- 設定管理： リポジトリのテンプレートをコピーする際に公開/非公開設定がデフォルトで「非公開」になるようテンプレートそのものを見直し、公開設定への変更時は承認を必須化する。
- 権限設計： APIキーには業務上必要な最小限の権限のみを付与する最小権限の原則（Least Privilege）を徹底し、用途別にスコープを分離したキー発行ポリシーを整備する。
解説： 根本原因分析では「なぜなぜ分析」により表面的な原因（O氏のコミットミス）の背後にある構造的要因（シークレットスキャン未導入・テンプレート設計の不備・過剰な権限付与）まで掘り下げ、それぞれに対する技術的・運用的統制を組み合わせて再発防止策とすることが重要である。個人の注意力に依存しない仕組み化がポイントとなる。
採点基準（計15点）：
| 採点項目 | キーワード | 配点 |
|---|---|---|
| シークレットスキャン等の技術的統制の提示 | シークレットスキャン、CI/CD | 5点 |
| テンプレート・公開設定の見直しの提示 | デフォルト非公開、承認フロー | 5点 |
| 最小権限の原則に基づく権限設計の提示 | 最小権限、スコープ分離 | 5点 |
重要キーワード
| 用語 | 説明 |
|---|---|
| ポストモーテム | インシデント対応完了後に実施する事後レビュー。根本原因の特定と再発防止策の策定を目的とする |
| Blameless（非難なし）文化 | 個人の処罰ではなく構造的問題の究明に焦点を当て、心理的安全性を確保しながら事実を明らかにする姿勢 |
| 根本原因分析（RCA） | 直接原因の背後にある構造的・組織的要因まで掘り下げて特定する分析手法。「なぜなぜ分析」等が用いられる |
| ヒヤリハット | 実害には至らなかったが、事故につながる可能性があった軽微な事象。共有・蓄積が予防に有効 |
| シークレットスキャン | ソースコードへのAPIキー等の機密情報の混入をコミット前後に自動検出する仕組み |
| 最小権限の原則 | アカウントやAPIキーに業務上必要な最小限の権限のみを付与する設計原則 |
まとめ
- 午前I視点： 失敗分析の目的は個人の処罰ではなく構造的問題の特定であり、それが再発防止に資するという一般原則を理解する
- 午前II視点： Blamelessポストモーテムの狙いは「率直な事実報告を促す環境づくり」にあり、根本原因分析は表面的原因で終わらせず深掘りする必要がある点を押さえる
- 午後視点： 処罰文化が報告回避・隠蔽を招くという因果関係を論述し、技術的統制・設定管理・権限設計など複数の観点から構造的な再発防止策を提示する力が問われる