開発途中の仕様変更にどう対応するか：追加費用と優先順位の決め方

システム開発の途中で仕様変更が起きるのは、失敗ではなく自然なことです。実際に画面を触って初めて分かる使いにくさや、開発中に変わる事業の状況は、どれだけ丁寧に要件定義をしても完全には防げません。問題になるのは変更そのものではなく、変更の受け付け方とお金の決め方がルール化されていないことです。

結論から言うと、仕様変更で予算と納期を崩さないためには、三つのルールを開発の最初に決めておくことが有効です。一つ目は、変更要求を必ず記録に残すこと。二つ目は、実施を決める前に費用と納期への影響を見積もること。三つ目は、何かを足すなら何かを削る、または後回しにする「代替削減」を基本にすることです。

この記事は、システム開発を外注している発注側の担当者や、新規事業でMVPを開発中の事業責任者に向けて書いています。仕様変更がなぜ追加費用につながるのか、変更要求をどう記録し判断するのか、優先順位をどう決めるのか、そして契約形態によって何が変わるのかを、手順と判断基準の形で整理します。

仕様変更はなぜ起きるのか

仕様変更を前向きに扱うためには、まず変更が起きる理由を知っておくと役に立ちます。主な理由は次の四つです。

一つ目は、要件定義の段階で想像しきれなかった使い方が、実物を見て分かるケースです。文章や画面設計書では問題なさそうに見えた入力手順が、実際に操作すると手間が多いと分かることはよくあります。

二つ目は、事業や業務の状況が変わるケースです。開発期間中に取引先の要望が変わった、法令や社内規程が改定された、競合サービスの動きを見て優先度を変えたくなった、といった外部の変化は避けられません。

三つ目は、関係者の認識がそろっていなかったケースです。要件定義の場にいなかった部署が、テストの段階で初めてシステムを見て、「この項目がないと業務が回らない」と指摘することがあります。

四つ目は、技術的な制約が後から判明するケースです。連携先のシステムの仕様が想定と違った、外部サービスの機能に制限があった、などの理由で、作り方や画面の動きを変えざるを得ないことがあります。

このうち、一つ目と二つ目は「良い変更」になりうるものです。価値の高いシステムに近づくための変更であれば、受け入れる価値があります。三つ目と四つ目は、事前の準備で減らせる変更です。関係者を早めに巻き込む、連携先の仕様を早めに確認する、といった予防策で発生を抑えられます。

仕様変更で追加費用が発生する仕組み

仕様変更で追加費用が発生するのは、開発会社の都合ではなく、作業量が実際に増えるからです。たとえば画面の項目を一つ増やすだけでも、画面の表示、入力チェック、データベースの項目、関連する帳票や一覧、テストのやり直しなど、影響は複数の箇所に及びます。

影響の大きさは、変更のタイミングによっても変わります。要件定義の段階で項目を追加するなら、書類を直すだけで済みます。設計が終わった段階なら、設計書と関連する画面の見直しが必要です。開発が終わってテストに入っている段階なら、作ったものを壊して作り直し、テストもやり直すことになります。同じ変更でも、後になるほど手戻りが大きくなるのです。

この表から分かるのは、変更の判断を早めるほど負担が小さくなるということです。発注側ができる最大の工夫は、変更の種を早い段階で見つけることです。画面の試作品やデモを早めに見せてもらい、関係者に触ってもらうことが、結果的に追加費用を抑える近道になります。

変更要求を記録する：変更管理表の作り方

仕様変更をめぐるトラブルの多くは、「言った・言わない」から始まります。定例会で口頭で伝えた変更が実装されていない、あるいはいつの間にか実装されていて追加費用を請求された、という事態です。これを防ぐ基本は、変更要求を一件ずつ記録に残すことです。

記録の形式は、表計算ソフトでもチケット管理ツールでも構いません。大切なのは、次の項目がそろっていることです。

「変更理由」の欄は特に重要です。理由が書けない変更は、思いつきである可能性が高く、優先度を下げて考えるべきです。また、後から振り返ったときに「なぜこの仕様になっているのか」を説明する材料にもなります。

影響を見積もってから判断する手順

変更要求を記録したら、すぐに実施を決めるのではなく、影響を見積もってから判断します。次の手順で進めると、判断がぶれにくくなります。

1. 変更要求を起票する：発注側の担当者が、変更内容と理由を変更管理表に書きます。現場からの要望も、担当者が一度受け止めてから起票します。
2. 開発会社に影響を見積もってもらう：影響範囲、追加工数、費用、納期への影響を回答してもらいます。小さな変更でも見積もりは必ず取ります。
3. 代替案を検討する：同じ目的を、より小さな変更で達成できないかを開発会社と一緒に考えます。画面を新しく作る代わりに既存の画面に項目を足す、自動化の代わりに当面は手作業で運用する、といった選択肢がよく出ます。
4. 実施の要否と方法を決める：実施する、何かを削って実施する、見送る、次期の改修に回す、のどれかを決めます。
5. 決定を記録し、関係者に共有する：判断日と判断者を記録し、開発会社と社内の関係者に伝えます。

見積もりに時間がかかる大きな変更の場合、その見積もり作業自体に工数がかかることもあります。見積もり作業の扱いについても、開発会社と事前に確認しておくと安心です。

契約形態による扱いの違い

仕様変更の扱いは、契約形態によって大きく変わります。

請負契約では、契約時に合意した仕様が完成の基準です。変更はその基準を動かすことになるため、変更内容と追加費用を書面で合意する「変更契約」の手続きが必要になるのが一般的です。小さな変更でも、記録と合意を省くと、検収のときに「どこまでが契約範囲か」で揉める原因になります。

準委任契約では、決まった期間と体制で作業を行うため、その範囲内であれば優先順位の入れ替えで柔軟に対応できます。ただし、稼働量が増えるわけではないので、足した分だけ他の作業が後ろにずれます。変更管理表に「何を後ろにずらしたか」も記録しておくと、後で予定との差を説明しやすくなります。

どちらの契約形態でも、変更の受け付け方を契約書や開発の進め方の取り決めに書いておくことが重要です。契約形態そのものの選び方は、請負契約と準委任契約の選び方で詳しく扱っています。

変更の大きさに応じて判断者を決めておく

すべての変更を経営層が判断していては、意思決定が追いつきません。逆に、現場の担当者が大きな変更まで決めてしまうと、予算の管理ができなくなります。そこで、変更の大きさに応じて判断者を分けておくと運用が回りやすくなります。

基準となる工数や金額はプロジェクトごとに決めて構いません。大切なのは、誰が判断するかで迷う時間をなくすことです。

優先順位の決め方：何を足して何を削るか

予算と納期が決まっている中で変更を受け入れるには、「足すなら削る」という代替削減の考え方が欠かせません。そのためには、すべての機能に優先順位がついていることが前提になります。

優先順位をつけるときは、機能を「なければリリースできないもの」「あると大きく助かるもの」「あれば便利なもの」「今回は作らないもの」の四つ程度に分けると判断しやすくなります。いわゆるMoSCoW分析の考え方です。変更要求が来たら、その変更がどの区分に当たるかを決め、より低い区分の機能と入れ替えられないかを検討します。

判断の基準としては、次の観点が使えます。

• その変更がないと、リリースの目的が達成できないか
• 利用者や現場の業務に与える影響はどれくらい大きいか
• 当面は手作業や運用の工夫で代替できないか
• リリース後に改修しても間に合わないか
• 変更しないことで、後からより大きな手戻りが発生しないか

最後の観点は見落とされがちです。たとえばデータベースの構造に関わる変更は、後回しにすると、溜まったデータの移行まで必要になり、かえって高くつくことがあります。画面の見た目や文言の変更は後からでも比較的容易に直せますが、データの持ち方や権限の考え方は早めに決めた方がよい、という目安を持っておくと判断しやすくなります。

機能の優先順位のつけ方は、MVPの機能の絞り方でも詳しく説明しています。

架空の例：予約システム開発での仕様変更

ここでは架空の例で、仕様変更の扱い方を見てみます。

ある整体院のチェーンが、店舗ごとに電話で受けていた予約をWebで受け付けるシステムを開発しているとします。開発の終盤、受付スタッフに試作品を触ってもらったところ、「同じ人が家族の分もまとめて予約したいことが多い」という声が出ました。家族の分をまとめて予約する機能は、要件定義の段階では想定していませんでした。

発注側の担当者はこの要望を変更管理表に起票し、開発会社に影響を見積もってもらいました。回答は、予約画面と予約データの構造、確認メールの文面、管理画面の一覧表示に影響し、テストのやり直しを含めて相応の工数がかかる、というものでした。リリース日も後ろにずれます。

そこで代替案を検討しました。家族の分をまとめて予約する機能の代わりに、予約完了画面に「続けて別の方の予約をする」ボタンを置き、氏名以外の入力を引き継ぐ形にすれば、影響は予約画面だけに限られます。さらに、当初予定していた「予約一覧のCSV出力機能」は、当面は管理画面から確認できれば足りるため、次期に回すことにしました。こうして、利用者の不便を大きく減らしつつ、予算とリリース日を守ることができました。

この例のポイントは、要望をそのまま実装するのではなく、目的を確認したうえで小さな代替案を探し、さらに何かを後ろに回して全体の枠を守ったことです。

仕様変更を減らすために発注側ができる準備

仕様変更を前向きに扱うことと、不要な変更を減らすことは両立します。次のチェックリストは、開発が始まる前や序盤に発注側が確認しておきたい項目です。

• システムを使う部署・役職の関係者を、要件定義の段階で洗い出したか
• 実際に使う現場の担当者に、画面設計や試作品を見てもらったか
• 業務の流れを、例外的なケースも含めて開発会社に説明したか
• 連携する外部システムや外部サービスの仕様を確認したか
• 必ず作る機能と、余裕があれば作る機能を分けたか
• 変更要求を誰が受け付け、誰が判断するかを決めたか
• 変更管理表の置き場所と書き方を開発会社と合意したか
• 予算のうち、変更に備える余裕をどれくらい持つかを社内で決めたか

最後の項目について補足すると、変更が起きる前提で、予算の一部を予備として確保しておくのが現実的です。どの程度確保するかはプロジェクトの性質によって違いますが、新規事業のように不確実性が高いほど多めに見ておくべきです。予備費を最初から使い切る前提にしないことも大切です。

予備費を社内で説明するときは、「何に使うためのお金か」を明確にしておくと承認を得やすくなります。たとえば、試作品を見た現場からの改善要望、連携先の仕様確認で判明した追加対応、テストで見つかった想定外の業務パターンへの対応、といった具体的な使い道を挙げておきます。使わなかった予備費は、リリース後の改善に回せることも伝えておくと、予備費を持つこと自体への抵抗が減ります。

要件の固め方については、要件定義書の書き方も参考にしてください。

よくある失敗と避け方

現場の要望をそのまま開発会社に伝えてしまう

現場の担当者が、発注側の責任者を通さずに開発会社のエンジニアへ直接要望を伝えてしまうケースです。エンジニアが善意で対応すると、記録が残らないまま範囲が広がり、後から追加費用や納期遅れとして表面化します。要望の窓口は一本化し、必ず変更管理表を通す運用にします。

小さな変更だからと見積もりを取らない

「文言を変えるだけ」「項目を一つ足すだけ」と考えて見積もりを省略するケースです。一つひとつは小さくても、積み重なると大きな工数になります。また、見た目は小さな変更でも、内部では広い範囲に影響することがあります。小さな変更ほど、まとめて定例会で判断する習慣をつけると負担を抑えられます。

判断を先延ばしにする

変更の要否を決めないまま開発が進むと、開発会社は保留のまま作業を進めるか、手を止めて待つしかありません。どちらも無駄が生じます。判断者を決め、定例会で必ず結論を出すようにします。結論が出せない場合は、判断の期限を決めて記録に残します。

削る判断ができない

足すことには合意できても、削ることには誰も合意しない、というのはよくある状況です。結果として、予算と納期だけが膨らみます。「この変更を入れるなら、どの機能を次期に回すか」という問いを、変更の検討とセットで必ず行うルールにします。

決まった変更を仕様書に反映しない

変更管理表では実施を決めたのに、要件定義書や画面設計書などの元の資料を更新しないケースです。時間がたつと、どれが最新の仕様なのか誰にも分からなくなり、受入テストや将来の改修で混乱します。変更を実施したら、関連する資料のどこを直したかまで記録し、定期的に資料と実際のシステムがずれていないかを確認します。資料の更新を開発会社に任せる場合も、更新の範囲を作業内容に含めておきます。

よくある質問

Q. 仕様変更の追加費用はどうやって妥当性を判断すればよいですか？

まず、影響範囲と工数の内訳を説明してもらいましょう。どの画面・機能に、どれくらいの作業が発生するかが分かれば、妥当かどうかを判断しやすくなります。内訳を聞いても判断がつかない場合は、代替案での見積もりを依頼し、比較するのも有効です。

Q. 開発会社が仕様変更をなかなか受けてくれません。どうすればよいですか？

開発会社が慎重になるのは、変更の影響が大きい、あるいは納期が厳しいなどの理由があることが多いです。まずは理由を聞き、影響を小さくする方法を一緒に考えましょう。変更の進め方が契約に決まっていない場合は、変更管理のルールを改めて合意することから始めます。

Q. リリース直前に重大な問題が見つかった場合も、次期に回すべきですか？

業務が回らない、データが壊れる、セキュリティ上の問題がある、といった重大な問題は、リリースを延期してでも直すべきです。一方、使い勝手の改善や、あると便利な機能の追加であれば、リリース後の改修に回す方が全体の負担は小さくなります。

Q. 変更管理表はどの程度の規模のプロジェクトから必要ですか？

規模にかかわらず、外部の開発会社に依頼するなら作っておくことをおすすめします。小さなプロジェクトであれば、表計算ソフトに十数行並ぶ程度でも十分に役立ちます。

Otsumuに相談できること

変更管理のルールを決め、変更管理表を開発会社と一緒に運用できる体制が社内にあれば、多くの仕様変更は自社だけで十分に扱えます。本記事の手順とチェックリストを、まずは次の定例会から取り入れてみてください。

一方で、変更要求が多すぎて優先順位がつけられない、何を削ってよいか社内で合意できない、そもそも何を作るべきかが揺れている、という状況では、変更の手続きよりも「目的に対して何が必要か」を整理し直すことが先です。この整理は、事業と開発の両方を理解した第三者が入ると早く進みます。

Otsumuは、自らも事業を手がける実践者として、目的から逆算して必要な機能に絞り込み、構想から開発・運用・改善まで一気通貫で支援しています。開発プロジェクト全般はシステム開発、検証段階で範囲を絞って作りたい場合は新規事業の爆速MVPシステム開発をご覧ください。具体的なシステムの例として、予約システム開発のページもあります。

「今の変更要求をどう整理すればよいか」という相談でも構いません。30分の無料相談で、状況をお聞かせください。

この記事について

Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。

執筆：Otsumu株式会社 ／ 編集日 2026.10.01