システム開発の途中で仕様変更したい！どこまで変えていい？判断の物差しと進め方

開発が始まってから、現場の担当者に「やっぱりこの画面も欲しい」と言われた。システム開発の途中で仕様変更をしたくなるのは、決して珍しいことではありません。ただ、どこまでなら頼んでよくて、どこからが「迷惑な変更」なのか分からず、開発会社に切り出せずにいる発注者の方は多いものです。

先に結論をお伝えします。仕様変更に「ここまでならOK」という決まった線はありません。変えられるかどうかは、「今どの工程か」「変更がどこまで波及するか」「それが目的に対して本当に必要か」の3つで決まります。そして大切なのは、変更を我慢することではなく、影響（費用・納期・品質）を確認してから、正式な手続きで決めることです。

この記事では、現場から画面の追加を頼まれたケースを例に、仕様変更を判断する物差しと、開発会社への相談の進め方を解説します。

システム開発の途中で仕様変更が「タダでは済まない」理由

まず知っておきたいのは、仕様変更そのものは悪いことではない、という点です。業務を深く考えるほど新しい要望が出てくるのは自然なことですし、変えずに使いにくいシステムを完成させるほうが、よほどもったいない結果になります。

一方で、開発会社が変更に慎重になるのにも理由があります。開発会社側の事情を知っておくと、相談の仕方が変わります。

工程が進むほど「作り直す範囲」が広がる

システム開発は一般的に、要件定義（＝作るものを文章で決める工程）→ 設計（＝画面やデータの構造を決める工程）→ 開発（プログラミング）→ テスト、という順番で進みます。後ろの工程ほど、前の工程で決めたことの上に積み上がっています。

そのため、同じ「画面を1つ追加する」でも、どの工程で言い出すかによって手間が大きく変わります。

変更を言い出した時期	主に必要になる作業のイメージ	影響の大きさ
要件定義中	要望リストに1行足して検討する	小さい
設計中・設計完了後	画面設計・データ設計の見直し	中くらい
開発中	設計の見直し＋作ったプログラムの修正	大きい
テスト中・直前	上記に加えてテストのやり直し	かなり大きい

表はあくまで一般的な傾向で、実際の影響はシステムの作りによって変わります。ただ「早く言うほど安く済みやすい」という原則は、多くの開発現場で共通しています。

画面1つの追加が、見えないところに波及する

発注者から見ると「画面が1枚増えるだけ」でも、裏側では次のような作業が連鎖することがあります。

• 画面に表示・入力するデータを保存する場所（データベース）の追加・変更
• 誰がその画面を見られるか（権限）の設定
• 既存の画面との行き来（メニュー・リンク）の修正
• 他の機能に影響が出ていないかの確認テスト
• 操作マニュアルや研修資料の修正

「見た目は小さな変更でも、既存のデータや権限に関わると確認範囲が一気に広がるんです。まず『何のための画面か』を教えてもらえると、影響の少ない作り方を提案できます」

契約の形によって「変更の扱い」が違う

仕様変更の扱いは、契約の形によっても変わります。完成物を約束する請負契約（＝決めた仕様どおりに完成させることに対価を払う契約）では、仕様は契約の中身そのものなので、変更には正式な手続きが必要になるのが一般的です。

一方、途中で内容を変えていくことを前提にした開発手法もあります。

📰 出典：IPA（情報処理推進機構）「情報システム・モデル取引・契約書（アジャイル開発版）」

IPAはアジャイル開発（＝短い期間で作っては見直すことを繰り返す進め方）を、機能の追加・変更や優先順位の変更などに柔軟に対応できる手法と説明しており、このモデル契約書は、業務を行うこと自体に対価を払う準委任契約を前提としています。この場合でも「何でも自由に変えられる」わけではなく、決められた期間・予算の中で何を優先するかを入れ替えていく考え方になります。

自社の契約がどちらの形か分からない場合は、契約書を確認するか、開発会社に聞いてみましょう。契約の解釈で迷う場合は、弁護士などの専門家に相談するのが安心です。

仕様変更を「どこまで変えていいか」判断する3つの物差し

「変えていいかどうか」を一言で決めるのは難しいので、次の3つの物差しで整理してみてください。

物差し1：タイミング（今どの工程か）

先ほどの表のとおり、今どの工程にいるかで影響は大きく変わります。まずは開発会社のスケジュール表を見て、「今は設計中なのか、開発中なのか、テスト中なのか」を確認しましょう。

特にテスト中やリリース直前の変更は、スケジュール全体を動かすことになりやすい時期です。どうしても必要な修正以外は、リリース後に回す選択肢も検討する価値があります。

物差し2：影響範囲（どこまで波及するか）

変更の内容によって、影響の広さはおおよそ次のように分かれます。

変更の種類	例	影響の傾向
表示の調整	文言・ボタンの位置・色の変更	比較的小さいことが多い
項目の追加・変更	入力欄を1つ増やす、選択肢を増やす	データの持ち方次第で中程度に
画面・機能の追加	一覧画面や集計画面を新しく作る	中〜大。データ・権限・テストに波及
業務の流れの変更	承認の手順を変える、例外処理を足す	大きくなりやすい。設計の前提が変わる

「見た目の調整」と「業務の流れの変更」では、同じ仕様変更でも重さがまったく違います。自分の要望がどの種類に当たるかを意識するだけで、開発会社との会話がスムーズになります。

物差し3：目的との関係（それは本当に今必要か）

最後の物差しが一番大切です。その変更がないと、システムを作る目的が果たせないのか。それとも「あれば便利」なものなのか。

• 目的に直結する変更：業務の重要な例外が抜けていた、法令や社内ルール上必要だった、など。費用や納期に影響しても、入れる方向で検討する価値があります
• あれば便利な変更：今入れるより、リリース後に使ってみてから判断したほうが、本当に必要な形が見えることも多いです

現場から「画面を追加したい」と言われたときの進め方5ステップ

ここからは、現場の担当者から画面追加を頼まれたケースを例に、具体的な進め方を見ていきます。

ステップ1：要望の「背景」を現場に聞く

まずは「なぜその画面が必要なのか」を聞きます。画面そのものではなく、困っていることを確認するのがポイントです。

• その画面で何をしたいのか（見たい情報・やりたい作業）
• 今はどうやって対応しているのか
• 誰が・どのくらいの頻度で使うのか
• なかった場合、業務にどんな支障があるか

背景が分かると、「新しい画面を作らなくても、既存の一覧に絞り込みを付ければ済む」といった、影響の小さい別の方法が見つかることがあります。

ステップ2：社内で優先度を決め、決める人の了承を取る

要望を開発会社に伝える前に、社内で「必須か・あれば便利か」を整理し、予算や納期に影響した場合に誰が判断するのかを確認しておきます。

現場の要望をそのまま開発会社に渡すと、後から「その費用は出せない」と社内でひっくり返り、開発会社にも現場にも迷惑がかかります。窓口担当者と決裁者の間で、あらかじめ「どこまでなら追加予算を出せるか」の目安を話しておくと判断が早くなります。

ステップ3：開発会社に「決定」ではなく「相談」として伝える

開発会社には、「この画面を追加してください」ではなく、「こういう要望が出ているので、影響を教えてください」という相談として伝えます。背景や優先度も一緒に伝えましょう。

その上で、費用・納期・他の機能への影響を見積もってもらいます。影響の調査自体にも時間や工数がかかることがあるので、「いつまでに回答をもらえそうか」も確認しておくと安心です。

ステップ4：「入れる／入れ替える／後に回す」を比べる

影響が分かったら、次の選択肢を比べます。

選択肢	内容	向いているケース
今回入れる	費用・納期の調整を受け入れて追加する	目的に直結し、後回しにすると困る
入れ替える	優先度の低い別の機能を外して、代わりに入れる	予算・納期を動かせない
後に回す	リリース後の改修（第2弾）で対応する	あれば便利、または使ってみないと形が決まらない

「入れ替える」は見落とされがちですが、予算も納期も動かせない場合の有力な選択肢です。当初の要望リストを「必須」と「あれば嬉しい」に分けておくと、この判断がしやすくなります。

ステップ5：変更内容を書面に残して合意する

どの選択肢にするか決まったら、必ず書面（メールや変更の記録票など）で合意します。口頭だけの合意は、時間がたつと「言った・言わない」の原因になります。

📰 出典：IPA（情報処理推進機構）「情報システム・モデル取引・契約書（第二版）」

IPAが公開しているモデル契約書（第二版）では、仕様書等を変更したい場合、変更の内容や理由を書いた「変更提案書」を相手に渡し、受け取った側が「変更管理書」を作成して、両者の協議で変更の可否を決める流れが示されています。変更管理書には、次のような項目を書くことになっています。

• 変更の名称、提案の責任者、年月日
• 変更の理由
• 変更に関わる仕様を含む詳細
• 費用がかかる場合はその額
• 検討期間を含めた変更作業のスケジュール
• 納期・委託料・契約条項など、契約条件への影響

同じモデル契約書では、双方の責任者が変更管理書を承認した時点で変更が確定し、納期や委託料などの契約条件に影響する場合は、変更契約を結んだ時点で確定する形になっています。また、協議がまとまらない間は、事情によって開発会社側が作業を中断できるという定めもあります。

実際の契約がこのモデル契約書どおりとは限りませんが、「理由・中身・費用・スケジュール・影響」をそろえて合意するという考え方は、小さな案件でもそのまま参考になります。自社の契約書に変更の手続きがどう書かれているかも、この機会に確認しておきましょう。

仕様変更でやりがちな失敗パターン

• 現場の担当者が開発会社に直接お願いしてしまう：窓口を通さない変更は、費用や納期への影響が誰にも共有されないまま進みがちです。要望は必ず窓口担当者に集めるルールにしましょう
• 小さな変更を積み重ねてしまう：1つ1つは小さくても、積み重なると納期に響きます。変更は一覧にして、全体の影響を定期的に確認しましょう
• 「ついでにこれも」と要望を膨らませる：1つの変更の相談に、別の要望を次々と足すと、影響の見積もりがやり直しになります
• 決裁者への報告が後回しになる：追加費用や納期延長を、決める人が後から知ると話がこじれます。影響が分かった時点で共有しましょう
• 決まっていないことを黙って進める：開発開始時点でまだ決められない事項があるなら、最初から「未確定」と伝えておくのが大切です。IPAのモデル契約書（第二版）にも、未確定事項の内容と確定予定時期をあらかじめ書面で確認しておく定めがあります

発注者がやることチェックリスト

• ☐ 変更したい理由（現場の困りごと）を、画面や機能の名前ではなく言葉で説明できる
• ☐ 今プロジェクトがどの工程（設計・開発・テストなど）にいるか確認した
• ☐ 変更が「表示の調整」「項目の追加」「画面・機能の追加」「業務の流れの変更」のどれに近いか整理した
• ☐ 社内で「必須か・あれば便利か」を決め、決裁者に相談の予定を伝えた
• ☐ 開発会社に、費用・納期・他機能への影響を見積もってもらった
• ☐ 「今回入れる」「別の機能と入れ替える」「リリース後に回す」を比較した
• ☐ 決まった内容（理由・中身・費用・スケジュール）を書面で合意した
• ☐ 現場からの要望は窓口担当者に集めるルールを、社内に周知した

開発会社への質問例

仕様変更を相談するときに、そのまま使える質問です。

• 「現場からこういう要望が出ています。今の工程で対応した場合、費用・納期・他の機能への影響はどのくらいになりそうですか？」
• 「新しい画面を作る以外に、既存の画面を少し変えるなど、影響の小さい方法はありますか？」
• 「予算と納期を変えずに入れるとしたら、どの機能と入れ替えるのが現実的ですか？」
• 「今回は見送ってリリース後に対応する場合、今のうちに準備しておいたほうがいいことはありますか？」
• 「変更の相談は、どういう形（書式・窓口・回答までの期間）で出せばよいですか？」

最後の質問は、プロジェクトの早い段階で聞いておくのがおすすめです。変更のルールが最初に決まっていれば、いざというときに迷わずに済みます。

まとめ：仕様変更は「我慢」より「正しい手順」で決める

システム開発の途中で仕様を変えたくなるのは、自然なことです。大切なのは、変えるか変えないかを感覚で決めるのではなく、次の手順で判断することです。

• 3つの物差し（タイミング・影響範囲・目的との関係）で変更を整理する
• 現場の要望は背景から聞き、社内で優先度と決める人を確認する
• 開発会社には「決定」ではなく「相談」として伝え、影響を見積もってもらう
• 「入れる・入れ替える・後に回す」を比べて選ぶ
• 決まった内容は書面で合意する

仕様変更は、発注者と開発会社がより良いシステムを目指して話し合うきっかけにもなります。遠慮して黙っているより、早めに相談するほうが、結果的に双方の負担が小さくなります。

あわせて読みたい関連記事