Jiraでプレモーテムを行う：リリース前にリスクを見つける

Jiraではリリース準備ができて見えても、チームには誰も書いていない心配が残ることがあります。実装はほぼ終わり、テストが進み、公開日が迫っています。古い顧客アカウントは動きが違うのでは、と考える人もいれば、サポートが新しい操作を誤って説明するのでは、と心配する人もいます。

プレモーテムは、そうした心配に有用な出発点を与えます。すでにリリースがうまくいかなかったと想像して、原因を説明します。対応に追われる前に、ありうる失敗を話しやすくする練習です。

このガイドでは架空の顧客ポータルのリリースについて実践的なプレモーテムを行い、Power PackのRisk & Pre-Mortem Gridにまとめます。目標は、担当者、警告兆候、軽減の作業が明確な少数のリスクです。

具体的なリリース結果を選ぶ

チームは顧客ポータルにメール設定を加えています。顧客は任意のアカウントメールをオン・オフでき、必要なメッセージは引き続き受け取ります。Mayaがプロダクトの結果を担い、Leoが実装し、Priyaがテストを率い、Samがサポートを準備します。

共通のリリース結果を説明するJira課題を、プレモーテムの置き場所にします。実装とテストの関連チケットは通常のJira運用でリンクしたままです。リリース課題のそばに議論を置くと、振り返る場所が明確になります。

事前にMayaが範囲を短く書きます。設定機能の初回リリースに関し、顧客体験、メール動作、サポート準備を確認し、公開と最初の1週間を考えるというものです。この境界で、ポータル全体のあらゆる問題に議論が広がるのを防ぎます。

解決策を話す前に失敗を想像する

具体的に問いかけます。「公開から1週間です。顧客は混乱し、問い合わせが増え、展開を止める必要が出ました。何が起きたのでしょうか」。考えるきっかけになる程度に不都合な想像にしつつ、失敗が必然だとは示さないようにします。

数分間、各自で静かに原因を書きます。そうすると、最初の自信ある説明が場を支配する前に、テスターの懸念やサポートの観察も出せます。「品質が悪かった」といった一般論ではなく、具体的に説明できる原因を求めます。

次に順番にシナリオを共有します。最初は心配を集め、意味を明確にすることに集中します。最善の解決策の議論は後にします。気になる可能性を出す人が、その場で完全な改善計画まで弁護しなければならない状況は避けます。

• 既存顧客に、現在のメール設定と一致しない設定が表示される。
• 重要なメールまで無効にできるように見える。
• 公開前に変わった操作部品について、古いサポート手順が残っている。
• 裏側の更新が失敗していても、設定変更が成功したように見える。

これらは説明用の架空のシナリオです。実際の一覧は、仕事、依存関係、顧客体験を理解する人々から出します。Power Packは議論を記録し、何が起こりうるかを判断するのはチームです。

心配を認識できるリスク文に変える

役立つリスクは、起こりうる事象と影響を示します。「移行」は話題の名前です。「既存の設定値が誤って変換され、一部の顧客に止めたつもりの任意メールが届く」は調査できるシナリオです。

異なる影響を失わないように重複をまとめます。古いアカウントに関する複数の心配には共通の原因があるかもしれません。誤解を招くラベルと保存失敗はどちらも顧客を混乱させますが、確認方法が違うので通常は別のリスクにします。

各シナリオで早く気づけることを考えます。早期警告のきっかけは、注意を向けるべき観察可能な兆候です。既存のアカウント設定と移行後の予定値の不一致は、「苦情が出るかも」より有用です。公開前に確認できるからです。

可能性と影響の意味を合意する

Power Packには3×3または5×5のマトリクスがあり、可能性と影響を掛けて重大度を出します。議論や並べ替えの補助に使います。これは主観的な評価であり、失敗の頻度予測や期待損失の計算ではありません。

初回は3×3を使い、各値の意味を単純に決めます。可能性1は現時点で裏付けが少ない、2は十分ありえて調査が必要、3は対策しなければ起きると考える強い理由がある、という定義です。これはこのチームの作業用の基準です。

影響は顧客とリリースへの結果で定義します。1は限定的な不便、2は追加対応を要する相応の支障、3は深刻な顧客問題かリリースを止める理由です。別の環境なら異なる定義が必要かもしれません。

Priyaは誤移行を可能性2、影響3、スコア6と評価します。チームは背景を話します。新しい変換処理を代表的な古いアカウントでまだ試していません。数字の見かけの精密さより、不足している根拠のほうが重要です。

最初のリスクを比較するときは同じ尺度を維持します。マトリクスのサイズ変更では既存の値が再調整されるため、変更後の配置を見直します。新しい位置を、新しいリリース情報が発見された証拠と取り違えないでください。

Power Packにリスクを追加する

選んだJira課題でPower Packを開き、Risk & Pre-Mortem Gridを選びます。ヒートマップで評価の分布を見て、リスク一覧で各項目を確認します。最初の可能性と影響が分かっていれば、マトリクスのセルから追加できます。

各項目にタイトル、失敗シナリオ、早期警告のきっかけ、分類を記録します。合意した値、軽減計画、担当者を追加します。軽減の確認地点、状態、任意のJira課題参照も登録できます。

担当者はJiraユーザーでも外部の人物レコードでも構いません。対応を調整し、不足する根拠をチームへ持ち帰る人を選びます。表に名前を入れてもJiraタスクの作成、既存タスクの割り当て、課題へのアクセス付与は行われません。

共有されたと見なす前に保存状態を確認します。変更は課題に保存されますが、ローカルや再試行中の表示は、他のメンバーが最新版を見られる確認ではありません。

重要なリスクには具体的な対応を付ける

「徹底的にテストする」では追跡しにくいものです。移行リスクに対しPriyaは、既存アカウントの代表的な状態でリハーサルを行い、結果の設定と期待するメール動作を比較すると提案します。不一致はLeoが調べます。リスク担当者はPriyaのままで、リリースレビューへ結果を持参します。

進捗を見せる確認地点に分けます。代表ケースの選定、リハーサル、相違の確認、残る不確実性の記録などです。確認地点は対応を整理するもので、実際の根拠は関連するテストや実装作業の中に置きます。

軽減策に独立したJiraチケットが必要なら、通常のワークフローで作成して割り当て、キーをリスクの参照として加えます。参照は関係を追いやすくしますが、作業を自動作成したり遂行を管理したりするものではありません。

根拠が変わったら状態を見直す

Power Packの状態はIdentified、In Progress、Mitigated、Acceptedです。シナリオを記録したらIdentified、対応を進めているならIn Progressにします。Mitigatedにするために必要な根拠を合意しておきます。

Acceptedは、残るリスクを認識して進む判断を表せます。例えばSamが一時的な対応を用意したと確認したうえで、Mayaが小さなサポート文書の不足を受け入れる場合です。理由を残し、前提が変わったら再確認します。受容は理解された決定であり、表を整理するための操作ではありません。

リリースレビューでは担当者に警告兆候、軽減結果、残る不確実性を聞きます。重大な範囲変更、新しい依存関係、予期しないテスト結果は別途確認します。根拠があるときに値を更新し、評価が変わった理由を説明します。

計画の話し合い用にMarkdownやCSVへ出力できます。最新の記録を確認する場所としてJira課題を示します。共有された出力はある時点の写しであり、その後の評価を反映していないことがあります。

次の行動が変わる場にする

完成した表は、準備に影響してこそ役立ちます。このチームでは、移行のリハーサル、分かりやすい文言、サポートガイドとリリース候補の照合につながります。それぞれの行動が、実務に関わる人が挙げた具体的な失敗シナリオを扱っています。

一つのリリース、短い進行役付きの対話、少数の重要なリスクから始めます。Power Packでシナリオ、担当者、対応をJira課題のそばに置きます。次のリリースの会話にも持ち込み、実際に何が変わったかを評価しましょう。