コードフリーズの期間の決め方｜連休前の線引き

2026 10/28

2026年10月28日

「年末だから、来週からコードフリーズで」——この一言で決まった凍結期間が、根拠を持っていたことはあるでしょうか。

慣習で1週間。実際には回帰テストが1周しきらず、凍結明けに不具合が残る。あるいは逆に長すぎて、止める必要のない改修まで年明けに押し出される。どちらも受託開発でよく見ます。

この記事は、コードフリーズの期間を感覚ではなく逆算で決めるための記事です。コードフリーズの期間を決めるのは、連休の長さではなく、回帰テストが1周するのにかかる時間です。

なお、本記事はPMが決める運用の線引きの話で、ブランチ戦略やタグ運用といった実装寄りの手順は扱いません。

コードフリーズが形だけになる3つの理由

凍結を宣言したのに守られない現場には、共通点があります。

例外の条件が決まっていない：「緊急なら入れていい」とだけ決まっていて、何が緊急かの線がなく、結局ほぼ全部が入ります
凍結の対象が曖昧：アプリのコードだけ止めて、設定値・マスタデータ・外部連携先の変更は素通りします
期間の根拠がない：慣習で決まった日付なので、守る理由を誰も説明できません

凍結が骨抜きになる原因のほとんどは、例外の線引きを事前に決めていないことです。

逆に言えば、期間・対象・例外の3つを先に決めれば、凍結は宣言どおりに機能します。順に決めていきます。

期間はリリース判定日から逆算する

コードフリーズの期間は、前から数えるのではなく、リリース判定日から後ろ向きに引くと決まります。

リリース判定日から再テスト枠・回帰テスト1周を遡ってコードフリーズ開始日を決める逆算の図

必要なのは3つの材料だけです。

材料	何を見るか	典型的な見落とし
回帰テスト1周の所要	対象範囲を1周流すのに何営業日かかるか	手動部分の実行時間だけ数え、結果確認と起票を入れ忘れる
再テストの枠	見つかった不具合を直して再確認する期間	ここをゼロで引いてしまい、修正が出た瞬間に破綻する
判定と準備の枠	リリース判定会議と当日作業の準備	判定日＝リリース日にしてしまい、余裕がない

この3つを足した日数が、リリース判定日から遡る日数になります。凍結開始日＝リリース判定日 −（回帰1周＋再テスト枠＋判定準備）です。

連休前であれば、ここに「連休で作業できない日数」を足します。つまり連休の長さは期間そのものではなく、カレンダー上の空白として効いてくるだけです。

回帰テストの範囲をどう絞るかで、この1周の日数は大きく変わります。考え方は回帰テストスコープ決定術が参考になります。

計算例｜コードフリーズの期間を実際に引いてみる

数式だけでは手が動かないので、年末リリースを例に引いてみます。設定は「12月26日（金）にリリース判定、12月27日（土）から休暇」とします。

工程	所要	日付
リリース判定会議・当日準備	2営業日	12/25（木）〜12/26（金）
再テスト枠（修正と再確認）	3営業日	12/22（月）〜12/24（水）
回帰テスト1周	5営業日	12/15（月）〜12/19（金）
コードフリーズ開始	—	12/15（月）0:00

合計10営業日、つまり判定日のちょうど2週間前が凍結開始になります。慣習の「1週間前から」で始めていた場合、回帰テストが1周しきらないまま判定日を迎えることが、この計算だけで分かります。

ここで出た日付が慣習の日付とずれていたら、そのずれ幅がそのまま今回のリリースのリスクです。

期間が長すぎる・短すぎるときに動かす場所

逆算した結果が現実的でないとき、動かす先は決まっています。

長すぎる場合：回帰テストの対象範囲を絞ります。期間ではなく範囲を削るのが先です
短すぎる場合：再テスト枠を削るのは最後にします。ここを削ると、不具合が1件出た瞬間に計画が崩れます
どうしても足りない場合：リリース範囲そのものを削ります。凍結期間を縮めて品質を落とすより、出す機能を減らすほうが回復可能です

削る順番は「範囲 → リリース機能 → 再テスト枠」で、逆順にはしないでください。

何を凍結し、何を例外にするか

期間が決まったら、次は対象です。「コード」だけを止めても、品質は固まりません。

対象	凍結するか	理由
アプリケーションのコード	する	言うまでもなく中心
設定ファイル・環境変数	する	挙動が変わる。コードと同じ扱いが要る
マスタデータ・初期データ	する	テスト済みの前提が崩れる
外部連携先の仕様変更	止められないので把握する	自社で止められない。連絡を受ける窓口を決める
ドキュメント・文言の修正	しなくてよい	動作に影響しないものまで止めると不満が溜まる

凍結対象から設定値とマスタデータが漏れている現場は非常に多く、ここから事故が出ます。

例外は3つの問いで判定する

例外（ホットフィックス）を認めるかどうかは、その場の空気ではなく問いで決めます。

業務停止級か・回避策があるか・凍結明けまで待てるかの3問で例外可否を判定するフロー図

その不具合は業務を止めるか：止めないなら、原則として凍結明けに回します
回避策はあるか：運用で回避できるなら、まず回避策を案内します
凍結明けまで待てないか：待てるなら待ちます。待てない理由を言語化できるかが判定の肝です

3つすべてで「例外にすべき」となった場合だけ投入し、投入したら回帰テストをどこまでやり直すかもセットで決めます。ここを決めずに入れると、凍結の意味がなくなります。

判定そのものの進め方はリリース判定チェックリスト｜GO/NO-GOで揉めない判断軸と揃えておくと、会議が短くなります。

凍結中こそテストの本番

よくある誤解が、「凍結＝全部止まる」という受け取り方です。止まるのは変更であって、テストはここからが本番です。

凍結期間にやることは決まっています。

回帰テストを止まった状態のビルドで1周流す
残っている不具合の再テストを消化する
リリース判定に必要な材料（消化率・残件・未解決の内訳）を揃える
リリース手順と切り戻し手順を、実際に手を動かして確認する

凍結の価値は、変更が止まった状態でテストできることそのものにあります。動き続けるコードを追いかけるテストは、何周しても終わりません。

逆に、凍結中にテストの手が足りず回帰が1周しきらないのであれば、凍結期間ではなく体制側に問題があります。終盤の判断軸はリリース直前にテストが間に合わない時の判断軸と乗り切り方で扱っています。

連休・年末前に固有の注意

長期休暇をまたぐ場合、通常のリリースとは違う配慮が3つ要ります。

休み中に人がいない：障害が起きても調査できる人員が限られます。当番と連絡手段、エスカレーション先を事前に文書化します
切り戻しの判断者が捕まらない：誰が不在でも切り戻せるよう、判断基準を事前に決めておきます
休み明けの初日が最も危ない：溜まったバッチ、月またぎ・年またぎの処理、再開時の負荷が一度に来ます

休み明けの初日は「リリースしない日」として空けてください。立ち上がりの確認に充てる日です。

日付をまたぐ処理の確認観点は日付・時刻のテスト観点｜見落としがちな境界と時差に整理があります。障害が起きた場合の動き方はシステム障害時のトラブル初動対応手順を、休暇期間の体制づくりそのものについてはIPAが公開する長期休暇前後の対策も参考になります。

そもそも凍結しない選択はあるか

ここまで凍結する前提で書いてきましたが、凍結が適さない現場もあります。週に何度もリリースするような体制では、長い凍結はむしろ害になります。

判断の目安は次のとおりです。

状況	向いている進め方
リリースが月1回以下・手動テストが中心	凍結する。変更を止めないと回帰が終わらない
週次以上・回帰テストの大半が自動化済み	凍結せず、リリース単位で範囲を区切る
連休・年末など長期間の無人期間をまたぐ	頻度にかかわらず凍結する。直せない期間があるため

凍結するかどうかを分けるのは開発手法ではなく、回帰テストが変更に追いつけるかどうかです。

自動化が進んでいない状態で「うちはアジャイルだから凍結しない」とすると、テストが永遠に追いつきません。逆に自動化が効いている現場で長期凍結をかけると、ただ出荷が遅れるだけになります。

ただし長期休暇だけは例外です。どれだけ自動化されていても、異常時に人が対応できない期間がある以上、入れる変更は絞るべきです。

凍結を伝えるときに書く5項目

最後に通知です。口頭やチャットの一行で済ませると、必ず「聞いていない」が出ます。

項目	書く内容
期間	開始日時と解除日時。日付だけでなく時刻まで
対象	コード・設定・マスタデータなど、止めるものを列挙
例外の条件	前述の3つの問い。誰が判断するかも明記
申請先	例外を出したいときの連絡先と手順
解除後の予定	いつから通常運用に戻るか。順番待ちの扱いも

とくに解除後の予定は忘れられがちです。これがないと、凍結中に止められた改修の担当者が、いつ出せるか分からないまま待つことになります。

用語の社内統一が必要な場合は、JSTQBが公開するシラバス・用語集でテスト工程の呼び名を揃えておくと、通知の表現もぶれにくくなります。

まとめ：コードフリーズの期間は逆算で決まる

コードフリーズの期間を慣習で決めている限り、守る理由は生まれません。この記事で決めたのは次の4点です。

決めること	要点
期間	リリース判定日から「回帰1周＋再テスト枠＋判定準備」を遡って決める
対象	コードだけでなく設定値とマスタデータも止める
例外	業務停止級か・回避策はあるか・明けまで待てるかの3問で判定する
連休時	当番と切り戻し基準を文書化し、休み明け初日はリリースしない

まず次のリリースで、凍結開始日を逆算で出してみることだけでも試してみてください。慣習の日付とずれていたら、それがそのまま今回のリスクです。

逆算した結果、回帰テストが1周しきらないことがはっきりした場合は、期間ではなく体制の問題です。テスト体制の見直しについてのご相談はお気軽にどうぞ。