リリース停止期間はいつ設けるか。繁忙期と開発を両立させる判断

リリースフリーズを判断するときは、繁忙期に開発を一律停止せず、変更を三つに分けます。売上や顧客対応への影響が大きい期間を事業カレンダーから特定し、「通常変更は延期する」「既存の不具合や脆弱性の修正は条件付きで承認する」「事業継続を脅かす事象への緊急変更は例外経路で扱う」と先に決めます。

経営者が担うのは、どの事業をいつ守り、誰が例外を承認するかの決定です。コードの公開手順は、その決定を実行するために技術側が整えます。開始日と終了日だけを決めても、繁忙期に見つかった不具合を直してよいか、予定日が来れば本当に解除してよいかは決まりません。そこで僕なら、事業カレンダーに変更の分類と承認条件を重ねた「変更凍結台帳」を作ります。残る条件は、フリーズを解除する日に何を確認し、未反映の変更をどの順番で戻すかです。

リリースフリーズの判断は事業カレンダーから始める

判断の起点は、失敗した変更の影響を事業側で受け止めにくい期間です。受注が集中する時期、顧客対応の担当が薄くなる時期、重要な業務が特定のシステムに集中する時期を、開発スケジュールより先に社内の事業カレンダー上で確認します。そのうえで、対象システムごとに変更を止める範囲を決めます。全社で同じ期間を置く必要はありません。

2026年9月30日時点で確認したNIST SP 800-171r3は、米国連邦政府機関が非連邦組織との契約などで、管理対象非機密情報（CUI）の機密性を守るために使う想定のセキュリティ要求です。対象はCUIを処理、保存、送信する非連邦システムの構成要素などで、すべての会社やリリースフリーズへ一律に適用される規則ではありません。構成管理では、変更種別を定め、セキュリティへの影響を考慮して承認または却下し、実施・記録・監視・レビューするよう示します。変更を始める人を適格かつ権限を与えられた人に限り、アクセス制限の例に変更時間帯を挙げています。

繁忙期の経営判断では、この構成管理の考え方を変更種別、権限、時間帯、記録へ置き換えます。NIST所定の分類や義務ではなく、僕の提案です。

変更凍結台帳は、最低限、次の項目を一つの表で読めるようにします。

この表を埋めると、「繁忙期だから危ない」という曖昧な感覚が、「このシステムの通常変更は延期するが、この条件を満たす修正は責任者が承認できる」という判断に変わります。台帳の作成を開発部門だけに預けず、繁忙期を定義できる事業責任者と、変更の影響を説明できる技術責任者が同じ条件を確認することが要点です。変更を延期・再開する境界を業務影響から決める場合は、SLOを経営判断に変える方法にある代替手段、復旧期限、判断者の項目を台帳へつなげられます。

通常変更・修正・緊急変更を同じ承認にしない

フリーズ中の申請をすべて同じ会議へ載せると、小さな機能追加と事業継続に関わる対応が同列になります。逆に「修正なら通す」とだけ決めると、何を修正と呼ぶかで判断が揺れます。分類名に頼らず、目的、待てる理由または待てない理由、影響範囲、失敗時の戻し方で分けます。

次の判断表は、原典所定の分類・義務ではなく、僕の提案例です。

たとえば、繁忙期に予定していた画面改善は通常変更として延期します。一方、すでに発生している不具合への修正は、影響分析と責任者、切り戻し計画がそろった時点で個別に判断します。さらに、事業継続を脅かし、通常承認を待てない事象への変更だけを緊急経路へ進めます。分類名を申請者が選んで終わりにせず、承認者が条件との一致を確認する設計です。

2026年9月30日時点の英国政府によるService management good practiceは、英国の公共サービスネットワーク（PSN）に参加する組織が互いに期待するサービス管理を、ITILの用語で示した資料です。日本企業一般の法令や、あらゆる社内システムの義務ではありません。変更管理では、各変更に通常、承認者、実施責任者、変更時間帯、失敗時の切り戻し計画があるとします。緊急変更では承認なしで進める場合があり得る一方、影響先への通知に可能な限り努めるよう示します。判断表の「誰が、いつ、どう戻し、誰へ知らせるか」は、この原則を事業カレンダーへ落としたものです。

緊急変更を統制された例外にする

緊急時は、通常の承認会議を待つこと自体が問題になり得ます。急いでも責任の所在は消しません。緊急変更を「何でも通る区分」にせず、実施責任者、対象、理由、切り戻し方法、影響先への通知、実施後レビューを残す例外にします。記事で示すのは僕の実務案で、英国政府資料やNIST所定の分類・義務ではありません。

境界を定める問いは「通常経路を待てるか」です。待てるなら修正の個別承認へ戻し、待てないなら実施判断者、通知先、通常管理へ戻す時点も決めます。実施後は、成否、緊急とした理由、台帳や承認経路の修正要否をレビューし、NISTが示す実施・記録・監視・レビューの循環へ戻します。

責任者が技術上の影響を経営へ説明できず、経営者も待てない理由を評価できないなら、承認欄だけを増やしても判断は進みません。CTO代行を入れると、組織の意思決定はどう変わるのかで扱っているように、最終決裁者と判断材料を整える役割を分ける考え方が役立ちます。

リリースフリーズの解除日は条件を確認する

終了予定日は、解除を検討する日であって、自動的に通常変更を再開する日ではありません。繁忙のピークが過ぎても、変更後の状態を確かめる担当がいない、問題時に切り戻せない、通常時と違う負荷しか観測できない場合は、再開の判断材料が不足しています。

2026年9月30日時点で確認したGoogleのSRE Workbook「Canarying Releases」は、変更を一部へ限られた時間だけ適用して評価し、その結果から全面展開を続けるか判断する方法を説明しています。評価では、対象の規模、継続時間、利用量、時間帯、見る指標を検討し、利用が少ない時間だけでは高負荷時の性能問題を捉えにくいとしています。

経営者向けに置き換えると、全面再開の前に、影響を限定できる変更を一件だけ戻します。注文や申込みが集中する時間帯を含め、受付完了数、決済失敗、問い合わせの増加など、自社が守る業務の状態を担当者が見ます。悪化したら中止して戻せることまで確認してから、次の変更へ進みます。この解除ゲートは出典を基に僕が提案する実務上の方法で、Google、NIST、英国政府資料が定める解除条件や義務ではありません。

たとえば、繁忙期の終了予定日を迎えても、その日が閑散時間しか評価できないなら、通常変更の全面再開を自動決定しません。未反映変更は、次の順番で台帳を確認します。

1. 前提を再確認する：申込み件数、事業日程、仕様、外部サービス、担当者など、凍結前の前提が今も有効かを確かめる。
2. 依存が少ない変更を先にする：別の変更や外部サービスと同時でなければ評価できない変更は後ろへ置き、単独で結果を確認できるものから選ぶ。
3. 小さく戻せる変更を選ぶ：対象顧客、機能、時間帯を限定でき、問題時に元へ戻す手順と判断時刻があるものから再開する。
4. 監視担当がいる時間に実施する：見る業務指標、監視する人、中止を決める人、次の判断時刻を置き、担当が不在なら再開しない。

この四条件を満たす一件の結果を確認してから、次へ進みます。予定日前に繁忙ピークを過ぎても、同じ順番を飛ばしません。

停止期間、三つの変更区分、解除ゲート、再開順を同じ台帳へ置けば、開発を一律に止めず、繁忙期に守る事業と進められる変更の境界を決められます。

次の一手は、次の繁忙期の最終営業日を一つ選び、未反映変更の一覧から一件だけを変更凍結台帳へ移すことです。その一行へ、前提を再確認する日、依存先、小さく戻す手順、監視担当と見る業務指標を記入してください。一つでも空欄なら、終了予定日を自動再開日にせず、その欄の担当者を決めるところから始めます。