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