「ここをもう少し変えてほしいんですが」——この依頼がリリース3日前に来たとき、PMはどう返しますか。
受け入れれば品質が崩れるかもしれない。断れば関係が悪化するかもしれない。この板挟みに毎回悩むのは、仕様凍結を事前に合意できていないからです。
仕様凍結は、PMが一方的に「もう変更は受け付けません」と宣言するものではありません。いつまでに何を決めれば品質とスケジュールを守れるかを、顧客と一緒に確認するプロセスです。この記事では、仕様凍結を伝えるタイミングと内容を整理します。
仕様凍結を伝えないと何が起きるか
リリース直前の変更がなぜ問題になるかを整理しておきます。
テストが完了した後に仕様が変わると、テストをやり直す必要があります。コードを書き直すだけでなく、テスト設計・実行・確認の工数がそのまま発生します。品質保証のフローが崩れると、見落としが増えます。
スケジュールへの影響も直結します。「少しの変更」に見えても、影響範囲の確認から始まり、設計・実装・テストすべてが動きます。これが繰り返されると、リリース日が現実的ではなくなってきます。
仕様凍結は顧客への制限ではなく、品質を守るための段取りです。この目的を共有できていれば、顧客も理解しやすくなります。
伝えるタイミング
仕様凍結を伝える最適なタイミングは、設計フェーズの終盤か、開発開始のタイミングです。「これ以降は仕様を変えません」という宣言ではなく、「この段階から変更が発生すると影響が大きくなります」という形で伝えます。
プロジェクト計画書やキックオフ資料に仕様凍結の時期を記載しておくと、後で口頭で説明するより受け入れられやすくなります。顧客が「そういう約束でしたね」と認識していれば、凍結後の変更依頼に対しても「これは変更管理のフローで対応します」と言いやすくなります。
伝える内容1：目的
「なぜ仕様を凍結するのか」を先に説明します。
「凍結後に変更が発生すると、設計・実装・テストのやり直しが必要になり、リリース日と品質に影響が出ます。品質を守るために、この段階までに仕様を固めさせてください」
制限ではなく、守るためのルールとして伝えるのがポイントです。
伝える内容2：対象範囲
「何が凍結の対象か」を明確にします。
機能要件（画面・操作・処理フロー）は凍結対象にするのが一般的です。UIの細かいデザイン調整やテキスト修正は運用フェーズで対応できるものもあるため、範囲を明確にしておきます。
「凍結対象は〇〇ページの機能要件で、文言や配色は引き続き調整可能です」という形で線引きをしておくと、顧客も「何が変えられて何が変えられないか」が分かります。
伝える内容3：例外条件
仕様凍結後でも対応が必要なケースはあります。バグ・セキュリティ対応・法律的な要件の変更などです。
「以下の場合は凍結後でも対応します」という形で例外を明示しておくと、顧客も「バグは出しても大丈夫」と安心できます。逆に「追加機能・仕様変更は変更管理フローで対応します」という線引きも明確になります。
凍結後の変更扱い
それでも変更依頼が来た場合の対応を決めておきます。
最低限伝えることは次の2点です。
- 変更が発生した場合は工数・コスト・スケジュールへの影響を確認する
- 顧客の承認を得てから対応に入る
「変更は受け付けません」ではなく「変更の影響を確認してから対応します」という姿勢です。変更自体を否定するのではなく、影響を可視化した上で判断するプロセスに乗せます。
まとめ
仕様凍結を直前に宣言するのは、顧客にとっても受け入れにくいです。設計フェーズの終盤か開発開始時に「目的・対象範囲・例外条件・変更時の扱い」をセットで伝えることで、後の変更管理がずいぶん楽になります。
契約や法律的な判断は個別の状況によりますので、この記事はPMの実務運用として参考にしてください。
受託開発PM実務や仕様管理を学びたい方は、受託開発PM向けの課題別パックや炎上予防・立て直しパックをご覧ください。