システム開発を進めていくと、「やっぱりこうしたい」「この機能も追加してほしい」という要望が出てくるのは自然なことである。実際に動くものが見えてくると、最初は気づかなかった改善点が見えてくる。問題は、その変更を場当たり的に処理してしまうことである。「ちょっとした変更のつもり」が積み重なり、気づけば費用も納期も大きくふくらんでいた、という事態はよく起きる。

本記事は、仕様変更や追加要件をどう扱えばトラブルにならないかを、発注者の視点で整理する。読者として想定しているのは、中小企業の経営者、発注担当、管理部門である。変更そのものは悪いことではない。むしろ良いものを作るためには変更が必要なこともある。大切なのは、変更を扱う手順をあらかじめ決めておき、費用や納期への影響を双方で確認してから進めることである。なお、変更に伴う契約上の扱いや費用負担の判断には個別の事情が関わるため、最終的な判断は弁護士など専門家への確認を前提としていただきたい。

結論：変更を扱う手順を先に決めておく

仕様変更を上手に扱うには、変更が出てから慌てるのではなく、扱い方を先に決めておくことが重要である。GXOが発注者にすすめるのは、次の3点である。

  • 変更が出たときの手順（誰が判断し、どう記録するか）を先に決めておく
  • 変更が費用・納期にどう影響するかを確認してから進める
  • 口頭で済ませず、変更の内容と合意を記録に残す

変更管理の仕組みがあると、変更そのものを止めることなく、影響を把握しながら進められる。場当たり的に処理しないことが、後の対立を防ぐ鍵になる。

なぜ変更管理が重要か

システム開発における変更は、機能を一つ足すだけでも、関連する箇所の修正やテストが必要になることが多い。見た目には小さな変更でも、影響が広がることがある。これを把握せずに次々と受け入れると、費用と納期が制御できなくなる。

変更管理が不十分だと、次のような問題につながりやすい。

  • 「ちょっとした変更」が積み重なり、当初の予算を大きく超える
  • 変更の影響で納期が延びるが、その認識が共有されていない
  • 口頭の依頼が記録されず、後で「言った・言わない」になる

変更管理は、開発を予算と納期の中に収めるための仕組みである。もとの合意がはっきりしているほど、変更の判断もしやすい。要件定義の合意の残し方は要件定義でもめないための準備も参考になる。

変更管理のプロセスを決める

変更が出たときの流れを決める

変更を場当たり的に受けず、決まった流れで扱うようにしたい。たとえば、変更の依頼、影響の確認、費用・納期の合意、実施、という流れを定めておくと、抜けが減る。

段階内容
依頼変更したい内容を具体的に伝える
影響の確認費用・納期・他機能への影響を開発会社が見積もる
合意影響を確認したうえで、進めるか判断する
実施・記録合意した内容を記録し、実施する

誰が判断するかを決める

変更のたびに社内で判断が割れると、開発が止まる。変更を判断する窓口を一本化しておくと、進めやすい。

追加費用の決め方を取り決める

仕様変更には、追加の費用が発生することがある。費用の決め方を先に取り決めておくと、変更が出るたびに揉めずに済む。

  • 見積もりの方法：変更ごとに見積もるのか、工数の単価をもとに算定するのか。
  • 判断の基準：いくらまでは窓口で判断し、いくらを超えたら稟議に回すのか。
  • 無償か有償か：当初の要件の解釈の範囲なのか、新たな追加なのかの線引き。

特に「当初の要件に含まれるか、新たな追加か」の線引きは、認識がずれやすい。発注者は「当然含まれているはず」と考え、開発会社は「新たな追加だ」と考える、というように、立場によって受け止め方が分かれることがある。もとの要件定義がはっきりしているほど、この判断はしやすくなる。逆に、要件が曖昧なままだと、変更が出るたびにこの線引きで議論が紛糾しやすい。だからこそ、要件定義の段階で「何をどこまで作るか」を明確にしておくことが、変更管理を楽にする。スコープの考え方は契約書で確認すべき項目も参考になる。

合意を記録に残す

変更管理で最も重要なのは、合意を記録に残すことである。口頭でのやり取りは、後から振り返れず、認識のずれを生む。

  • 変更の内容を、依頼の時点で文書にする
  • 費用・納期への影響と、それに対する合意を記録する
  • 実施した変更を、もとの要件の記録に反映する

記録があれば、開発の途中でも、何をどう変えてきたかを振り返れる。検収のときにも、当初の要件と変更後の状態を照らし合わせやすくなる。

変更管理でよくある失敗

変更管理では、次のような失敗が起きやすい。いずれも、進め方を先に決めておけば避けられる。

  • 口頭で受けてしまう：軽い気持ちで口頭の依頼を受け、記録がないまま進む。
  • 影響を確認せずに進める：費用や納期への影響を見ずに変更を受け入れ、後で超過に気づく。
  • 窓口がばらばら：複数の担当者がそれぞれ変更を依頼し、全体が把握できなくなる。
  • 線引きを決めていない：当初要件か追加かの基準がなく、費用負担で対立する。

変更は止める必要はないが、影響を確認し、記録に残しながら進めることが大切である。

変更管理のチェックリスト

仕様変更が出たときに慌てないよう、次の点を発注前に決めておきたい。決めておくこと自体が、変更を冷静に扱うための備えになる。

  • 変更が出たときの手順（依頼→影響確認→合意→実施）を決めたか
  • 変更を判断する社内の窓口を一本化したか
  • 費用の見積もり方法（個別見積もり／工数単価）を取り決めたか
  • 窓口で判断できる金額の範囲と、稟議に回す基準を決めたか
  • 当初要件か新たな追加かの線引きの考え方を共有したか
  • 変更の内容と合意を記録に残す仕組みを用意したか
  • 変更が納期に与える影響を確認する流れを決めたか

これらが決まっていれば、変更が出たときに「どう扱うか」で迷わずに済む。逆に、何も決めずに変更を受け続けると、費用も納期も制御できなくなる。

発注者として変更にどう向き合うか

仕様変更は、発注者側の都合で出ることもあれば、開発を進める中で見えてきた改善として出ることもある。どちらの場合も、「本当に今、その変更が必要か」を一度立ち止まって考えたい。導入の目的に直結する変更なのか、あれば望ましい程度のものなのかで、優先度は変わる。

すべての要望をその場で取り込もうとすると、開発が膨らみ、肝心の目的の達成が遅れることがある。今回の開発では見送り、運用が安定してから次の段階で取り組む、という判断も選択肢である。変更の取捨選択を、目的と予算・納期に照らして冷静に行うことが、プロジェクトを成功に近づける。検収の段階での確認の進め方は検収・契約不適合責任も参考になる。

関連記事

よくある質問

Q1. 仕様変更は、どこまでなら無償でやってもらえますか

無償か有償かは、当初の要件の解釈の範囲に収まるか、新たな追加にあたるかによる。この線引きは案件ごとに異なり、契約や要件定義の記録に左右される。判断が難しい場合は、もとの要件と照らし合わせ、必要に応じて専門家にも確認するとよい。

Q2. 開発の途中で大きく方針を変えたくなったらどうすればよいですか

大きな方針変更は、費用や納期に大きく影響することが多い。まず変更したい内容を具体的に伝え、影響を見積もってもらったうえで判断したい。場合によっては、いったん区切りをつけて改めて契約し直す進め方が現実的なこともある。

Q3. 変更のたびに見積もりをもらうのは手間ではないですか

変更ごとに見積もりを取るのは手間に感じるかもしれないが、影響を把握せずに進めるリスクのほうが大きい。少額の変更は窓口で判断できる範囲を決めておくなど、運用を工夫すれば、手間と管理のバランスを取れる。

仕様変更の扱い方を、発注前に整理しませんか

GXOでは、システム開発で避けられない仕様変更や追加要件について、変更管理の進め方、追加費用の考え方、合意の記録の残し方を整理し、費用と納期を制御しながら進めるための準備をご支援します。

変更管理の進め方を相談する

※ 初回相談では、営業資料の説明よりも現状整理とリスク確認を優先します。