ITシステムの仕様変更対応をベンダーに任せるとき、後々のトラブルを左右するのが「仕様変更をどう依頼し、どう契約に落とし込むか」という要件定義とRFP（提案依頼書）の作り込みです。仕様変更は新規開発と違い、依頼内容が曖昧なまま「とりあえず直して」と頼まれることが多く、その結果、認識のズレや追加費用の押し付け合いが起きがちです。だからこそ、仕様変更対応を発注する側こそ、変更要件と契約条件を明文化する力を持つ必要があります。
本記事は、ITシステムの仕様変更対応に関するRFP・要件定義書・提案依頼書の作り方を、発注企業の視点から掘り下げる解説です。仕様変更を見据えた保守RFPの作り方、曖昧な変更要望を実装可能な要件へ翻訳する方法、対応範囲と責任分界点を契約で明確にする方法、そしてSLAや対応時間を数値で定義する方法まで、運用保守の一次データとあわせて具体的に解説します。読み終えるころには、ベンダーに提示すべき要件の骨子が描けるはずです。なお、仕様変更対応の全体像をまだ把握していない方は、まずITシステム仕様変更対応の完全ガイドから読むことをおすすめします。
▼全体ガイドの記事
・ITシステム仕様変更対応の完全ガイド
仕様変更を見据えた保守RFPの作り方
仕様変更対応のRFPは、新規開発のRFPとは観点が異なります。新規開発が「何を作るか」を問うのに対し、仕様変更対応のRFPは「作った後、どう変更を受け付け、どう対応するか」という継続的な体制を問うものです。リリースした瞬間から業務は変わり始めるため、変更対応の体制をどう確保するかをRFPの段階で明示しておくことが、後の安心につながります。
軽微改修の枠と追加見積もりの線引きを明記する
RFPで必ず定めておきたいのが、「どこまでが月額保守費の枠内で、どこからが別途見積もりになるか」の線引きです。運用保守費の構成では軽微改修が10〜15%を占めるとされますが（出典：ripla）、この枠を曖昧にしたまま契約すると、後から「これは追加費用です」と次々に請求され、予算が膨らみます。逆に枠を明記しておけば、現場は「これは枠内で頼める」と安心して変更を依頼できます。
線引きの基準として、変更の工数や規模を目安にするのが一般的です。たとえば「月◯時間までの軽微改修は保守費に含む」「それを超える、または影響範囲の大きい変更は別途見積もり」といった形です。RFPには、想定される変更の例を挙げて「これは枠内か、別途か」をベンダーに回答させると、認識のズレを早期に潰せます。年間保守費は開発費の15〜20%が目安ですが（出典：ripla）、その中で軽微改修の枠がどう設計されるかを比較することが、適正な保守契約を選ぶ要になります。
価格配点を抑え対応品質を評価軸に据える
RFPでベンダーを選ぶ際の評価軸も、慎重に設計する必要があります。仕様変更対応では、価格の安さだけで選ぶと、対応の遅さやドキュメント不備というツケが後から回ってきます。だからこそ、価格の配点を過度に高くせず、変更対応の品質、影響範囲分析の精度、ドキュメント整備の方針、過去の対応実績といった項目に配点を分散させることが重要です。
評価軸の設計では、「変更要望を受けてから対応完了までの標準的な流れ」をベンダーに提案させ、その手順の堅実さを評価するのが有効です。安いだけで影響範囲調査を省くようなベンダーは、この提案で馬脚を現します。RFPは、価格表だけでなく「どういう手順で安全に変更するか」を競わせる文書にすると、長期的に信頼できるパートナーを見極められます。最も安い見積もりが、最終的に最も高くつくことは珍しくありません。
曖昧な変更要望を実装可能な要件に翻訳する
仕様変更対応のトラブルの多くは、現場から上がる変更要望が曖昧なまま開発に渡されることに起因します。「使いにくいから直して」「もっと早くして」といった要望は、そのままでは実装できません。これを「何を、どう変えれば、誰が、どう楽になるのか」という具体的な要件に翻訳する作業こそ、仕様変更における要件定義の核心です。
現状の課題とあるべき姿をセットで記述する
変更要件を翻訳する際は、「今どういう運用で、何に困っているのか（現状）」と「変更後にどうなっていてほしいのか（あるべき姿）」をセットで記述します。たとえば「画面を直して」ではなく、「現状は受注入力に5画面の遷移が必要で平均3分かかる。これを1画面で完結させ、入力時間を1分に短縮したい」と書けば、ベンダーは何を実現すべきかを正確に理解できます。目的と現状が明確であれば、実装方法はベンダーが最適なものを提案できます。
このとき、変更によって達成したい数値目標を添えると、要件はさらに明確になります。処理速度のRFP例として「全画面3秒以内」といった具体値が挙げられますが（出典：ripla）、こうした定量目標があると、変更が成功したかどうかを客観的に判定できます。「なんとなく使いやすくなった気がする」では評価できません。現状・あるべき姿・数値目標の三点をセットで書く習慣が、曖昧な要望を実装可能な要件へと変える鍵です。
影響範囲とテスト範囲を要件に含める
仕様変更の要件定義でとくに重要なのが、「変更によって影響を受ける範囲」と「どこまでテストするか」を要件として明記することです。新規開発ならゼロから作るので影響範囲を気にせずに済みますが、仕様変更は既存システムに手を入れる以上、波及先の確認が不可欠です。要件書に「この変更は◯◯機能と△△連携に影響する可能性があるため、それらの動作確認まで含める」と書いておけば、テスト漏れによる障害を防げます。
影響範囲とテスト範囲を要件に含めることは、見積もりの妥当性を判断する材料にもなります。影響範囲を考慮しないベンダーの見積もりは安く見えますが、それはテストを省いているからかもしれません。要件書でテスト範囲まで指定すれば、各社が同じ前提で見積もるため、価格を公平に比較できます。仕様変更の要件定義は、変える部分だけでなく「変えることで揺らぐ部分をどう守るか」まで書いて初めて完成すると心得てください。
対応範囲と責任分界点を契約で明確にする
仕様変更対応の契約で、後々もっとも揉めるのが「どこまでがベンダーの責任で、どこからが対象外か」という責任分界点です。とくにクラウドやSaaSと連携する現代のシステムでは、外部サービス側の仕様変更や障害が絡むため、責任の所在が曖昧になりやすいのです。RFPと契約の段階で、この境界を明文化しておくことが、いざというときの不毛な押し付け合いを防ぎます。
クラウド・外部SaaS起因の変更の扱いを定める
現代のシステムでは、自社が何も変えていないのに、連携先のSaaSがAPI仕様を変えたために改修が必要になることがあります。こうした「ベンダーのコントロール外で発生する仕様変更」を、保守契約の範囲内とするのか、別途対応とするのかをRFPで問い、契約に明記しておくべきです。これを曖昧にすると、外部API変更への対応を依頼したときに「契約外です」と言われ、改修費の交渉でこじれます。
あわせて、クラウド基盤側の障害への対応もどう扱うかを定めておきます。クラウドサービス自体の障害は、責任共有モデルの考え方ではクラウド事業者側の責任ですが、その復旧後の自社システムの動作確認は誰がやるのか、といった細部まで決めておくと安心です。RFPに「クラウドや外部SaaS起因の事象をどう切り分け、どう対応するか」を提案させることで、責任分界点の認識をベンダーと早期にすり合わせられます。この一手間が、想定外費用のトラブルを未然に防ぎます。
準委任か請負か契約形態を変更の性質で選ぶ
仕様変更対応の契約形態は、変更の性質に応じて選ぶ必要があります。定常的な軽微改修や問い合わせ対応のように、成果物が明確に定まらない継続的な業務は、準委任契約が向いています。一方、まとまった機能追加のように成果物が明確な変更は、請負契約が適しています。一般に、定常運用は準委任、明確な成果物がある改修は請負やSESといった形で使い分けられます。
契約形態の選択は、責任の重さと費用の透明性に直結します。請負は成果物への責任が明確な一方、見積もりが固まりにくい変更には不向きです。準委任は柔軟ですが、成果が出なくても工数分の費用が発生します。RFPの段階で、どの種類の変更にどの契約形態を適用するかをベンダーと合意しておくと、契約後の認識のズレを防げます。仕様変更は性質がさまざまだからこそ、一律の契約ではなく、変更の性質に応じた使い分けを設計することが賢明です。
SLAと対応時間を数値で定義する
仕様変更対応のRFPで、定量性をもっとも担保すべきなのがSLA（サービス品質保証）です。「迅速に対応します」という言葉は、ベンダーと発注側で時間感覚が食い違えば意味をなしません。変更要望を受けてから着手・完了までの目安、障害時の初動と復旧の時間を数値で定義しておくことで、対応の遅さを巡るトラブルを避けられます。
応答・復旧時間の実値を要件に書き込む
SLAの要件は、具体的な数値で書き込むことが肝心です。実務でよく使われる水準として、初報応答が重大障害で15分・通常で2時間、エスカレーション30分、回答24時間、復旧は重大障害4時間・通常8時間、恒久対応5営業日といった値が挙げられます（出典：ripla）。仕様変更に関しても、要望受付から見積もり提示までの日数、軽微改修の標準対応日数などを数値で定めると、対応スピードの期待値をベンダーと共有できます。
稼働率についても、たとえば99.9%なら月あたり約43分の停止許容、99.5%ならより緩い水準、と意味を理解したうえで設定します（出典：ripla）。仕様変更のリリースに伴う計画停止をこの稼働率の計算からどう扱うかも、あらかじめ取り決めておくべきです。SLAは数値で書くからこそ、達成・未達を客観的に判定でき、ベンダーとの議論が感情論にならずに済みます。曖昧な約束ではなく、検証可能な数値で合意することが、健全な保守関係の土台です。
ペナルティ条項の実効性まで設計する
SLAを定めるなら、未達時のペナルティ条項もあわせて設計しておくと、約束に実効性が生まれます。ただし注意したいのは、ペナルティ条項を書いても、原因の切り分けが曖昧なまま「これは外部要因です」とされてペナルティが適用されない現実があることです。だからこそ、前述の責任分界点を明確にしておくことが、ペナルティ条項を機能させる前提になります。
ペナルティは罰金そのものより、ベンダーに緊張感を持たせ、品質を保つ抑止力としての意味が大きいものです。減額の相場や適用条件を契約で具体化し、どういう場合に適用され、どういう場合に免責されるかまで書き切ることで、いざというときに揉めずに済みます。riplaはフルスクラッチ受託と国内開発の立場から、こうした「数値で定義し、責任分界とペナルティまで設計するRFP」の作成を重視しています。仕様変更対応のRFPは、価格表ではなく、変更の進め方と品質保証の取り決めを競わせる文書にすることが、後悔しない選択への近道です。
まとめ
ITシステムの仕様変更対応のRFP・要件定義書を整理すると、肝になるのは「変更の進め方と品質を数値と契約で明文化する」ことだと分かります。保守RFPでは軽微改修と追加見積もりの線引きを明記し、価格配点を抑えて対応品質を評価軸に据えます。曖昧な変更要望は現状・あるべき姿・数値目標と影響範囲・テスト範囲をセットで書いて実装可能な要件に翻訳します。さらにクラウド・外部SaaS起因の変更や契約形態で責任分界点を明確にし、SLAは応答・復旧時間の実値とペナルティの実効性まで設計します。
RFP・要件定義で大切なのは、「とりあえず直して」という曖昧さを残さず、変更の範囲・品質・責任・費用を検証可能な形で定義することです。これが、追加費用の押し付け合いや責任の擦り付け合いを防ぐ最大の防御になります。riplaはフルスクラッチ受託と国内開発を組み合わせ、変更を見据えた要件整理と、責任分界・SLAまで踏み込んだ契約設計を一貫して支援します。全体像の確認には、あらためて完全ガイドをご活用ください。
株式会社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を創業。