リリース前のプレモーテム
概要
私たちは、失敗が起きた後にそこから学ぶことを得意としています。私たちのインシデントレビューは充実しています。誰かを責めず、文書に残し、是正措置を担当者付きの Issue として追跡します。問題は、こうした失敗に気付くのがお客様であることが多く、ときには私たち自身が気付くよりも早いことです。
運用の観点では、ソフトウェア開発ライフサイクルの前半に向けられる注意ははるかに少なくなっています。これまで私たちに欠けていたのは、リリース日前に、システムを知る人たちが、悲観的に考えてもよいという共通認識のもと、密かに心配していることを声に出す、意図的で集中できる時間です。プロジェクトが失敗する場合、ほとんどはチームの誰かがすでに分かっていたものです。目的は、そうしたリスクを前もって、安心して素早く明らかにできるようにすることです。
プレモーテムは、それを集めるための 45 分間です。
プレモーテムは、口にされていないリスクを明らかにするだけでなく、リーダーシップにおける難しい課題の 1 つ、組織全体で意思決定とその質を拡大することにも役立ちます。チームメンバーは、多様な失敗のパターンを認識し、自分自身が経験しなくても、他の人が見てきた苦い経験から学べる場を得られます。十分な頻度で実施すると、失敗シナリオへの対処を開発ライフサイクルの早い段階へ移す力が身に付きます。
Data Engineering and Monetizationのチームはこの取り組みを活用しており、GitLab のどのチームでも利用できます。このページは、チームが利用できる取り組みを説明するものであり、必ず従うべき手順ではありません。実施するかどうかは、リリースの DRI が決定します。
プレモーテムとは何か、何ではないか
考え方のすべては、1 つの逆転にあります。チームに「何がうまくいかない可能性があるか」と尋ねる代わりに、すでに起きた失敗として表現します。リリースから 8 週間後です。これは失敗しました。この場にいる全員が、失敗したことをすでに知っています。その理由を書いてください。
失敗したという確実性が、この取り組みを機能させます。「何がうまくいかない可能性があるか」と聞くと、人は計画を擁護したくなります。「すでに失敗しました。説明してください」と言えば、ためらいがなくなります。悲観的になっているのではなく、尋ねられた質問に答えているのです。
プレモーテムは、次のようなものです。
- リスク台帳ではありません。 発生可能性と影響度を掛け合わせたスコアリングは行いません。
- 設計レビューではありません。 ミーティングの結論が「別の作り方をするべきだった」では、得られる価値は限られます。
- 時制を変えたポストモーテムではありません。 ポストモーテムは、起きた 1 つの出来事を説明します。プレモーテムは、起こり得る多くの出来事を生み出します。
- フィーチャーフラグ、PREPのような準備状況レビュー、エラーバジェット、テストの代わりではありません。
実施するタイミング
分かりやすい考え方は、2 つの質問です。どちらかの答えが「はい」なら、おそらく 45 分間をかける価値があります。
- これがうまくいかなかった場合、数分で元に戻せますか？ 戻せないなら、実施候補です。
- これがうまくいかなかった場合、誰が私たちに知らせますか？ 正直な答えが自動アラートではなく、経営幹部も参加している Slack チャンネルのお客様なら、実施候補です。
GitLab では具体的に、次のような場合が当てはまる傾向があります。
- GitLab.com の規模でバックフィルに数時間かかるスキーマ変更。
- レプリケーション、ストレージ、書き込みパスに触れるもの。Orbit と Data Insights Platform の展開は、最近の最も分かりやすい例です。論理レプリケーション、WAL 蓄積のリスク、そして 1 件の障害や設定ミスがすべての利用側に影響する共有メッセージングへの依存関係があります。
- GitLab.com、GitLab Self-Managed、GitLab Dedicated の境界をまたぐもの。環境が異なり、新しく加わったエンジニアには見落としがあるかもしれません。Dedicated テナントにはメンテナンス時間帯とお客様固有の設定がありますが、GitLab.com にはありません。
- 認証または権限の処理経路に関わるもの。
- 新しい依存先、データストア、ベンダーを本番環境で初めて使用する場合。
- 外部に対して日付が確定しているもの。日付が動かせないと、終盤に分かったことに対応する余地がなくなります。それこそが、早く知りたい理由です。
- サポートとオンコールの体制が固まっていないベータから GA への移行。「誰に呼び出しが届き、その人は午前 3 時に何か対処できるのか」は、実際に最もよくある不足であり、どの準備状況チェックリストでも確実に確認できるとは限りません。
実施時期。 理想的なのは、設計が固まった後、コードが完成する前です。実装が 60 〜 70% 程度進んだ頃、または展開開始の 2 〜 3 週間前が目安です。それより早いと、まだ変わる設計について推測することになります。それより遅いと、どの指摘に対しても正直な答えは「それでもリリースする」しかありません。DRI が判断します。
実施しない場合
このセクションは、その前のセクションよりも重要です。優れた取り組みを駄目にする最も手っ取り早い方法は、あらゆる場面に適用することです。
- 変更がフラグで制御され、実際の段階的展開とテスト済みの停止スイッチがある場合。 フラグがプレモーテムの役割を果たします。30 秒で無効にできるものにミーティングを追加しないでください。停止スイッチを一度も試していないなら、それは別の問題であり、解決策はそのスイッチを試すことであって、ミーティングを開くことではありません。
- 日常的な作業。 バグ修正、依存関係の更新、ドキュメント、UI の変更、成熟した機能の 20 回目のイテレーション。チェックリストが適切なツールであり、コストもはるかに低く済みます。
- 1 人ですでにリストを書ける場合。 それならリストを書いてください。プレモーテムは、複数の人の頭の中に分散していることを明らかにするためのものです。1 人のエンジニアの既知の懸念を、正式なものと感じさせるための仕組みではありません。
実施方法
下のテンプレートを使用してください。形式を固定しているのは意図的です。
- 24 時間前に非同期で記入します。 ファシリテーターは、すでに起きた事実として書かれたシナリオを含むドキュメントを共有します。各参加者は、先に他の人の回答を読まずに、自分のセクションに自分の回答を記入します。全員が失敗のパターンと理由について、10 分間集中して黙って書くことが、この取り組みの中心的な価値です。
- 30 分間の通話を行います。 全員が順番に 1 項目ずつ読み上げ、議論はしません（15 分）。テーマ別にまとめ、それぞれのテーマについて、これが実際の問題かどうか分かる、今週できる最も低コストなことは何かを尋ねます（10 分）。DRI が最大 3 つを選びます（5 分）。
- 成果をリリースのエピックに貼り付けます。 アクションは最大 3 つで、それぞれに担当者、日付、Issue を設定します。それ以外はすべて「既知であり、受容済み」の一文にします。X が起こり得ることを認識しています。Y のため、対処しません。起きた場合は、Z を通じて把握します。
測定
プレモーテムがインシデントを防いだことは証明できません。提案できるどの指標も数字を取り繕う余地があり、ここではそうした指標はいずれも、目的とは逆に、チームに実施回数を増やすよう促してしまいます。四半期に 1 回、非公式に確認する価値がある唯一の兆候は、インシデントが起きたとき、その原因が誰かのプレモーテムのリストに載っていたかどうかです。繰り返し載っていたなら、先を見通す力ではなく行動に問題があり、その方が議論する価値のある話題です。一貫して載っていなかったなら、プレモーテムは適切な問題を見つけられておらず、実施方法を変えるか、この取り組みをやめるべきです。やめる覚悟を持つことは、人々に始めてもらうよう求める代償です。
よくある質問
「Claude にやらせればよいのでは？」 一部は、そのとおりです。the-fool スキル（コミュニティが保守しており、GitLab や Anthropic の公式ツールではありません）をプレモーテムモードで使うと、設計ドキュメントから 90 秒で、もっともらしい失敗のリストが得られます。これは非同期記入のステップのよい出発点になります。設問と一緒に配布し、人々に反応してもらい、追加してもらいます。一方、この取り組みを機能させる肝心なことは生成できません。再試行の処理経路を担当するエンジニアが、実は誰か別の人が担当していると密かに思い込んでいたことや、Support がすでに 2 社のお客様で同じような失敗を見ていたことです。そうした情報は設計ドキュメントにはありません。Claude はリストを広げるために使ってください。黙って書く時間を省くために使わないでください。
「準備状況レビューと変更管理はすでに行っています。」 対象となる失敗のパターンが異なります。PREPのような準備状況レビューや変更管理は、行うべきだとすでに分かっていることを実施したかを確認します。プレモーテムは、誰のチェックリストにも載っていない、このリリースに固有のことは何かを問います。
「設計ドキュメントにはすでにリスクのセクションがあります。」 そのとおりであり、それは役に立ちます。Siphon の実行時リスクは、この取り組みが始まるずっと前から記録されていました。しかし、リスクのセクションは、リリースの成功に最も力を注いでいる人が、設計時に、おそらく 1 人で書いています。プレモーテムの価値は、設計が現実のものになった段階で複数の人が別々に書き、それらを集約することで、1 人の著者では見えなかった相互作用を明らかにすることです。
「リストが当たり前のことばかりだったら？」 その場合は、リスクについて文書で合意し、20 分で終了します。それはよい結果です。失敗のパターンは、当たり前のリストであることではありません。その場の誰もが、それまで明らかにしたり考えたりしていなかったリストであることです。
「誰が担当し、どこで管理しますか？」 実施するかどうかは、リリースの DRI が決定します。プレモーテムのプログラムも、四半期レポートも、追跡用 Issue もありません。存続するためにプログラムが必要なら、存続させるべきではありません。このページは、チームが利用できる取り組みを説明するものであり、必ず従うべき手順ではありません。
テンプレート
これをドキュメントにコピーし、24 時間前に共有してください。セクションを追加したくなったら、それこそがこのページで懸念している、取り組みの変質です。
## Pre-mortem: [launch name]
Session: [date] · DRI: [name] · Facilitator: [name]
**Scenario.** It is [launch date plus six to eight weeks]. [One specific bad outcome,
written as a fact that has already happened. Name a date, a number, and who noticed.]
**Before the call (async, 24 hours).** Write your own answers in your own section.
Do not read anyone else's first.
- Why did it fail?
- What did we find out too late, and how did we find out?
- What did we assume that turned out not to be true?
Be specific. "It didn't scale" is not an answer.
"The backfill held a lock for nine minutes at 14:00 UTC and web timed out" is.
**On the call (30 minutes).**
1. Read-out, one item each, round the room, no debate. (15 min)
2. Cluster into themes. Per theme: what is the cheapest thing we can do this week
that tells us whether this is real? (10 min)
3. DRI picks at most three. (5 min)
**Output (paste into the launch epic).**
Actions, maximum three:
| Action | Owner | By | Issue |
|--------|-------|----|-------|
| | | | |
| | | | |
| | | | |
Known and accepted, one line each:
We know [X] could happen. We are not acting on it because [Y]. If it happens, we find out via [Z].
5d840611)