ITシステムは、法改正への対応や業務フローの見直し、利用部門からの要望などにより、稼働後に仕様変更が必ず訪れます。外部に発注するときは、まず月額保守の範囲に入るかを切り分けて請負か準委任かを選び、変更管理と責任分担を決めてから委託先を選ぶのが基本の流れです。
この境界を曖昧にしたまま依頼すると、追加費用や引き継ぎ時の摩擦が生じることがあります。
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
ITシステム仕様変更対応を外注する前に押さえるべき全体像
仕様変更対応の発注では、まず保守契約の範囲かどうかを切り分けます。そのうえで、別途の制作作業として発注する変更かどうかも判断します。
この境界線を曖昧にしたまま発注すると、後から追加費用をめぐる認識のずれが生じることがあります。そこで、発注方法の話に入る前に、仕様変更という作業の性質と保守との関係を整理しておく必要があります。
仕様変更が「保守範囲外」とされる理由
月額保守に含まれるのは、一般にバグ修正と障害対応です。OSやミドルウェアの軽微なアップデート適用も、現状を保つための作業として含まれます。
- 仕様変更に当たる作業：大幅なデザイン変更や新機能の追加です。
- 切り分けの根拠：恣意的なものではなく、作業の性質が本質的に異なるためです。
業務ロジックの作り替えのような根本修正を伴うため、ほぼすべての保守事業者で範囲外とされ、別途の制作作業として追加費用が発生します。
現状維持の作業は予測しやすく、工数も安定します。これに対して仕様変更は、要件定義からテストまでを一通り行う小さな開発プロジェクトで、案件ごとに工数が変動します。
仕様変更まで固定の月額に含めることは、事業者にとって合理的ではありません。
発注者としては、この前提を理解したうえで「どこまでが保守で、どこからが別途発注か」を契約書で具体的に定義しておくことが、無用なトラブルを避ける第一歩になります。
委託先の種類と仕様変更対応への向き不向き
仕様変更対応の委託先は3つに分かれます。開発したベンダー、運用保守の専門会社、フリーランスやSES経由のエンジニアです。
- 既存ベンダー：内部仕様を熟知しているぶん改修品質が安定しやすい反面、ベンダーロックインで価格交渉が働きにくいという側面があります。
- フリーランスやSES：活用する場合、単価は平均で月額70万〜76万円前後が中心とされますが、注意したいのは総コストの視点です。
SESでは、エンジニアへの還元率が約6割で、企業側のマージン率は平均35〜40%という実態があります。そのため、表面の単価だけでなく、投入工数と生産性を見て判断する必要があります。
単価が高くても生産性の高いエンジニアのほうが、安価でも工数のかかる下請けより総額が安く済むケースは珍しくありません。
仕様変更のように既存システムの理解が品質を左右する作業では、この見極めがとりわけ欠かせません。
請負契約と準委任契約の選び方
仕様変更対応の発注で最初に決めるのは、契約形態です。
請負契約と準委任契約は、完成義務の有無、責任の所在、仕様変更への柔軟性が大きく異なります。そのため、どちらを選ぶかで、プロジェクトの進め方そのものが変わります。
仕様変更という作業の特性を踏まえ、自社の案件に合う契約形態を選ぶことが、発注をうまく進める要になります。
請負契約が適するケース
請負契約は、受託者が成果物を完成させる義務を負い、納品後に契約不適合（旧来の瑕疵担保）責任を負う契約形態です。
- 仕様が明確な変更：作るものの範囲を事前にはっきり定義できるなら、請負契約が適しています。
- ゴールが一意に定まる改修：「帳票のレイアウトを指定どおりに変更する」「特定の計算ロジックを法改正に合わせて修正する」などです。
請負契約のメリットは、完成責任が受託者にあるため、納品物が要件を満たさなければ修補や損害賠償を求められる点にあります。発注者にとって、成果が担保されやすい契約です。
契約締結後に要件が変わると、その都度変更契約や追加見積もりが必要になり、柔軟な仕様変更には不向きという弱点があります。
要件が固まりきらないうちに請負契約を結ぶと、後から発生する変更がすべて追加費用になり、かえって割高になることがあるため注意が必要です。
準委任契約が適するケース
準委任契約は、受託者が完成義務を負わず、善管注意義務（善良な管理者としての注意を払って業務を遂行する義務）に基づいて作業を行う契約形態です。
- 向いている案件：仕様が固まりきっていない案件や、継続的に変更が見込まれる案件に合います。作業そのものに対して対価を払う契約だからです。
- 業務要件が動きながら改修を重ねる案件：仕様変更対応のように、準委任のほうが柔軟に対応しやすいことが多いです。
準委任契約では、要件が変わっても契約の枠組みを変えずに対応を続けられるため、変更のたびに契約をやり直す手間が省けます。
完成義務がないということは、成果物の品質を発注者側がマネジメントしなければならないことを意味します。
そのため、発注者が変更管理や進捗管理に主体的に関わる体制が前提になります。継続的なアップデートや保守を伴う仕様変更対応では、準委任契約が選ばれる場面が多いといえます。
契約不適合責任と善管注意義務の責任設計
契約形態を選ぶうえで、責任の所在をどう設計するかは見落とされがちです。しかし、後々のトラブルに直結する部分でもあります。
- 請負の契約不適合責任：納品物が契約内容に適合しない場合に、受託者が修補や代金減額、損害賠償の責任を負います。
- 責任を問える期間と範囲：契約書で具体的に定めておく必要があります。
仕様変更の成果を明確に定義できるなら、この責任を発注者の保険として活用できます。
一方、準委任契約の善管注意義務は、作業のプロセスが適切だったかを問うものです。受託者が専門家として相応の注意を払って作業していれば、期待した結果が出なくても契約上の義務違反にはなりません。
準委任を選ぶ場合は、作業範囲や成果の基準、報告の頻度を契約に明記し、発注者側で品質を管理できる仕組みを整えることが、責任設計の要になります。
どちらの契約でも、責任の境界を曖昧にしないことがトラブル回避の鍵です。
変更管理プロセスを契約に組み込む発注方法
仕様変更対応の発注で最も差が出るのは、変更管理プロセスを契約や運用ルールに組み込めているかどうかです。
変更管理とは、変更要求を起票し、その影響を評価して承認し、反映して履歴を記録するまでの一連の手続きを指します。発注時点でこれを取り決めておけば、場当たり的な変更依頼による品質の低下や費用の膨張を防げます。
変更要求の起票から承認までの取り決め
変更管理を機能させるには、誰がどのような書式で変更を起票し、誰が承認するかを発注時に決めておく必要があります。
- 変更要求書による起票：変更の理由と対象範囲、業務影響と概算工数を書いてもらい、発注者側の責任者が承認したものだけを着手対象とします。
- 承認の仕組み：現場からの思いつきの依頼が無制限に流れ込むことを防げます。
承認の前段階として欠かせないのが、影響評価とリスク評価です。一見小さな修正でも、他の機能やデータ連携に波及することがあるからです。
変更は即座に本番環境へ反映せず、まず業務への影響と、適用しない場合のリスクを評価します。そのうえで是非を判断する手順を契約に盛り込むと、安定運用につながります。
発注時には、この評価フォーマットの提供を委託先に求めておくとよいでしょう。
バージョンの一元管理と履歴の追跡可能性
仕様変更を重ねていくと、設計書とソースコードの整合性が崩れ、いつ誰がどの理由で何を変更したのか分からなくなりがちです。
- 設計と実装のずれ：システムのブラックボックス化を招き、将来の改修コストを押し上げる大きな要因になります。
- 委託先に求める管理：設計書とソースコードのバージョンをまとめて管理し、変更理由と履歴を追える状態に保つことを、発注時に明記しておくべきです。
履歴を追える状態にしておくと、後から別のベンダーへ運用を移す際の引き継ぎコストを大幅に抑えられます。
変更履歴が特定の担当者だけに任されていると、担当者が替わった時点で経緯が失われ、再調査に膨大な工数がかかります。
発注の段階で、「変更管理台帳の提出」と「設計ドキュメントの更新義務」を成果物として位置づけておくことは、長期的なTCO（総保有コスト）の抑制に直結します。
スコープクリープを防ぐ発注の工夫
仕様変更対応の発注で発注者が最も悩まされるのは、当初の依頼範囲がいつの間にか膨らんでいく「スコープクリープ」です。
「ついでにここも直してほしい」という小さな追加が積み重なり、気づけば工数も費用も当初の想定を大きく超えてしまう現象です。
発注者は、発注の段階でスコープの境界を明確にしておき、追加が発生したときの扱いも取り決めておく必要があります。
月額保守内の改修枠の取り決め
仕様変更のうち軽微なものには、月額保守費の中に「改修枠」として一定の工数を確保しておく方法が有効です。
- 改修枠の上限：月あたり一定時間までの軽微な改修は保守費に含め、それを超える分は別途見積もりとする取り決めです。
- 保守費に占める割合：内訳では、軽微な改修・改善が全体の10〜15%程度を占めるとされます。
改修枠を明示しておくと、小さな変更のたびに見積もりを取り直す手間を減らせます。
改修枠を設けるときは、どこまでが枠内の軽微な改修で、どこからが枠外の仕様変更かを、あらかじめ合意しておく必要があります。判定が曖昧なままだと、結局そのつど交渉になり、枠の意味が薄れてしまいます。
できるだけ具体的な例で線引きしておくと、運用が安定します。たとえば、文言修正や設定値の変更は枠内、業務ロジックの変更や画面の新規追加は枠外、といった具合です。
見積もり段階での追加費用の境界線の確認
見積もりを取るときは、提示された金額が「開発費ベース」「工数積算」「機能ポイント法」のどの算出手法によるものかを確認します。
- 算出手法別の根拠：工数積算なら単価と想定工数の内訳を、機能ポイント法なら複雑さの評価基準を開示してもらうと、価格の妥当性を判断しやすくなります。
- 総額だけの見積もり：後から追加費用が発生したときに比較の基準を持てず、過剰請求に気づけません。
あわせて、見積もりに含まれない作業も明確にしておく必要があります。たとえば、時間外対応費や本番反映後の追加修正、テスト環境の準備費用などが別建てになっていないかを確認します。
保守費の内訳を精査して未利用のサービスを見つけた結果、月額28万円が20万円になり、約28.6%の削減につながった事例もあります。年間にすれば96万円の削減です。
見積もり段階で内訳を出してもらうことが、こうした適正化の出発点になります。
知的財産権の帰属と経理処理の取り決め
仕様変更対応では、成果物の知的財産権を誰に帰属させるかを決める必要があります。費用を経理上どう処理するかも、契約と会計にまたがる論点です。
これらを発注時に取り決めておかないと、後の運用移管や決算処理で思わぬ制約や負担が生じることがあります。そのため、情報システム部門だけでなく、経理や法務とも連携して整理しておきたいところです。
権利帰属の設計
改修で生まれたプログラムの著作権を発注者に帰属させるか、ベンダーに帰属させるかは、契約で明確に定めておく必要があります。発注者に帰属させれば、将来、別のベンダーへ運用を移す際の自由度が高まります。
- もう一つの選択肢：ベンダーに権利を帰属させる案もあります。
- 再利用の合理性：汎用的な改修部分を再利用して開発コストを下げ、結果として発注者の負担を軽くするという考え方に基づきます。
ベンダーが他案件でもソースコードを再利用できるため、全体の開発価格を抑えられる場合があります。ただし、自社固有の業務ノウハウが詰まった部分まで再利用可能にすると、競合への流出リスクが生じます。
そのため、再利用を認める範囲と、自社に独占的に帰属させる範囲を切り分けて契約に落とし込むことが、権利帰属の設計として賢明です。発注時に、この方針を委託先と擦り合わせておく必要があります。
修繕費と資本的支出の切り分け
仕様変更にかかった費用は、その内容によって経理上の扱いが変わります。
- 修繕費：障害の除去や現状維持の修正は、期間費用として計上できます。
- 見積もりとの照合：発注の段階で、改修が修繕費と資本的支出のどちらに当たるかを見積もりの内訳と照らしておくと、決算時の判断がスムーズになります。
一方、新機能の追加や性能向上を伴う改修は資本的支出です。原則として資産計上し、減価償却します。
資本的支出として資産計上する場合には、既存部分の除却という視点も知っておくと役立ちます。
既存機能を作り替える改修では、既存の資産計上部分を除却と捉える考え方があります。建物の一部を取り壊して建て直す場合と同じように、その分を費用として処理できる余地があります。
こうした会計上の扱いは発注額の見え方を左右します。そのため、見積もりを取る段階から経理担当を巻き込み、契約金額の内訳を機能単位で把握しておくことをおすすめします。
委託先の選定と発注後の体制づくり
契約形態と取り決めの方針が固まったら、どの委託先へ発注するかを選び、発注後の役割分担を整える段階に入ります。
仕様変更対応は一度きりで終わらず、システムが稼働し続ける限り繰り返し発生します。だからこそ、単発の安さよりも、変更管理に対応できる体制を持つパートナーを選ぶことが、長期的な適正化につながります。
相見積もりで比較すべきポイント
複数社から相見積もりを取るときは、金額だけでなく、料金体系の透明性、変更管理への対応力、準委任契約への柔軟性を比較の軸に据えます。
- 見積もりの出し方：同じ仕様変更でも、内訳を明示する会社と総額のみを提示する会社では、後の追加費用の見え方が大きく変わります。
- 開示の範囲：工数の根拠や担当エンジニアのスキルレベルを開示できる会社のほうが、発注後のコントロールがしやすくなります。
また、既存システムの理解度も比較の重要な観点です。設計書やソースコードを渡したときに、的確な影響範囲を示せる会社は、改修品質と工数精度の両面で信頼できます。
システムの内部を十分に把握しないまま安い見積もりを出してくる会社は、後から想定外の追加工数が発生するリスクが高いといえます。
価格の安さだけで決めず、総コストと品質のバランスで判断することが肝心です。
自社対応範囲と委託範囲の役割分担
発注後の体制づくりでは、どこまでを自社で担い、どこからを委託先に任せるかを、はっきりさせておく必要があります。
- 変更要求の扱い：整理、承認、優先順位づけは発注者が主導します。
- 準委任契約の場合：発注者が主体的にマネジメントへ関わる前提を、双方で共有しておく必要があります。
設計・開発・テストを委託先が担う分担を決めると、責任の所在がはっきりし、変更管理も安定します。
将来的に運用を内製化したり、別のベンダーへ移したりする可能性も、あらかじめ視野に入れておきます。
特定の委託先に依存しすぎると、いざ移管しようとしたときに引き継ぎコストが膨らみ、非協力的なベンダーであれば移管そのものが難航します。
発注の段階からドキュメントの整備と変更履歴の蓄積を委託条件に含めておくことが、ベンダーロックインを避け、将来の選択肢を確保するうえで有効です。
仕様変更対応の発注は、目先の改修だけでなく、システムを長く健全に保つための体制づくりでもあります。
仕様変更対応の進め方、費用、委託先選びは、関連記事でも確認できます。
ITシステム仕様変更対応の進め方では、変更要求の起票から反映までを解説します。
ITシステム仕様変更対応の費用相場では保守範囲外の費用構造を、ITシステム仕様変更対応でおすすめの開発会社では委託先比較の観点を扱います。
全体像を網羅的に把握したい方は、ITシステム仕様変更対応の完全ガイドをご参照ください。
まとめ
ITシステム仕様変更対応の発注・外注を成功させる鍵は、追加費用の境界線を曖昧にしないことに尽きます。
仕様変更は保守範囲外として別途費用が発生するのが原則です。その前提に立ち、請負と準委任のどちらが自社の案件に適するかを選ぶことが出発点になります。
成果物が明確なら請負を、要件が動きながら継続的に改修するなら準委任を選びます。そのうえで、契約不適合責任と善管注意義務のどちらで責任を設計するかも明確にします。
変更要求の起票から承認、バージョン管理までを、変更管理のプロセスに含めます。月額保守内の改修枠と見積もりの内訳を明らかにしておけば、スコープクリープと過剰請求を防げます。
知的財産権の帰属や、修繕費と資本的支出の切り分けも発注時に整理します。ドキュメントの整備を委託条件に含めれば、将来の運用移管にも備えられます。
発注前にこれらの観点を体系的に押さえておけば、想定外の追加費用に振り回されず、健全な仕様変更対応の体制を築けるはずです。
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。