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