プレモーテムの進め方：失敗を想定してリスクを見つける

「何かリスクはありますか」と聞くと、短い話し合いだけで「大丈夫そうだ」と終わりがちです。プロジェクトのプレモーテムでは、より具体的に問いかけます。「すでにプロジェクトが失敗したと想像してください。何が起きたのでしょうか」。視点を変えることで、計画を修正できるうちに、検討すべき失敗の筋道が見えてきます。

ワークショップの結果は、検証すべき前提、追加する予防策、監視する兆候、再調整する約束など、少数の具体的な計画変更につなげます。

プレモーテムを実施するタイミング

計画の形が見えてきた後、費用の大きい、または取り消しにくい約束をする前に実施します。新しい仕組みの導入、移行、イベント、複数チームによるリリースなどが対象になります。計画が大きく変わったときは、機械的に会議全体を繰り返すのではなく、関係するリスクを見直します。

プレモーテムは、想像上の失敗から将来を考える手法です。実際に行った仕事を検討する振り返りとは異なります。また、リスク登録簿は、リスクを継続的に記録・追跡するものです。このワークショップの結果を登録簿に反映することはできますが、技術的なテスト、契約確認、専門家による安全性分析の代わりにはなりません。

Atlassianのプレモーテム手法は、個人でのアイデア出し、議論、担当者を決めた行動を通じて、プロジェクトのリスクを探ります。以下では、この基本的な進め方をリリースの場面に当てはめ、特に早期の警告サインに注目します。

具体的に想像できる失敗シナリオを書く

「プロジェクトがうまくいかなかった」だけでは不十分です。いつの時点で、どのような重要な結果になったのかを書きます。顧客サポートのシステム移行なら、例えば「切り替えから一か月が経過した。顧客はまだ旧メールアドレスに連絡し、担当者は過去のやり取りを見つけられず、チームは旧システムに戻した」とします。

これは検討用の仮想シナリオであり、予測ではありません。参加者が考える原因を指定せず、共通の出発点を用意します。「期日に間に合わなかった」だけに限定すると、予定どおり公開してもユーザーの役に立たない失敗を見落とします。

現在のプロジェクト計画、目指す成果、分かっている制約を事前に共有します。変更を実施する人と、変更後の仕組みを使う人の両方を招きます。サポートの移行では、担当者や管理者が、プロジェクトのスポンサーには見えない失敗の経路に気付くことがあります。

責任追及の議論にせず進める

最初に、批判の対象は計画であり、計画を作った人の能力ではないと伝えます。一人ずつ、起こりうる原因を独立して書き、一つの原因を一枚の付箋にします。リーダーは、ほかの人が意見を出すまで自分の見立てを控えます。そうしないと、最初に出た上位者の意見を裏付ける理由ばかりが並びかねません。

グループ分けの前に、付箋を読みます。「研修が終わっていない」と「例外的な問い合わせに答えられない」は関連していても、同じではありません。前者は研修への参加、後者は対応能力の問題です。早くまとめすぎると、具体的な対策につながる情報が失われます。

各グループについて、失敗がどのような順序で起きるかを尋ねます。「連絡不足」なら、「新しい連絡先をニュースレターでしか知らせなかった。顧客は以前のメールに返信した。切り替え後は旧受信箱を誰も確認していなかった」と具体化します。これにより、介入できる箇所が複数見つかります。

例：サポート業務を新システムへ移行する

次の架空のボードは、失敗の物語を判断事項へ変える例です。氏名と日付は実際のプロジェクトチームが追加します。ここに示す役割は、誰が責任を持つかを考えるための例です。

「移行が失敗する」は結果であり、原因ではありません。同様に「プロジェクトを監視する」も、何を観察し、その後どの判断をするかが決まるまでは、具体的な対応とは言えません。

確率を無理に数値化せず優先順位を付ける

影響の大きさ、そのリスクが起こりうると考える根拠、いつまでなら対応できるかを話し合います。来週でも簡単に戻せるものと、取り消せない切り替えの後にしか発覚しないものは違います。確率を見積もる根拠がないなら、精密な割合を作るのではなく「不明」とします。

投票は、議論する価値のある懸念を見つける手助けにはなりますが、最終対応を投票だけで決めてはいけません。専門家が気付いた深刻な失敗の仕組みに、ほかの参加者が理解できないため票が集まらないこともあります。理由を聞き、適切な専門家に検討をつなぎます。

必要な判断に合った行動を選びます。大規模展開を承認する前にサンプル移行を試すのは有用でしょう。一方、短い練習で主な問題がアクセス権だと分かるかもしれないのに、すべての研修資料を書き直すのは無駄になる可能性があります。

予防策と発生時の対応を分ける

予防策は、失敗が起こる前に、その可能性や影響を減らすものです。発生時の対応計画は、所定の条件に達したら何をするかを定めます。サポートチームが公開前に移行データを照合するのは予防です。展開を延期したり、サービスを復旧したりする条件を決めるのは、発生時の対応計画です。

判断のきっかけは観察可能にします。「状況が悪そうなら」では、切迫した中で基準を交渉することになります。「必須の種類の案件をリハーサルで処理できなければ」なら、リリース責任者が具体的に評価できます。基準は例から借りた任意の数値ではなく、プロジェクトのサービス要件に合わせます。

重要な判断は意思決定ログに残し、残留リスクを誰が受け入れられるかも記録します。会議の進行役に、その権限が暗黙に移るような運用は避けてください。

会議後も言いにくい懸念を残す

スポンサーの提示した日程を、全員の前で批判しにくい参加者もいます。会議前に懸念を提出できる方法を用意し、解決していない意見の違いは後から確認します。収集方法が匿名性を保証していないなら、匿名だと約束しないでください。

行動の責任が曖昧なら、RACIマトリクスを使います。プレモーテムのボードには、リスク、兆候、対応、担当者、次の判断日という簡潔な情報を残します。実際の実施タスクへのリンクを付け、二つの場所で別々に進捗を管理しないようにします。

Boardmixを開き、キャンバスの上部にサポート移行の失敗シナリオを置きます。その下に、例と同じ「考えられる原因」「早期の警告サイン」「対応案」「担当者の候補」の四列を作ります。原因と対応は同じ行に並べます。履歴の欠落については、サンプル案件の確認で見つかった不備を、移行責任者が担当する照合タスクにつなぎます。切り替えの承認前に、このタスクと残っている警告サインを確認します。必要な添付ファイルがまだ欠けていれば、リリース責任者には延期を判断する具体的な理由があります。