段階的リリース計画
Idira Gradual Release Frameworkに従い、構造化されたリリース計画を生成します。PRDからシグナルを推論し、リリースパスを分類し、リングをマッピングし、R3コホート計画を構築し、LaunchDarklyのセットアップ手順を提供します。
ステップ1 — PRDを読み取り、推論する
PRD全体を読み込みます。以下の各シグナルを内容から推論してください。自分で判断できることについてPMに質問しないでください。
| シグナル | 探すべき内容 |
|---|---|
| NFI | 「NFI」ラベル、「新機能」、「以前は利用不可」、以前のバージョンのない完全新規機能 |
| 影響度 | 影響を受けるユーザー/テナントの範囲、「クリティカルパス」/「コアワークフロー」の表現、データセンシティビティ、データ損失やサービス中断のリスク |
| ロールバックの複雑さ | スキーママイグレーション、データ書き込み、サードパーティ依存関係、必要な顧客連絡、不可逆的な状態→「協調的」または「不可逆」。フラグ切り替えのみ→「簡単」。言及がない場合→必ず質問 |
| 地域制約 | GDPR、FedRAMP、データレジデンシー、地理固有の要件、「[地域]から開始」、「[地域]のみ」、「[地域]から先に」、「[地域]に限定」 |
| サービス制約 | 機能が依存または変更する名前付きサービス、統合、またはコンポーネント |
| 初期テスター準備完了 | 「QA準備完了」、スプリント完了日、アルファ/ベータ日付 — 機能が最初の外部公開に十分安定した時期 |
| 目標GA | 確定リリース日、OKR期限、リリースマイルストーン |
読み取り後、推論結果を提示してください。PRDに見つからないシグナルは❓とマークし、最後に関連する質問をします。
PRDに基づいて、このリリースを次のように読み取りました：
- NFI: [はい / いいえ — 理由] または ❓ PRDから不明
- 影響度: [高 / 中 / 低 — 理由] または ❓ PRDから不明
- ロールバック: [簡単 / 協調的 / 不可逆 — 理由] または ❓ 言及なし
- 地域制約: [なし / リスト — 理由] または ❓ 言及なし
- サービス制約: [なし / リスト — 理由] または ❓ 言及なし
- 初期テスター準備完了: [日付 — 理由] または ❓ PRDに見つかりません
- 目標GA: [日付 — 理由] または ❓ PRDに見つかりません
その後、❓となった質問のみを次の正確な形式で尋ねます。
- ロールバックが未記載 → 「ロールバック計画はありますか？ 選択肢：(1) 簡単 — 単純なフラグ切り替えで即時復元。(2) 協調的 — データマイグレーション、スクリプト、または顧客連絡が必要。(3) 未定義 — ロールバック戦略はまだ設計中。」
- 影響度が不明 → 「問題が発生した場合の顧客への影響をどのように評価しますか？ 高（コアワークフローまたは多数のテナントに影響）、中（特定のサービスまたはサブセットに限定）、低（軽微 / 容易に復元可能）」
- 初期テスター準備完了が見つからない → 「機能はいつ初期テスターによる検証準備が整いますか？」
- 目標GAが見つからない → 「目標とするGA日付または期間はいつですか？」
- 地域が未記載 → 「地域制約はありますか？ 例：特定の地域（EMEA、US、APAC）から開始し、その後グローバルに拡大するなど」
値を仮定しないでください。PRDから既に判明しているシグナルについては質問しないでください。
ステップ2 — リリースパスを分類する
NFI = はい → HIGH-TOUCH
または 影響度 = 高
または ロールバック = 不可逆
影響度 = 中 → STANDARD
または ロールバック = 協調的
その他 → LIGHTWEIGHT
ステップ3 — 必要なリングをマッピングする
| パス | 必須リング | R&D担当 | PM担当 |
|---|---|---|---|
| LIGHTWEIGHT | R0 → R4 | R0 | R4 |
| STANDARD | R0 → R3 → R4 | R0 | R3, R4 |
| HIGH-TOUCH | R0 → R1 → R2 → R3 → R4 | R0, R1 | R2, R3, R4 |
- R0 内部QA — エンジニアリング/QA環境
- R1 カスタマーゼロ / ドッグフーディング — 社内チーム
- R2 カスタマーワン — 選定された早期アクセス顧客（NFIプロセス経由）
- R3 プロダクションカナリア — テストテナント → LaunchDarklyフラグによるライブコホート
- R4 一般提供 — 対象となるすべてのプロダクションテナント
ステップ4 — R3コホート計画を構築する（StandardおよびHigh-Touchのみ）
R3は常にテストテナントから開始します。その後、ARR順にライブテナントを展開します。
| ウェーブ | 累積% | 対象 |
|---|---|---|
| 0 | — | テストテナント（顧客購入のサンドボックス） |
| 1 | 5% | 最低ARR、少数テナント |
| 2 | 15% | 低～中ARR |
| 3 | 35% | 中ARR |
| 4 | 65% | 中～高ARR |
| 5 | 100% | 残りの対象全テナント |
調整：
- サービス制約 → ウェーブごとにサービスフィルタターゲティングを追加
- 地域制約 → 初期ウェーブに地域フィルタを追加、ウェーブ4〜5で削除
- 短いタイムライン → ウェーブを統合（例：5% → 35% → 100%）
- 高ARRへの配慮 → 高ARRテナントはウェーブ4まで保持し、ベイク時間を延長
各ウェーブに含めるもの：%、コホート説明、Go/No-Goゲート（メトリック + ベイク時間）、担当者。Go/No-Goゲートは必須であり、省略しないでください。PRDで成功メトリックが定義されている場合はそれを使用し、ない場合はデフォルトを適用します：署名/機能成功率 ≥99.5%、エラー率差 <0.1%、p99レイテンシ悪化 <5%、サポートチケット増加 <テナント1,000件あたり3件、初期ウェーブの最小ベイク時間48時間、高ARRウェーブは1週間。
ステップ5 — 完全なリリース計画を出力する
以下のテンプレートを使用して計画を作成します。
# 段階的リリース計画 — [機能名]
**リリースパス:** [LIGHTWEIGHT / STANDARD / HIGH-TOUCH]
**最早開始日:** [日付] | **目標GA:** [日付]
---
## このリリースの読み取り方
| シグナル | 値 | 根拠 |
|--------|-------|-----------|
| NFI | はい/いいえ | [一行] |
| 影響度 | 高/中/低 | [一行] |
| ロールバック | 簡単/協調的/不可逆 | [一行] |
| 地域制約 | なし / [リスト] | [一行] |
| サービス制約 | なし / [リスト] | [一行] |
---
## 必要なリング
| リング | ステージ | 担当者 | 開始条件 | 終了条件 |
|------|-------|-------|------------|-----------|
| R0 | 内部QA | R&D | メインにマージ | QA承認 |
| R1 | ドッグフーディング | R&D | R0完了 | 内部承認 *(High-Touchのみ)* |
| R2 | カスタマーワン | PM | NFIプロセス完了 | 顧客フィードバック確認済み *(High-Touchのみ)* |
| R3 | プロダクションカナリア | PM | R2完了 | 100%ウェーブ安定 |
| R4 | 一般提供 | PM | R3 100%ウェーブ完了 | PMのGo/No-Go判断 |
*(選択したパスに必要なリングのみ含める)*
---
## R3コホート計画
**最初:** テストテナント — ライブテナントの前に安全なアクティベーションを確認。
| ウェーブ | % | 対象 | ターゲティング | Go/No-Goゲート |
|------|---|-----|-----------|---------------|
| 0 | — | テストテナント | 外部テストテナント | 48時間インシデントなし |
| 1 | 5% | 低ARR | [基準] | [メトリック]が[ベイク時間]安定 |
| 2 | 15% | 低～中ARR | [基準] | [メトリック]が[ベイク時間]安定 |
| 3 | 35% | 中ARR | [基準] | [メトリック]が[ベイク時間]安定 |
| 4 | 65% | 中～高ARR | [基準] | [メトリック]が[ベイク時間]安定 — 延長 |
| 5 | 100% | 全対象 | フィルタ解除 | [メトリック]が[ベイク時間]安定 |
---
## LaunchDarklyセットアップ
**1. フィーチャーフラグを作成する**
- フラグキー: `[機能名]-rollout`（小文字、ハイフン区切り）
- タイプ: ブール値
- デフォルト（オフ）: 全環境でfalse
**2. 環境を構成する**
- `internal-qa` → R0: R&D QAチームに対して有効化
- `dogfooding` → R1: 社内テナントに対して有効化 *(High-Touchのみ)*
- `early-access` → R2: 指定されたカスタマーワンテナントに対して有効化 *(High-Touchのみ)*
- `production` → R3: 以下のターゲティングルール
**3. プロダクションターゲティングルール（R3ウェーブ）**
ウェーブ0 — テストテナント:
- ルール: `tenant_type = "test"` → trueを提供
ウェーブ1 — 5%:
- ルール: `tenant_type = "live" AND arr_tier = "low"` → 5%ロールアウトでtrueを提供
ウェーブ2〜5: ロールアウト率を増加させ、ウェーブごとに`arr_tier`フィルタを拡大します。
ウェーブ5（100%）で`arr_tier`フィルタを完全に削除します。
サービス制約がある場合:
- 各ルールに`AND deployed_services CONTAINS "[サービス名]"`を追加します。
地域制約がある場合:
- 初期ウェーブに`AND region IN ["[地域]"]`を追加し、ウェーブ4〜5で削除します。
**4. ウェーブ間のゲート**
- ベイク期間中、エラー率、レイテンシ（p99）、サポートチケットを監視します。
- Go/No-Go基準が満たされた後にのみ、次のウェーブに展開します。
- 一時停止またはロールバックするには：プロダクションフラグをfalseに設定します — すべてのテナントが即座に元に戻ります。
**5. 単一トグル**
- R&Dは影響を受けるすべてのコンポーネントにわたって1つのフラグキーを実装する必要があります。
- R3開始前に、すべてのコンポーネントが同じフラグを読み取ることをR&Dと確認してください。
---
## 担当者と責任
- **R&D** — フラグを実装し、R0〜R1を担当、単一トグルカバレッジを検証
- **PM** — 顧客公開（R2〜R4）を担当、各ウェーブゲートにサイン、コホート計画を更新
- **プロダクトオペレーション** — R3開始前に必須ガイドラインに対して計画をレビュー
## 未解決の質問 / 前提条件
- [R&D / BIと確認済みまたは確認すべき前提事項のリスト]
例
完成したコホート表とLaunchDarklyルールを含む実例については、reference.mdを参照してください（NFI、高影響度、3か月GA目標）。