システム開発を外部に発注したものの、開発が進むにつれて「それは仕様変更なので追加費用がかかります」とベンダーから言われる場面が増えてきた——。当初の見積もりから費用がどんどん膨らみ、社内で予算超過の説明を求められて頭を抱えている、という発注担当者の方は少なくありません。最初に提示された金額を信じて社内稟議を通したのに、最終的な請求額がそれを大きく上回ってしまうと、発注担当者としての立場も難しくなってしまいます。
費用が膨らむたびに「次こそは同じ轍を踏みたくない」と思うものの、いざ対策を考えると「そもそも、どこからが追加費用なのか」「どうすれば費用が際限なく増えるのを止められるのか」が分からず、打ち手が見えないまま次の打ち合わせを迎えてしまいがちです。ベンダーや先輩から「仕様凍結」という言葉を聞いて意味を調べ始めた方も多いのではないでしょうか。
仕様凍結は、こうした追加費用の膨張を防ぐための重要な仕組みです。ただし、その効果を本当に引き出せるかどうかは、発注者側が「いつ・何を・どこまで固めるか」を理解し、契約前から主導権を握れるかにかかっています。言葉の意味を知っているだけでは、費用はコントロールできません。仕様凍結を「ベンダーがやってくれるもの」と受け身で捉えているうちは、追加費用の問題は繰り返されてしまいます。
本記事では、仕様凍結の定義と必要な理由をわかりやすく整理したうえで、仕様変更がなぜ追加費用に直結するのかという構造を分解し、発注者が契約前・凍結前・凍結後の各段階で握るべき具体的な合意手順を解説します。読み終えたとき、次のベンダーとの打ち合わせで「費用をコントロールするための仕様凍結」を、自分から切り出せる状態を目指します。
システム開発の費用を正しく理解するガイドブック――相場・見積チェックリスト・予算策定テンプレート付き
この資料でわかること
発注検討者がシステム開発の費用体系を正しく理解し、「この見積は適正か」「どのくらい予算を確保すれば良いか」を自分で判断できるようになること。
こんな方におすすめです
- システム開発の発注を初めて担当する方
- 複数社の見積もりを比較・評価したい方
- IT投資の社内稟議を通す根拠を固めたい方
入力いただいたメールアドレスにPDFをお送りします。
仕様凍結とは？開発で「仕様を確定させる」合意のこと
まずは仕様凍結という言葉の意味を正確に押さえておきましょう。言葉のイメージだけで理解していると、後の費用コントロールの議論で誤った前提を持ってしまうおそれがあります。
仕様凍結の基本的な定義
仕様凍結とは、発注者（ユーザー）とベンダー（開発会社）が、これ以上は仕様の追加・変更をしないと合意し、確定した仕様をもとに後続の工程へ進むことを指します。英語では「スペックフリーズ（spec freeze）」とも呼ばれ、開発の途中で「ここから先は仕様を固める」という線を引く行為だと考えるとイメージしやすいでしょう。
ここで重要なのは、仕様凍結が単なる開発側の宣言ではなく、発注者とベンダー双方の「合意」であるという点です。一方的に「もう決まったことにします」と通告するものではなく、両者が確定した内容を確認し、納得したうえで次の工程に進むためのプロセスなのです。この「合意」という性質が、後ほど説明する費用コントロールの土台になります。
裏を返せば、発注者が内容を十分に確認しないまま「とりあえず進めてください」と任せてしまうと、それは本当の意味での仕様凍結にはなりません。発注者自身が「この仕様で確定する」と判断し、その判断に責任を持つからこそ、後から「そんなつもりではなかった」という認識のズレを防げるのです。
仕様凍結を行うタイミング
システム開発は一般的に、要件定義 → 基本設計 → 詳細設計 → 開発（実装） → テスト という工程の流れで進みます。仕様凍結は、このうち要件定義から設計が完了する段階で行われるのが一般的です。
なぜこのタイミングなのかというと、要件定義と設計は「何を作るか」を決める工程だからです。ここで決まった内容をもとに、ベンダーは実際のプログラムを組み、画面を作り、テストの項目を設計します。つまり、設計が固まった時点で仕様を凍結することで、開発以降の工程は「確定した仕様を形にする作業」に専念できるようになります。
逆に言えば、開発が始まってから仕様が動き続けると、すでに組んだプログラムを作り直すことになりかねません。だからこそ、開発に着手する前の節目で仕様を確定させることに大きな意味があります。
なお、すべての仕様を一度に凍結しなければならないわけではありません。大規模なプロジェクトでは、画面ごと・機能ごと・サブシステムごとに段階的に仕様を確定させていくこともあります。重要なのは「いつ・どの部分の仕様を確定させるのか」を発注者とベンダーの間で共有し、確定したものから順に手戻りの心配なく開発へ進めていくことです。自社のプロジェクトでどのような凍結の進め方が適しているかは、規模や開発の進め方に応じてベンダーと相談して決めるとよいでしょう。
「凍結」が意味すること・意味しないこと
「凍結」という言葉の響きから、「一度凍結したら、もう一切変更できなくなるのではないか」と心配される方もいます。しかし、これは誤解です。
仕様凍結が意味するのは、「これ以降の変更は、無条件・無制限には受け付けない」ということであって、「未来永劫いかなる変更も認めない」ということではありません。実務では、凍結後にどうしても必要な変更要望が出てくることは珍しくありません。法改正への対応や、市場環境の変化、テスト段階で発覚した想定外の問題など、後から変更が必要になる理由はいくらでもあります。そうした変更を、あらかじめ決めた手続きに沿って扱えるようにするのが、健全な仕様凍結の姿です。凍結後の変更をどう扱うかについては、本記事の後半で詳しく説明します。
ここではまず、仕様凍結が「変更を完全に禁止する仕組み」ではなく、「変更を無秩序に受け入れない仕組み」であると理解しておいてください。この理解があれば、「凍結を提案すると柔軟性がなくなるのでは」という不安を持たずに、仕様凍結を前向きに活用できるようになります。
仕様凍結が必要な理由｜なぜ追加費用とスケジュールの起点になるのか
仕様凍結の定義がわかったところで、次に「なぜ凍結が必要なのか」を、発注者の最大の関心事である費用の観点から見ていきましょう。
手戻りを防ぎ、開発の方向性を固定する
仕様が固まらないまま開発を進めると、作っている途中で「やっぱりこの機能はこう変えたい」という要望が次々と出てきます。そのたびに、すでに完成しかけていた部分を作り直す「手戻り」が発生します。
手戻りは、開発チームの工数を二重三重に消費します。一度作ったものを壊し、設計し直し、また作る——この繰り返しが、スケジュールの遅延とコストの増加を同時に引き起こします。たとえば、ある画面の入力項目を一つ追加するだけでも、データベースの設計、入力チェックの処理、関連する他の画面、テスト項目と、影響は思いのほか広範囲に及びます。仕様凍結は、開発の方向性を固定することで、この手戻りの連鎖を断ち切る役割を果たします。
見積もり・スケジュールの根拠を確定させる
発注者にとって、仕様凍結のもっとも大きな意味は、見積もりとスケジュールの「根拠」が確定することにあります。
ベンダーが提示する見積もり金額や納期は、確定した仕様を前提に算出されています。「この機能をこの範囲で作るなら、これだけの工数と期間が必要」という計算が、見積もりの土台になっているわけです。つまり、凍結された仕様こそが、見積もりの根拠そのものなのです。
ここが費用コントロールの核心です。仕様が確定しているからこそ、「ここまでが見積もりの範囲」「ここから先は追加」という線引きが、感情論ではなく客観的な基準として成立します。凍結という基準点があるからこそ、追加費用の発生もその根拠が明確になり、発注者・ベンダー双方が納得できる形で費用を管理できるのです。逆に、何が確定した仕様なのか不明瞭なままでは、どこからが追加なのかを巡って「言った・言わない」の水掛け論になりやすく、費用の見通しが立ちません。発注者にとって、確定した仕様書は「この金額でここまで作ってもらえる」という約束の証でもあります。
仕様凍結をしないとどうなるか
仕様凍結を行わないまま開発を進めると、費用は際限なく膨らんでいきます。
仕様が確定していないため、開発途中の要望はすべて「もともと想定していたこと」なのか「新しい追加」なのかの判断がつきません。ベンダーは要望を受け入れるたびに工数を投入しますが、その分のコストをどう扱うかが曖昧なまま進みます。結果として、プロジェクトの終盤になって「想定外の工数がかかったので追加費用を」という請求が次々と発生したり、納期が大幅に遅れたりします。
さらに深刻なのは、仕様が動き続けることでプロジェクト全体のゴールが見えなくなり、「いつまでたっても完成しない」状態に陥るケースです。発注者は追加費用を払い続け、ベンダーは終わりの見えない開発に疲弊し、最終的に双方が不信感を募らせて関係が破綻してしまうこともあります。仕様凍結なきプロジェクトでは、こうした費用とスケジュールの膨張が構造的に起こりやすくなります。発注者が当初の予算と納期を守りたいのであれば、仕様凍結は避けて通れない仕組みだといえます。
仕様変更で追加費用が増える構造
ここからは、本記事の中核となる「仕様変更がなぜ追加費用に直結するのか」という構造を、工程の流れに沿って分解していきます。この構造を理解すると、自社の状況で「どこで費用が発生しているのか」を診断できるようになります。
仕様変更が手戻り工数を生む仕組み
仕様変更が追加費用を生む最大の理由は、すでに完了した工程の「手戻り」を引き起こすからです。
システム開発では、要件定義の成果物をもとに設計を行い、設計をもとにプログラムを実装します。各工程は前の工程の成果物の上に積み上がっているため、上流の仕様を変更すると、その下流のすべての工程に影響が及びます。たとえば、開発の終盤で要件レベルの変更が入ると、設計のやり直し、プログラムの作り直し、テスト項目の再設計と、広範囲の手戻りが連鎖的に発生します。
重要なのは、工程が進めば進むほど、変更にかかるコストが大きくなるという点です。要件定義の段階での変更なら、まだ紙の上で直すだけで済みます。しかし、開発やテストの段階まで進んでからの変更は、すでに作り込んだものを壊して作り直す必要があり、その分の工数が追加費用として跳ね返ってきます。「同じ変更でも、いつ言うかで費用が大きく変わる」というのが、システム開発の費用構造の本質です。家を建てる場面に置き換えると、図面の段階で部屋の配置を変えるのは簡単ですが、すでに柱や壁ができあがってから「やっぱり間取りを変えたい」と言えば、解体して作り直す費用がかかるのと同じことです。
「言った・言わない」が追加費用トラブルを招く
追加費用を巡るトラブルの多くは、変更の指示や合意が記録に残っていないことから生じます。
打ち合わせの場や、ちょっとした会話の中で「ここはこうしてほしい」と口頭で伝えた内容が、後になって「言った・言わない」の争いになるケースは非常に多く見られます。発注者は「最初からお願いしていた」と認識し、ベンダーは「それは新しい追加要望だ」と認識する——この認識のズレが、追加費用の妥当性を巡る不信感やトラブルへと発展します。とくに、メールではなく電話や対面の会話だけで指示を伝えていると、後から内容を確認するすべがなく、双方の記憶頼みになってしまいます。
口頭でのやり取りに頼ることがなぜ危険なのか、その具体的なリスクについてはシステム開発で口頭指示が危険な理由で詳しく解説しています。追加費用のトラブルを避けるうえで、記録の重要性はいくら強調してもしすぎることはありません。
凍結がないと「どこからが追加費用か」が曖昧になる
ここまで見てきた手戻りと「言った・言わない」の問題は、いずれも「確定した仕様がない」ことに根があります。
仕様凍結という明確な基準点がなければ、ある変更が「もともとの仕様の範囲内」なのか「凍結後の新しい追加」なのかを判断する物差しがありません。物差しがないまま追加費用の話をすると、ベンダーは「これは追加です」と主張し、発注者は「いや、これは当然含まれているはずだ」と反論し、双方が納得できないまま交渉が長引きます。
逆に、仕様凍結によって「ここまでが確定した仕様」という線が引かれていれば、その線を超える変更は客観的に「追加」だと整理できます。追加費用の発生そのものをゼロにはできなくても、「なぜ追加なのか」「どこから追加なのか」が明確になり、発注者は費用の発生を予測しコントロールできるようになります。仕様凍結は、追加費用を巡る曖昧さを取り除くための基準点なのです。
仕様凍結を成功させるためのポイント｜発注者が契約前に握ること
追加費用が増える構造がわかったところで、いよいよ実践です。発注者が費用をコントロールするために、契約前・凍結前に握っておくべきポイントを3つに整理します。
凍結のタイミングと範囲を契約・要件定義の段階で合意する
もっとも重要なのは、「いつ仕様を凍結するのか」「どの範囲を凍結するのか」を、開発が始まってからではなく、契約や要件定義の段階であらかじめベンダーと合意しておくことです。
開発が進んでから「そろそろ仕様を固めましょう」と切り出すのでは遅すぎます。すでに認識のズレが生じていたり、なし崩し的に仕様が動き続けていたりするからです。理想は、契約時点で「設計完了の時点で仕様を凍結する」という節目を双方で確認し、その節目に向けて要件と設計を詰めていくことです。プロジェクトの計画段階で「この日までに仕様を確定する」というマイルストーンをスケジュールに組み込んでおくと、関係者全員が同じゴールに向かって動けます。
凍結の範囲についても、「機能の一覧」「画面の構成」「処理の流れ」など、何を確定対象とするのかを具体的に握っておきましょう。範囲が曖昧なまま凍結したつもりになると、結局「それは凍結に含まれていなかった」という新たな争点を生んでしまいます。発注者が主導権を持って、凍結のタイミングと範囲を早期に合意することが、費用コントロールの第一歩です。
凍結内容を書面化し、記録に残す
凍結した仕様は、必ず書面（ドキュメント）として記録に残し、発注者とベンダーの双方で内容を確認したうえで合意の証跡を残してください。口頭やその場の了解だけで済ませてはいけません。
書面化すべき理由は明快です。記録に残っていれば、後から「どこまでが確定した仕様だったのか」を客観的に確認でき、「言った・言わない」のトラブルを未然に防げるからです。要件定義書・設計書といった成果物のどのバージョンを凍結対象とするのかを明示し、双方が署名や承認の形でその内容に合意した事実を残しておきましょう。メールやプロジェクト管理ツール上で「この仕様で確定する」という承認のやり取りを残しておくだけでも、後の認識のズレを大きく減らせます。
記録を残さずに口頭で進めることがどれほどのリスクを生むかは、先ほど触れたシステム開発で口頭指示が危険な理由でも解説しています。凍結内容の書面化は、発注者自身を守るための保険でもあります。
追加費用そのものを防ぐ発注者側の具体策
凍結のタイミングと範囲を握り、内容を書面化する——この2つに加えて、発注者には追加費用そのものを抑えるためにできることがいくつもあります。
たとえば、要件定義の段階で関係者の要望を可能な限り洗い出し、後出しの変更を減らすこと。社内の意思決定者を早期に巻き込み、凍結後に「やっぱり別の部署からこんな要望が」という事態を防ぐこと。そして、ベンダーとのコミュニケーションを記録に残す習慣を徹底することなどです。とくに、現場の担当者だけで仕様を決めてしまい、後から上司や他部署の意見で覆るというパターンは追加費用の典型的な原因です。仕様を凍結する前に、関係する部署すべてのレビューを受けておくことが、後出しの変更を防ぐ鍵になります。
こうした追加費用を防ぐための具体的な発注者側の対策は、仕様変更で追加費用が発生する原因と防止策で体系的にまとめています。仕様凍結とあわせて取り組むことで、予算超過のリスクを大きく減らせます。
仕様凍結後に変更が必要になったらどうするか
仕様を凍結しても、開発を進める中で「どうしてもこの変更が必要だ」という場面は実際に出てきます。ここでは、凍結後の変更にどう向き合えばよいかを説明します。「凍結したら変更できない」という不安を抱えたまま凍結を先送りにするのが、もっとも避けたい事態です。
凍結後の変更は「事前に決めたプロセス」で扱う
凍結後の変更要望は、「全部受け付けない」か「全部受け入れる」かの二択で考えるものではありません。健全なのは、凍結する前の段階で「凍結後に変更が必要になったら、どういう手続きで扱うか」をあらかじめ取り決めておくことです。
具体的には、変更要望が出たときに、その内容を変更要求書として文書化し、ベンダーが影響範囲（必要な工数・費用・スケジュールへの影響）を評価し、その評価をもとに発注者とベンダーが対応するかどうかを再合意する——という一連の流れを決めておきます。これを変更管理プロセスと呼びます。
変更管理プロセスをあらかじめ設計しておけば、凍結後に変更が必要になっても慌てることはありません。決められた手続きに沿って、追加費用や納期への影響を確認したうえで、納得して判断できます。変更管理の具体的な進め方は変更管理・仕様変更プロセスとは？で詳しく解説しています。
軽微な変更と仕様変更の線引きをどう考えるか
「ボタンの文言を直す程度の軽微な変更まで、いちいち変更管理にかけるのか」という疑問を持つ方もいるでしょう。
実務では、変更の影響度に応じて扱いを分けるのが現実的です。たとえば、追加の工数がほとんど発生しない軽微な修正は、その都度の合意で柔軟に対応し、一定の工数や費用が発生する変更は変更管理プロセスにのせる、といった線引きをあらかじめベンダーと決めておくとスムーズです。
大切なのは、その線引きの基準を凍結前に両者で握っておくことです。基準が決まっていないと、結局「これは軽微か、仕様変更か」を巡って毎回もめることになります。「○時間以内の作業は軽微な修正として扱う」といった目安をあらかじめ共有しておくと、判断の迷いが減ります。線引きの基準まで含めて合意しておくことで、凍結後の運用が円滑になります。
凍結後の追加費用に納得感を持たせる進め方
凍結後の変更に追加費用が発生すること自体は、決して悪いことではありません。問題なのは、その費用が「いつの間にか」「説明もなく」発生することです。
変更管理プロセスに沿って進めれば、変更要望ごとに「この変更にはこれだけの工数と費用がかかります」という見積もりが事前に提示されます。発注者はその内容を確認したうえで、変更を実施するか、見送るか、別の方法を検討するかを判断できます。追加費用の発生が予測可能になり、発注者の意思決定のもとで進むため、後から「こんな請求は聞いていない」という事態を防げます。
凍結後の追加費用に納得感を持たせる鍵は、費用を発生させないことではなく、費用を「見える化」し、発注者が判断できる状態を保つことにあります。これこそが、仕様凍結と変更管理プロセスをセットで運用する最大のメリットです。発注者は、限られた予算の中で「どの変更に優先的にお金を使うか」を主体的に選べるようになり、本当に必要な機能に投資を集中できます。
まとめ｜仕様凍結は発注者の費用コントロール手段
仕様凍結とは、発注者とベンダーがこれ以上の仕様の追加・変更をしないと合意し、確定した仕様をもとに後続工程へ進むことです。それは開発側の都合のためだけの仕組みではなく、発注者が追加費用をコントロールするための強力な手段です。
仕様凍結という基準点があるからこそ、「どこまでが見積もりの範囲で、どこからが追加費用なのか」が客観的に整理でき、費用とスケジュールの膨張を防げます。逆に凍結がなければ、手戻りや「言った・言わない」のトラブルによって、費用は際限なく膨らんでいきます。
発注者として、次のアクションは明確です。
- 仕様凍結のタイミングと範囲を、契約・要件定義の段階でベンダーと合意する
- 凍結した仕様は必ず書面化し、双方の合意の証跡を記録に残す
- 凍結後の変更をどう扱うか（変更管理プロセス・軽微な変更との線引き）をあらかじめ取り決めておく
この3つを押さえておけば、次のベンダーとの打ち合わせで、追加費用をコントロールするための仕様凍結を主導的に切り出せるはずです。仕様凍結は決して発注者を縛るものではなく、むしろ予算と納期を守りながら、本当に必要なものに投資を集中させるための味方になります。追加費用を防ぐための発注者側の具体策については、仕様変更で追加費用が発生する原因と防止策もあわせてご覧ください。仕様凍結を正しく使いこなし、予算と納期を守れる発注を実現していきましょう。
システム開発の費用を正しく理解するガイドブック――相場・見積チェックリスト・予算策定テンプレート付き
この資料でわかること
発注検討者がシステム開発の費用体系を正しく理解し、「この見積は適正か」「どのくらい予算を確保すれば良いか」を自分で判断できるようになること。
こんな方におすすめです
- システム開発の発注を初めて担当する方
- 複数社の見積もりを比較・評価したい方
- IT投資の社内稟議を通す根拠を固めたい方
入力いただいたメールアドレスにPDFをお送りします。
