リリース判定のプレゼンでは、承認権限を持つ人が「何を公開するのか」「どの根拠で判断するのか」「失敗したらどうするのか」に答えられるようにします。冒頭で求める判断を示し、根拠と未解決の条件を並べ、最後に誰が何を承認したかを記録します。緑色のステータス表示を並べるだけでは不十分です。
まず、レビュー済みのリリース情報をまとめます。その後、Presentiでテキストから編集可能なプレゼンの下書きを作り、根拠への参照や承認条件をスライドに残せます。以下は、架空の予約サービスのGo/No-go会議を例にした説明です。記録、時刻、しきい値は学習用の例であり、実際の導入結果ではありません。
進捗の前に、対象リリースと判断を示す
チームは、予約枠の確保とキャンセル方法を変更するバージョン2.4を公開しようとしています。料金、アカウント移行、モバイルアプリは対象外です。検討する候補はビルド2.4-rc3、設定セットC17で、新しいデータベース移行を含みます。まず社内テスト用アカウント10件に限定し、顧客への公開は別の判断とする案です。
会議時点で予約機能のテストは合格していますが、通知の遅延は調査中です。ロールバックの予行確認は前の候補を対象としており、rc3とその移行処理は対象外でした。したがって、冒頭は次のように述べます。
提案：rc3の試験公開を見合わせる。予約の動作を裏付けるテスト結果はあるものの、この候補からの復旧は実証できていません。復旧条件を満たし、通知遅延の状況を明らかにしてから、試験公開の承認を求めます。
「リリース2.4は95%準備完了」とするよりも、判断に役立つ説明です。完了率は影響の異なる項目を混ぜてしまいます。文書作成が何件終わっていても、復旧結果がないという問題は相殺できません。
最初のスライドにビルド、設定、レビュー時刻、求める公開範囲を載せます。会議中にビルドや設定が変わったなら、どの根拠が引き続き有効かを確かめる必要があります。前の候補への承認を、新しい成果物にそのまま引き継がないでください。
各結果が裏付ける範囲を示す
根拠は短い一覧にまとめ、詳細記録は別途参照できるようにします。各行で、主張、対象範囲、残る不足を結び付けます。社内アカウントや一部の決済経路しか確認していないのに、「テスト合格」とだけ書くのは範囲が広すぎます。
| 領域 | この架空のレビューでの根拠 | 判断への意味 |
|---|---|---|
| 予約の動作 | QA-42に、検証環境のrc3/C17で行った予約作成、キャンセル、同時予約のテストを記録。 | 確認した経路を裏付ける。あらゆる顧客負荷での動作を証明するものではない。 |
| 通知 | MAIL-9に、再試行テスト中の確認通知の遅延を記録。最大遅延と原因は未解決。 | 例外を見える状態に保つ。通知は準備完了とせず、遅延が無害だとも決め付けない。 |
| 復旧 | RB-14は前の候補で実施。rc3と移行処理を対象にした予行確認の記録はない。 | 合意済みの復旧条件を満たさず、現時点の提案は見合わせ。 |
| サポート体制 | OPS-6に、主担当、代理、試験時間帯、エスカレーション経路を記載。 | その時間帯の体制がある。無期限の対応や公開範囲の拡大まで保証しない。 |
QA-42などは例示用の記録IDです。実際の資料では、環境、候補、時刻を含む本物の結果へ参照できるようにします。個人情報や運用上の秘密は適切にアクセス制限された記録に置き、広く共有するプレゼンへ転載しないようにしてください。
Googleの信頼性を考慮した製品公開の解説（英語）は、サービスに合わせた具体的で実用的な確認を重視しています。過去の公開チェックリスト（英語）にも、障害時の動作、監視、復旧、段階的な公開が含まれます。自社向けに考える問いとして使い、普遍的な承認基準や自社サービスが合格した証拠として扱わないでください。
公開を止める条件と、受け入れた例外を区別する
どの条件なら見合わせ、どの条件なら明示的な範囲制限の下で検討できるかを、会議前に合意します。そうしないと「黄色」の表示が、公開範囲の判断ではなく色の交渉になってしまいます。
この例での合意は、どの試験公開でも、その候補から復旧できることを先に実証するというものです。rc3の予行確認がないことは公開を止める条件に当たります。顧客向けから従業員10人へ対象を狭めるだけで、議長が受け入れ可能な例外に変えることはできません。
メール遅延は別の問いです。その制限を残して狭い範囲の試験を行えるでしょうか。まず観測された遅延、予約状態が正しいままか、参加者に何が見えるか、誰が試験を止められるかを知る必要があります。「回避策がある」だけでは答えになりません。
例外案には、制限内容、影響する利用者、根拠、一時的な対策、責任を持つ役割、期限または見直し時点を短く記します。対象者と終点のない例外は、リリースの約束を期限なく変えてしまいます。
3つの結果を区別してください。Goは合意条件の下で明示した範囲を承認します。限定Goは、さらに小さく具体的な範囲を承認します。No-goでは、指定した根拠と判断を再検討するまで提案された変更を承認しません。どのラベルも、発表者に本来ない権限を与えるものではありません。
復旧まで見える公開経路を描く
「デプロイ」で終わるタイムラインでは、承認の前提となる作業が隠れます。段階の間に判断や停止条件を置き、短い経路として示します。
- 公開前：rc3の復旧確認を完了し、MAIL-9の状況を明らかにする。新しいレビューに記録を添える。
- 承認：指定されたリリース承認者が、その候補を10アカウントの試験に進めてよいか判断する。
- 限定した観測：指名された担当者が試験時間帯の予約の正しさ、通知、合意済みの監視指標を確認する。
- 次の判断：限定状態の継続、停止と復旧、または公開拡大の申請を選ぶ。最初の承認で最後の選択肢まで自動的に許可されるわけではない。
後のレビューで、二重予約の確認、5分を超える確認通知の遅延、そのどちらかを観測するために必要な監視の喪失を停止条件にしたと仮定します。これは例のサービスに固有の限度であり、推奨される標準値ではありません。30分の観測を限定試験に含めることはできますが、より大きな規模での信頼性を実証したことにはなりません。
停止条件の横に、止める権限を持つ人を記します。この例では当番責任者が試験を停止でき、再開可否はリリース承認者が決めます。復旧経路は承認済みの手順書へつなぎ、プレゼン自体を実行可能なデプロイ手順にしないでください。
データベース移行では「戻す」の意味も確認します。旧アプリは新アプリが書き込んだ記録を読めるでしょうか。試験中に作られた予約の照合が必要でしょうか。分かっている答えか、不足する根拠を示します。アプリのバージョンを戻すだけでは、データが利用可能な状態に復旧した証明にはなりません。
チーム別の報告ではなく、6枚で判断の流れを作る
各チームの週報を繰り返さなくても、短い資料で判断を進められます。
- 「復旧を実証するまで、rc3の試験公開を見合わせる」。候補、範囲、提案、承認する役割を示す。
- 「予約テストは確認経路を裏付けるが、2つの条件が未解決」。根拠一覧とその限界を示す。
- 「前回のロールバック結果は、この移行を対象としていない」。公開を止める不足と、必要な結果を説明する。
- 「最初の承認は10アカウントだけが対象」。段階、観測時間帯、停止権限を示す。
- 「提案した時間帯のサポート要員は確保している」。役割、代理体制、時間帯終了後の引き継ぎを示す。
- 「判断と、再レビューに必要な条件を記録する」。会議の結論を具体的に残す。
最初のスライドは提案で、最後は実際の決定です。異なる場合もあります。会議で求める範囲が変わったら、その変更を記録してください。後から冒頭を書き換えて、何を検討したのかが分からなくならないようにします。
下書きには6つの見出しと、その下にレビュー済みの根拠を入力します。「rc3/C17を変更せず、見合わせ提案と未解決の復旧条件を残してください。根拠、今後の段階案、承認を区別してください。テスト結果、承認者の名前、公開日、性能向上を作らないでください」と指定できます。仕上げの前に生成文を読み、整ったレイアウトによって予定が承認済みに見えていないか確認します。
完成した判断記録を残して会議を終える
架空の会議の記録は次のとおりです。参加者が退出する前に読み上げられる長さにしています。
決定：14:00のレビューで、rc3/C17の10アカウント試験案をNo-goとした。顧客への公開は承認していない。
理由：復旧の根拠が候補のデータベース移行を対象としていない。通知遅延も未解明。
次に必要な根拠：開発責任者が、新たに作られた予約の扱いを含む候補固有の復旧結果を提出する。通知担当者が、遅延調査と試験範囲の制限案を提出する。
判断責任者：指定されたリリース承認者が、記録がそろった時点で再レビューを開く。提案された16:00の確認は状況報告であり、16:00にデプロイしてよいという許可ではない。
変わらない対象外事項：顧客への展開、モバイルアプリ、料金、アカウント移行は今回の判断に含めない。
資料と根拠への参照に、この記録を添えて共有します。次の会議で異なる結論になったら、その時に検討した候補と条件について新たに記録します。欠席者にも、何が承認され、何が見送られ、次に何が必要か分かることが、このプレゼンの役割です。
