午前2時10分にアラートが発報されます。エンジニアが構成変更をプッシュすると、チェックアウトサービスがエラーを返し始め、オンコールリーダーが40分後にロールバックします。レビュー会議で最初に問われるのは「誰が変更をプッシュしたのか？」です。数分後には、午前2時の1人の判断についての議論になり、カナリアリリースなしで変更が本番環境に到達できた理由、アラートがページングされるまでに時間がかかった理由、ランブックが最新ではなかった理由など、誰も疑問を呈しません。
これはあくまで例示シナリオであり、実際の顧客事例ではありません。しかし、実際に起こりうるため、よく知られている事例です。最後に行動した人物にばかり焦点を当てたインシデントレビューは、整然としたストーリーにはなりますが、そこから得られる教訓はほとんどありません。
このガイドは、インシデントの証拠を分析し、テスト可能な改善策を合意する能力を向上させたいと考えているエンジニアリングマネージャーやイネーブルメントリーダーを対象としています。スキルギャップをその背景にある状況から切り離す方法、実践方法を設計する方法、事後検討を行う方法、そしてレビューが効果を発揮しているかどうかを測定する方法について解説しています。
「非難されるべきでない」とはどういう意味か、またどういう意味ではないか
Googleのサイト信頼性エンジニアリングに関する書籍では、事後検証が真に非難のないものであるためには、個人やチームの悪質な行動や不適切な行動を非難することなく、インシデントの根本原因を特定することに焦点を当てる必要があると明言している。また、その根底にある前提として、関係者全員が善意で行動し、入手した情報に基づいて正しい行動をとったと述べている。GoogleのSRE書籍「ポストモーテムカルチャー：失敗から学ぶ」.)
非難しないということは、結果が伴わないという意味ではありません。同じ章では、事後検証は優先順位と担当者を定めたアクションアイテムで締めくくられるべきだと述べています。非難しない調査でも説明責任は必要ですが、その責任は「誰が原因を作ったのか」から「誰が、いつまでにシステムをより安全にするのか」へと移行します。レビューで後半部分を省略してしまうと、単なる楽しい会話になってしまい、学習プロセスにはなりません。
1. 行動とその状況を特定する
変えたい具体的な行動から始めましょう。「インシデントレビューでは、最後に行動した人に焦点を当てている」というのは観察可能な行動です。「私たちの組織文化は、責任転嫁が横行している」というのは観察不可能です。
次に、そもそもこれがスキルの問題なのかどうかを考えてみましょう。トレーニングは、パフォーマンス低下の原因の一部しか改善できません。何かを構築する前に、次の3つの可能性を区別してください。
- 欠けているスキル。 審査員は、タイムラインの作成方法、引き金となる要因と寄与要因の区別方法、あるいは「当時、この行動が妥当に見えたのはなぜか？」という問いかけ方を知らない。
- インセンティブ。 レビューはパフォーマンスに関する話し合いに反映されるため、人々は自分を守るためにアカウントの設定を調整する。
- 権威の勾配と過去の反応。 前四半期に懸念を表明した際に「ネガティブなことを言うのはやめろ」と言われた若手エンジニアは、どれほど訓練を受けていても、今回の会議では懸念を表明しないだろう。
最初の項目だけがトレーニングの問題です。残りの2つは環境要因です。スキルを訓練するだけで環境要因を放置すると、職場で罰せられるような行動を人々は繰り返してしまうでしょう。原因に関する現在の見解は仮説として捉え、プログラムに着手する前に、エンジニアとの会話や最近のレビュー文書の確認などを通じて検証してください。
2. 実践のための運用条件を設定する
職場が対応してくれる場合にのみ、練習は引き継がれます。練習を始める前に、評価担当者と以下の点について合意しておきましょう。
- 承認された職務内容。 ファシリテーターは誰で、タイムラインは誰が作成し、フォローアップの責任者は誰なのか？役割を明確にすることで、ファシリテーターが権限を勝手に決めてしまうことを防ぎます。
- リーダーは懸念事項をどのように受け止めるか。 エンジニアが「デプロイツールのおかげでカナリアリリースをスキップできました」と言った場合、ディレクターは次にどうすべきでしょうか？ 事前に対応策を決めておきましょう。例えば、感謝の意を伝え、要因として記録し、具体的な対応策を割り当てるなどです。
- 上司の対応。 スタッフの訓練には、それに合った上司の対応が必要です。エンジニアに評価の際に発言するよう訓練しても、上司が依然として「誰の責任だったのか？」と尋ねるようでは、訓練の効果は得られません。
管理者向けの評価プロセスに関する簡単な説明は、参加者向けの研修と同様に重要です。評価文書が業績管理においてどのように使用されるか、また使用されないかを簡潔に説明してください。
3. 行動に基づいた学習プロセスを設計する
カーネギーメロン大学エバリーセンターの学習目標に関するガイダンスは、目標、評価、指導戦略は互いに整合しているべきであるという有益な点を指摘している（エバリーセンター、学習目標これは設計上の指針であり、特定のツールや成果に関する証拠ではありませんが、このプログラムにとっては良いテストになります。目的が証拠を分析し、検証可能な改善点に合意することであれば、想起に関する質問だけでは評価になりません。
ブルームの分類法は、課題の認知的要求（分析、評価、創造）を説明する上で役立ちます。これは、課題が人に何を求めているかを説明するものであり、なぜその課題に取り組むのか、あるいは取り組まないのかを説明するものではないため、動機付けの診断には使用しないでください。
実行可能な旅は3つの段階から成る。
| ステージ | 学習者の行動 | 出荷 |
|---|---|---|
| 準備 | インシデントレビューポリシーと簡単な用語集（トリガー、要因、軽減策、対応項目）をお読みください。簡単な診断で前提条件を確認します。 | 自分のペースで学習できます。復習チェックは前提条件の確認のみを行い、スキルの復習は行いません。 |
| 専門 | 事前に準備されたインシデント事例を分析し、検証可能な改善策を合意する。選択肢の中から選ぶのではなく、論理的な回答が求められる。 | 相互作用型またはファシリテーター付きの事例演習。要因分析の質とフォローアップについてフィードバックを提供する。 |
| 確認と転送 | 曖昧な選択肢を一つ取り上げて議論した後、新しい事例に取り組むか、指導を受けながら実際の事例をレビューしてください。 | 対面でのコーチング、または非同期のレビュー。スキルを職場で実際に使用した後に、そのスキルが定着しているかどうかを確認する。 |
事例は現実的なものにし、経験豊富なエンジニアに検証してもらいましょう。技術的に間違った事例は、レビュー担当者に演習への不信感を抱かせることになります。
4. シナリオを実際に実行し、振り返りを行う
以下に、午前02時10分のシナリオを用いた練習セッションの例を示します。証拠資料には、デプロイログ、アラートタイムライン、ページングポリシー、プルリクエスト、ランブックが含まれていますが、これらはすべて架空のものです。
参加者への指示。 「エンジニアがそのタイミングで変更を推進した理由を説明してください。根拠となる証拠を挙げてください。確信を持つために、他にどのような情報や支援が必要か教えてください。」
不十分な対応の例としては、「エンジニアはステージングを確認すべきだった」というものがある。これは人名を挙げるだけで、具体的な根拠は示さず、改善策も提案しない。
より適切な対応としては、次のようなものが考えられます。「デプロイログを見ると、ツールでカナリアステップがオプションになっているため、変更が直接デプロイされたことがわかります。プルリクエストにはレビュー担当者が1名おり、20分後に承認されました。アラートのしきい値が平均5分に設定されていたため、エラー発生から18分後にページが起動しました。今月、カナリアステップをスキップした変更が他にいくつあるか、また、オンコールエンジニアにこのステップがスキップ可能であることが伝えられたことがあるかどうかを知りたいです。提案するアクション：このサービスティアでカナリアステップを必須にする、担当者：プラットフォームチーム、確認事項：ステージング環境でカナリアステップをスキップしたデプロイを試行し、ブロックされることを確認する。アラートウィンドウを短縮する、担当者：オンコールリーダー、確認事項：先週のエラーを新しいしきい値で再現する。」
何が優れているかに注目してください。それは証拠に基づき、制約と不確実性を明確にし、検証可能な行動で締めくくっています。
それでは、振り返りの時間です。ただ点数をつけるだけではなく、以下の点について質問してください。
- 証拠は何を裏付けており、あなたは何を仮定しましたか？
- チームが実際に権限を持つ行動はどれですか？
- 次の実際の評価で、この行動を再現しやすくするにはどうすればよいでしょうか？逆に、再現しにくくするにはどうすればよいでしょうか？
3つ目の質問が最も重要です。これは、第2節で述べた条件を浮き彫りにします。もし3人の参加者が「上司が誰がやったのか尋ねるだろう」と答えた場合、トレーニングでは取り除けない制約が見つかったことになります。
5. 行動を測定し、フォローアップする
重要なのは、学習者がインシデントの証拠を分析し、検証可能な改善策に合意できることを示す証拠は何か、という点です。以下に、出発点となる評価基準を示します。これは、経験豊富なエンジニアが調整するための提案であり、検証済みの準備基準ではありません。
| 基準 | 観察可能な証拠 | 0 | 1 | 2 |
|---|---|---|---|---|
| タスクの実行 | 証拠を分析し、改善策に合意する。行動とその根拠となる証拠を記録する。 | 欠席または支持なし | 一部省略あり | 合意された基準に照らして完全かつ正当化されている |
| 推論 | 制約、代替案、不確実性について説明する。寄与要因は最後の行動にとどまらない。 | 欠席または支持なし | 一部省略あり | 完全かつ正当な |
| 境界 | 承認された手順に従い、情報や権限が不足している場合は助けを求める。 | 欠席または支持なし | 一部省略あり | 完全かつ正当な |
重大なエラーは個別に定義する必要があります。例えば、原因となった人物を特定したり、担当者のいない対策を提案したりするなどです。高い合計スコアは、重大な失敗を隠蔽するものであってはなりません。
測定自体について：
- 寄与因子分析の質。 プログラム実施前に書かれたレビューと実施後に書かれたレビューを、どちらがプログラム実施前でどちらが実施後かを知らない人が同じ評価基準で採点し、比較する。実際の事例だけでなく、未公開のフォローアップ事例も活用する。
- フォロースルー。 提起されたすべてのアクション項目のうち、担当者、テスト、完了の条件を満たしているアクション項目の割合を数えてください。分母と期間を明記してください。
- 観察結果とプロセス変更を関連付ける。 実際のレビューに参加してみましょう。その後、アクションアイテムがどうなったかを確認してください。
報告件数には注意が必要です。プログラム実施後に懸念事項やヒヤリハットの報告件数が増えた場合、それは安全性の向上、信頼関係の向上、あるいは新しいツールによって報告が容易になったことを意味する可能性があります。逆に報告件数が少ない場合は、問題の発生件数が減ったか、あるいは報告意欲が低下したことを意味するかもしれません。トレーニングの効果を安易に判断する前に、同じ期間に何が変化したのかを検討し、測定していない効果量を主張することは避けてください。
上記のエバリーの指針は、連携の枠組みを示すものであり、このアプローチが事故の減少につながるという証明ではありません。独自のベースラインデータと追跡調査データを保持し、それらを地域における証拠として扱ってください。
スキルが向上した後でも残る可能性のある制約は何か
スポンサーに対しては、以下の点について正直に伝えましょう。
- レビュー文書は、依然として業績評価の判断材料となる可能性がある。
- 納期に追われるチームは、コストがかかるものの理にかなった行動を省略してしまうことがある。
- 境界線の所有権が不明確なため、チーム間の連携が滞る可能性がある。
- ベテランエンジニアが依然として議論を主導する可能性がある。
より高度な分析を行っても、これらの問題は解消されません。これらの問題については、別途プロセス変更を計画してください。
AhaSlidesで実践してみる
AhaSlidesは、適応型学習、インタラクティブ学習、ライブ配信と自己ペース配信の切り替えをサポートしています。このプロセスでは、自己ペースでの準備ステップ、グループディスカッションの前に全員が分析に取り組むための自由回答形式の質問を含むライブまたはファシリテーター付きのケースセッション、そしてセッション後のフォローアップタスクなどが含まれます。特定のオーサリング、スコアリング、レポート機能は、実際に使用する前に、ご自身のケースでデモンストレーションを行い、必ず確認してください。また、AI、シミュレーター、インシデントツールとの統合に関わる機能は、実際にデモンストレーションを見るまでは外部機能として扱う必要があります。
次のステップ： 上記の評価基準を参考に、上級エンジニアの一人と調整し、使用するケースを作成してください。この学習過程をライブ形式で自分のペースで進める方法をご覧になりたい場合は、 AhaSlidesのワークフローデモを予約する 事例と評価基準案が作成されたら。
