このユニットの結論
新しい版を全員に一度に出すと、問題が出たときの影響も全員です。
一部の利用者から出し、決めた指標を観察し、条件を満たしたら広げ、条件を超えたら即座に戻す。「出す・広げる・戻す」の判断を数字と事前の条件で行うことで、本番で初めて分かる問題の影響を小さくできます。戻す条件は、広げる条件より先に決めます。
1. 何の話か
このユニットは、本番への配布を段階的に進める方法の話です。
09-04 自動テストと自動配布 で、合格した版を自動で配る流れを学びました。配る先が本番のときだけは、「一度に全員へ」ではない選択肢があります。世界で共有されている考え方では、機能の切り替えスイッチ（フィーチャーフラグ）や、少数への先行配布（カナリアリリース）を使う進め方を「プログレッシブデリバリー」と呼びます。
2. なぜ必要か
一度に全員へ出すと、
- テストでは見つからなかった問題（本番のデータ量、本番の使われ方）が、全員に同時に起きる
- 戻す判断が「全員に影響する大きな判断」になり、ためらって遅れる
- 問題の原因が「この版のどの変更か」を切り分けにくい
ということが起きます。段階的に出せば、問題は一部にとどまり、戻すのも速く、原因も絞りやすくなります。
3. このユニットで分かること
- 段階的に出す 2 つの道具（切り替えスイッチと先行配布）
- 観察する指標と、広げる条件・戻す条件
- 段階的に出せない変更の扱い
4. 2 つの道具
| 道具 | 仕組み | 向いている変更 | 注意 |
|---|---|---|---|
| 切り替えスイッチ | 新しい機能をプログラムに入れたまま、設定で「誰に見せるか」を切り替える | 画面や処理の変更。対象を部門や人で絞れる | 使い終わったスイッチは消す。残ると、どれが有効か分からなくなる |
| 先行配布 | 新しい版を一部の計算機や一部の利用者にだけ配り、残りは古い版のまま動かす | 基盤に近い変更。スイッチで隠せないもの | 新旧の版が同時に動くので、両方が同じデータを正しく扱える必要がある |
どちらも、「戻す」が速いことが価値です。スイッチなら設定を戻すだけ、先行配布なら配った一部を古い版に戻すだけです。
5. 指標と条件
段階ごとに、観察する指標（誤りの率、応答の時間、処理の失敗件数、問い合わせの件数）と、広げる条件（指標がこの範囲なら次へ）、戻す条件（指標がこの値を超えたら即座に戻す）を決めます。比べる基準は、従来の版の値です。先に測っておきます。
戻す条件は、広げる条件より先に、より厳しく決めます。戻す条件が決まっていないと、問題が出たときに「もう少し様子を見る」が続きます。可能なら、戻す条件は監視が検知して自動で戻すようにします。
段階的に出せない変更もあります。データの形の変更（項目の追加・分割）は、スイッチで隠せず、変換したあとに新しいデータが入ると戻せません。こうした変更は「戻せなくなる点」を明示し、12-03 失敗したら元に戻せるか の考え方で別に扱います。計画は DEV-007 段階的リリース計画 に書き、どの環境にどの版があるかは DEV-004 環境・リリース対応表 で追います。
CASE FACTFROZEN正本に記載されたアステリア案件の事実
アステリア案件のリリースに関する記載
- M18 本番稼働、M21 初期安定化完了
- システムに SYS-09 開発・CI/CD基盤、SYS-11 監視・ログ基盤 がある。Vendor B クラウドブリッジの担当範囲に CI/CD、監視 が含まれる
- 成果物に DEV-004 環境・リリース対応表、DEV-007 段階的リリース計画 がある
- P-011 山下 恵 — 本番移行・運用リーダー
- 本番移行承認は、AIへ最終委任しない事項
稼働後のリリースが段階的に行われたか、何を観察して広げたかは、正本に記録がありません。記録なし
6. THINK — 「小さな修正なので全員に一度に出す」
稼働後の定例で、次の提案がありました。
「今回は画面の文言の修正と、請求の計算の小さな直しだけです。段階的に出す手間をかけず、全員に一度に出しましょう。」
問題
この提案をそのまま認めてよいでしょうか。
判断例を開く
判断
「文言の修正」と「計算の直し」は、同じ「小さな修正」ではありません。
確認すること:
- 計算の直しは、金額に影響するか。影響するなら、一部の請求で確かめてから広げる価値がある
- 2 つの変更が 1 つの版に混ざっていると、問題が出たときにどちらが原因か分かりにくい（分けて出せないか）
- 観察する指標（計算結果の検証、問い合わせ）と、戻す条件は決まっているか
- 戻す手順は、この変更で使えるか（データを変える処理が含まれていないか）
- 「手間」は、段階的に出す仕組みが整っていないからか。整っていれば手間はほとんどない
文言だけなら一度に出してよいでしょう。計算の直しは、金額に関わる以上、一部から出して確かめる方が、結果として速く安全です。
7. よくある失敗
- 最初の段階の対象を「協力的な部門」だけにし、本番の使われ方の幅を見ずに広げる
- 広げる条件は決めたが戻す条件を決めず、「もう少し様子を見る」が続く
- 切り替えスイッチを消さず、何十も残って、どれが有効か分からなくなる
- データの形の変更をスイッチで隠せると思い込み、戻せなくなる点を見落とす
8. 成果物との接続
- DEV-007 段階的リリース計画：段階、観察する指標、広げる条件、戻す条件と手順
- DEV-004 環境・リリース対応表：どの環境に、どの版が、いつ出たか。段階的に出している途中の状態も記録する
9. AI WORKFLOW — 条件と判断の食い違いを点検させる
AIは、リリースの記録から、広げる条件・戻す条件と実際の判断が食い違った段階を探す下書きに役立ちます。
指示例:
「次のリリースの記録を読み、段階ごとに『観察した指標の値』『条件を満たしたか』『判断』を表にし、条件を満たしていないのに広げた段階、条件を超えたのに戻さなかった段階があれば示してください。判断の是非は評価しないでください。」
10. REVIEW — AIの点検を確認する
- AIが「条件を満たした」と読んだ指標の値が、記録と一致しているか
- 条件と判断が食い違った段階について、了解された例外かどうかを人が確かめたか
- リリースの記録を AI に渡してよいか（構成・業務情報の扱い）を事前に確かめたか
11. 人間が判断すること
- 最初の段階の対象と、段階の数
- 広げる条件と戻す条件の値
- 条件を満たさないときに、広げるか、待つか、戻すか
本番移行承認は、AIへ最終委任しない事項です（正本の方針）。
12. 判断演習
「経費精算の画面に、新しい承認の流れを追加する」変更を段階的に出す計画を立ててください。
最初の段階の対象（誰に）、観察する指標（3 つ）、広げる条件、戻す条件、戻す手順を書いてください。そのうえで、この変更の中に「段階的に出せない部分」があるとしたら何か、1 つ書いてください。
あなたの記録あなたの考え。事実ではありません
判断ノート
このユニットで覚えてほしいこと
本番には一部から出す。切り替えスイッチか先行配布で対象を絞り、指標を観察し、条件で広げ、条件で戻す。戻す条件は広げる条件より先に、厳しく決める。