段階的リリース計画

これは何か

段階的リリース計画は、新しい版を本番の全員に一度に出すのではなく、一部の利用者や一部の処理から出し、観察する指標と広げる条件・戻す条件を決めて、段階的に広げる手順を書いた成果物です。

全員に一度に出すと、問題が出たときの影響も全員です。一部から出せば、問題は一部にとどまり、戻すのも速くなります。世界で共有されている考え方では、機能の切り替えスイッチ（フィーチャーフラグ）や、少数への先行配布（カナリアリリース）を使う進め方を「プログレッシブデリバリー」と呼びます。

なぜ作るか

• 本番で初めて分かる問題（本番のデータ量、本番の使われ方）の影響を、一部にとどめる
• 「出す・広げる・戻す」の判断を、数字と事前の条件で行い、その場の空気で決めない
• 戻す手順を、出す手順と同じ重さで用意する（12-03 失敗したら元に戻せるか）
• 自動の流れ（09-04 自動テストと自動配布）の最後の段階（本番）を、段階的に進められるようにする

誰が使うか・いつ作るか

• 作る人：開発の取りまとめ役と、開発・CI/CD 基盤を担当する会社。運用の担当が観察する指標を提供する
• 使う人：リリースを決める人、配布を実行する人、運用・監視の担当、業務部門の窓口
• 一般的には、本番への配布の仕組みを作るときに型を決め、リリースごとに具体の値（対象、指標、条件）を埋めます
• アステリア案件で段階的なリリースが行われたか、どんな条件で広げたかは、正本に記載がありません。未確定

稼働後のリリースがどんな段階で行われ、何を観察して広げたかは、正本に記載がありません。未確定

主な項目

一般的には、リリース 1 回ごとに次の項目を持ちます。

1. 対象の変更：何を出すか（機能、修正）。切り替えスイッチで隠せる変更か、隠せない変更（データの形の変更 など）か
2. 段階：最初の対象（たとえば社内の 1 部門、全体の 5%）、次の対象、全体。段階ごとの期間
3. 観察する指標：誤りの率、応答の時間、処理の失敗件数、問い合わせの件数。段階ごとの観察の期間
4. 広げる条件：指標がどの範囲なら次の段階へ進めるか。誰が判断するか
5. 戻す条件：指標がどの値を超えたら即座に戻すか。自動で戻すか、人が判断するか
6. 戻す手順：切り替えスイッチを戻す、前の版に戻す、データを戻す。それぞれにかかる時間と、戻せなくなる点
7. 連絡：段階ごとに、誰に何を知らせるか。問題が出たときの連絡先
8. 記録：各段階の実施日時、指標の値、判断、判断した人

読み方

1. 段階ごとに、対象・観察の期間・広げる条件が数字で書かれているか
2. 戻す条件が、広げる条件より厳しく、即座に動く形か
3. 戻す手順にかかる時間と、戻せなくなる点が書かれているか
4. 切り替えスイッチで隠せない変更（データの形）が、別の扱いになっているか
5. 各段階の判断と指標の値が記録に残るか

書き方

1. 変更を「切り替えスイッチで隠せるもの」と「隠せないもの」に分ける
2. 観察する指標を運用・監視の担当と決め、従来の値（比べる基準）を測っておく
3. 段階と条件を表にする。戻す条件は、広げる条件より先に決める
4. 戻す手順を実際に一度通す（戻したことのない手順は動かない）
5. リリースごとに記録を残し、条件の妥当性を見直す

何を書いてはいけないか

• 「問題がなければ広げる」のような、指標のない条件
• 戻す手順のない計画（出すことだけを考えた計画は、計画ではない）
• 切り替えスイッチを本番に残し続けること（使い終わったスイッチは消す決まりを書く）
• 実在の製品名を、案件の正式な採用として書くこと（正本に記載がない）

よくある失敗

• 最初の段階の対象を「協力的な部門」だけにし、本番の使われ方の幅を見ずに全体へ広げる
• 広げる条件は決めたが戻す条件を決めず、問題が出ても「もう少し様子を見る」が続く
• データの形の変更を切り替えスイッチで隠せると思い込み、戻せなくなる点を見落とす

関係するUnit・成果物・危機演習

• Unit：09-07 本番へ段階的にどう出すか、09-04 自動テストと自動配布、12-03 失敗したら元に戻せるか、14-02 正常に動いているか何を見るのか
• 成果物：DEV-003 自動テスト・自動配布構成、DEV-004 環境・リリース対応表、CUT-003 切り戻し計画書、OPS-002 監視・アラート一覧
• 危機演習：この成果物を直接の題材にする危機演習はありません

いつ使うか

この教材では STAGE 09｜120人で安全に開発する の文脈で扱います。 アステリア案件での正式な作成・使用時期（月）は正本に記載がないため、未確定としています。