アプリ開発におけるフィーチャーフリーズとコードフリーズ：本質、違い、役割

フィーチャーフリーズとは？

フィーチャーフリーズは、計画されたリリース前にコードベースへの新機能追加を一時的に禁止するものです。チームは機能のマージを停止し、バグ修正、最適化、既存コードの洗練に切り替えます。開発者は不完全な機能を、スコープを拡大せずにバグ修正の範囲内でのみ完成させます。

フィーチャーフリーズは、リリースに間に合わないもののメインブランチに部分的にマージされてしまった進行中の機能の問題を解決します。新機能がマージされ続けると、リグレッションのリスクが高まります。各新規統合には、既に完成したモジュールの再テストが必要だからです。フィーチャーフリーズはリリースのスコープを固定し、動く標的から安定した機能セットに変えます。

重要な明確化：フィーチャーフリーズ ≠ コードフリーズ。フィーチャーフリーズ中は、バグ修正、リファクタリング、依存関係の更新、ドキュメント作成が許可されます。禁止されるのは、新しいユーザー向け機能のみです。つまり、ユーザーの視点からアプリケーションの動作を変更するコードです。コードレビューのチェック：PRが新しい画面、ボタン、APIメソッドを追加する場合、フリーズが解除されるまで拒否されます。

コードフリーズとは？フィーチャーフリーズとの違い

コードフリーズはより厳格なプラクティスであり、コードへのすべての変更が完全に禁止されます。重大でない限り、バグ修正でさえ許可されません。コードフリーズは短期間（通常24〜48時間）導入され、リリースビルドが固定されたコミットセットから構築されることを保証します。

フィーチャーフリーズとコードフリーズの違いは制御のレベルにあります。フィーチャーフリーズはスコープを管理します。リリースに何が含まれるかを決めます。コードフリーズは品質を管理します。リリース前日に新たなバグが混入するリスクを排除します。実際には、多くのチームが2段階モデルを使用しています。リリースの1〜2週間前にフィーチャーフリーズ、24〜48時間前にコードフリーズです。コードフリーズは、計画リリース日の数日前にビルドをストアにアップロードする必要があるモバイルアプリに特に重要です。

コードフリーズの例外は、重大な脆弱性のセキュリティ修正（CVEスコア9以上）です。そのような変更は、必須の高速コードレビューとチーム通知を伴う緊急プロセスを経由します。その他の変更はすべて次のリリースサイクルまで延期されます。

フィーチャーフリーズ vs コードフリーズ：比較

フィーチャーフリーズとコードフリーズの選択は、チームの成熟度とリリース頻度によって異なります。CI/CDとフィーチャーフラグを備えたチームは24時間のコードフリーズのみで済む場合がありますが、月次リリースのチームは両方のフリーズを順次使用することが多いです。

フリーズの種類：完全、部分、BAUフリーズ

完全なフィーチャーフリーズとコードフリーズ以外にも、より柔軟なオプションがあります。部分的なフィーチャーフリーズは、特定のモジュール（例えば支払いモジュールや認証モジュール）でのみ新機能をブロックし、他のコンポーネントは変更可能なままにします。

BAUフリーズ（business as usual freeze）は妥協案であり、変更量が一定のしきい値（例えば500行のコード）を超える大規模な機能のみが禁止されます。小さな改善、UI調整、バグ修正は引き続きマージされます。BAUフリーズは、1週間の完全な開発停止が経済的に非現実的な継続的デリバリーのプロジェクトに便利です。

デプロイフリーズ（deployment freeze）という概念もあります。これは本番環境へのデプロイを完全に停止するもので、ホリデーシーズン（クリスマス休暇、ブラックフライデー）に特徴的です。この期間中は、セキュリティ関連でない限りホットフィックスもブロックされます。デプロイフリーズは通常1〜2週間続き、企業レベルで調整されます。

フリーズの導入時期と期間

フィーチャーフリーズを導入する最適なタイミングは、コード完了後、計画されたすべての機能がマージされQAにかけられているときです。正確なタイミングはリリースサイクルによって異なります。2週間のスプリントの場合、フィーチャーフリーズはリリース日の3〜4日前に導入されます。月次リリースの場合は7〜10日前です。コードフリーズは計画されたリリースビルド時間の24〜48時間前に導入されます。

フリーズの期間はコードを安定させるための最小限で十分な長さでなければなりません。長すぎるフリーズ（2週間以上）はチームの意欲を低下させ、マージされていない機能の蓄積を生み、フリーズ解除後にそれぞれが競合のリスクを高めます。短すぎるフリーズ（フィーチャーフリーズで24時間未満）は、十分なテストと修正の時間を確保できません。

推奨されるプラクティスは、カレンダー日付ではなくコードベースの状態によってフリーズを設定することです。フィーチャーフリーズは、リリースの未解決バグ数がしきい値（例：10個の重大バグ）を超えたときに導入されます。コードフリーズは、ビルドがスモークテストとリグレッションスイートに合格したときに導入されます。時間ベースのフリーズ（固定日付）は、規制業界（フィンテック、メドテック）では依然として標準であり、リリース日が規制当局によって承認されています。

CI/CDとGitによるフリーズの自動化

手動のフリーズ管理はエラーの原因です。開発者が誤ってフリーズ解除を待つべきPRをマージしてしまう可能性があります。自動化はGitブランチ保護ルールとCI/CDパイプラインによってこれを解決します。Gitプロバイダー（GitHub、GitLab、Bitbucket）では、特別なタグやリリースマネージャーの承認なしにリリースブランチへのマージをブロックするルールが設定されます。

CI/CDパイプラインはビルド作成前にフリーズステータスをチェックします。Jenkins、GitLab CI、GitHub Actionsには、フリーズスケジュールを含む設定ファイルを読み取り、現在の日付がフリーズ期間内にある場合にビルドを拒否するステップが追加されます。別の方法として、管理パネルのフィーチャーフラグで本番環境へのデプロイをブロックすることもできます。

# .github/workflows/check-freeze.yml
name: Check Freeze Status
on:
  pull_request:
    types: [opened, synchronize]

jobs:
  check-freeze:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Check freeze status
        run: node .github/scripts/freeze-check.js
      - name: Block PR if frozen
        if: failure()
        run: echo "Feature freeze is active. PR blocked." && exit 1

サンプルのfreeze-check.jsスクリプトは、リポジトリルートからフリーズスケジュールのJSONを読み取ります。現在の日付が指定されたブランチのstart_dateとend_dateの間にある場合、パイプラインはフリーズステータスメッセージとともに失敗します。Gitブランチ保護は第二の障壁を追加します。パイプラインがトリガーされなかった場合でも、ルールは承認なしにPRのマージを許可しません。

フリーズ導入時のよくある間違い

最初の間違いは、明確な解除基準なしにフリーズを行うことです。チームはコードを凍結しますが、解除の条件（重大バグゼロ、リグレッションスイート合格、プロダクトマネージャーの承認）を定義しません。基準がないと、フリーズが何週間も続く可能性があります。フリーズの完了条件は文書化され、すべての開発者が知っているべきです。

2番目の間違いは、フリーズの例外が多すぎることです。それぞれの例外（「このPRは機能ではなく技術的負債です」）はフリーズの境界を曖昧にします。例外が通常のPRフローの20％を超える場合、フリーズは機能しません。チームはブロックを回避するために、機能をバグ修正として単に名前を変更します。

3番目の間違いは、リリース候補を無視することです。チームがリリース候補ビルドを作成せず、コードフリーズ後に直接本番環境にデプロイする場合、フリーズの目的は失われます。バグはユーザーによって発見されます。リリース候補はコードフリーズ前に作成され、QAとステージングでテストされ、品質確認後にのみコードフリーズが導入されるべきです。

4番目の間違いは、手動管理における人的要因です。開発者はマージ前にフリーズステータスの確認を忘れるかもしれません。リリースマネージャーは通知を見逃すかもしれません。唯一の信頼できる解決策は、GitプロバイダーまたはCI/CDレベルでの自動ブロッキングであり、人為的エラーを排除します。