ITシステムのアップデート対応を外部に委託するなら、最初に整えるのがRFP（提案依頼書）と要件定義書です。
依頼が曖昧だと、見積もりを比べられません。何を・どのスピードで・どこまで対応してほしいかを定量的に書けるかで、契約の質が決まります。全体はITシステムアップデート対応の完全ガイドで確認できます。
▼全体ガイドの記事
・ITシステムアップデート対応の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
対象システムと構成情報の棚卸し要件
RFPでまず書くべきは、アップデート対応の対象となるシステム全体と構成情報です。ここが曖昧だと、ベンダーは前提を各自で置いて見積もるため、金額がそろわず比べられません。
このため、対象範囲を正確に棚卸しして提示することが、適正な提案を引き出す出発点になります。
OS・ミドルウェア・ライブラリの一覧化
アップデート対応の対象は多岐にわたり、サーバーOSやデータベース、Webサーバーといった基盤から、フレームワークや各種ライブラリまで含みます。
RFPには、構成情報を一覧にして添付します。この一覧化は、自社にとっても現状把握の好機です。意外と「何が・どのバージョンで動いているか」を正確に把握できていない現場は多いものです。
RFPを書く過程で構成情報を棚卸ししておけば、契約後の適用台帳の土台にもなります。構成の一覧化は、見積もりの精度を上げると同時に、自社のIT資産管理も整える一石二鳥の作業です。
- 製品名と現行バージョン：どの版が動いているかが分かると、ベンダーは更改に必要な工数を見積もれます。
- サポート期限（EOL）：分かる範囲で書けば、期限が近いものから更改の計画を立てられます。
一覧には、現行バージョンとEOLに加えて、各コンポーネントが事業にとってどれだけ重要かも添えると、提案の精度がさらに上がります。
停止が許されない基幹に近い部分と、多少の遅延が許容される周辺機能とでは、求める対応スピードが変わります。重要度の濃淡を伝えておけば、ベンダーは限られた工数をどこに厚く配分すべきかを判断しやすくなります。
構成情報は単なる製品リストではなく、「どこを優先して守るべきか」を示す地図として整えることに価値があります。
連携SaaS・外部APIの依存関係の明示
現代のシステムは、決済や認証、通知などで外部SaaSのAPIに依存しています。RFPには、どの外部サービスのどのAPIに依存しているかを明示します。
これらのSaaSは自社の都合と関係なく仕様を変えたり、旧バージョンを廃止したりするため、アップデート対応の重要な対象です。依存関係を書いておけば、ベンダーはAPI仕様変更への追従も含めて提案できます。
構成情報の棚卸しは、内部のOSやミドルだけでなく、外部依存まで含めて初めて完成します。外部API変更時の調査・軽微改修の扱いを問う設問をRFPに入れておくと、後の費用トラブルを未然に防げます。
外部サービス側の変更は、保守費の扱いと依存先の一覧の作り方に関わるため、RFPの段階で決めておきます。
- 外部API変更時の調査・軽微改修：保守費に含めるか、別契約とするかを決めます（保守費内訳の10〜15%が目安、出典：ripla）。
- 外部依存の一覧化：OSやミドルウェアと並べて、連携する外部サービスまで一覧に加えます。
対応範囲とSLA・処理速度の数値要件
RFPの核心は、対応してほしい範囲とそのスピードを定量的に書くことです。「迅速に対応」「適宜パッチを当てる」といった表現では、各社が思い思いの水準で見積もるため比べられません。
数値の要件をSLAの形で示すことが、揉めにくく比べやすいRFPの条件になります。
SLAの応答・適用時間の数値定義
RFPには、緊急度別の対応スピードをSLAとして書きます。たとえば、緊急の脆弱性は初報応答15分・暫定対応4時間以内、通常の更新は応答2時間・恒久対応5営業日以内、といった水準になります（SLA実値の例、出典：ripla）。
稼働率も99.9%（月43分の停止許容）や99.5%といった目標を明記します。数値があれば、ベンダーはその水準を満たす体制を前提に見積もれるため、提案の質と価格を同じ条件で比べられます。
後述する責任分界点と絡んで、ベンダーのコントロール外が原因の場合はペナルティ対象から外す例外条項が、現実には必要です。
SLAは数値を掲げるだけでは足りず、その数値を守る義務の強さと、達成をどう判定するかも条文で決めておく必要があります。
- 努力目標型か保証型か：保証型で未達ペナルティ（月額の何%を減額するか）まで求める場合は、その条件もRFPに記載します。
- 達成判定の方法：数値を掲げるだけでなく、どう判定して達成とみなすかまで決めておきます。
更新後の処理速度・非機能要件の維持
アップデートで見落とされがちなのが、更新後も性能を維持する非機能要件です。OSやミドルウェアのバージョンが上がると、これまでの処理速度が落ちることがあります。
RFPには「全画面の応答3秒以内を維持する」といった処理速度の要件（RFP例、出典：ripla）を盛り込み、更新後もこの水準を満たすよう求めます。これにより、更新が性能を犠牲にしないことを担保できます。
性能だけでなく、可用性・セキュリティ・運用性も数値で書いておくと、更新の品質基準が明確になります。アップデートは機能を変えない作業に見えて、非機能特性には実際に影響を与えます。
「全画面の応答3秒以内」という数字は、測る環境と条件が決まって初めて、達成したかどうかを確かめられます。
- 測定の環境と条件：「全画面の応答3秒以内」と書くだけでなく、どの環境でどんな条件で計測するかを明記します。
- 達成の判定方法：測定の前提が曖昧だと、達成したかどうかの判断がベンダーと依頼者で食い違い、揉め事の火種になります。
数値と測定方法をセットで定義しておくと、後の認識のずれを防げます。対応範囲とSLA・処理速度の数値要件は、アップデートRFPの説得力を支える二本柱です。
クラウド責任共有を前提とした責任分界点の明記
モダンなIT環境のアップデートRFPで、もっとも差がつくのが責任分界点の明記です。
クラウドやSaaSを前提にしたシステムでは、「どこまでがベンダーの責任で、どこからが発注側やクラウド事業者の責任か」が曖昧なまま契約すると、いざ障害が起きたときに責任の押し付け合いになります。
責任共有モデルを前提に分界点を書き切ることが、揉めない契約の鍵です。
ベンダーのコントロール外障害の扱い
コントロール外の事象には、クラウド事業者側の大規模障害、連携SaaSの一方的なAPI仕様変更、AI連携機能の予期せぬ挙動などがあります。ベンダーが手を出せない領域で起きる事象は、確実に存在します。
モダンなIT環境では、想定外の事象の起因が、自社・ベンダー・クラウド事業者・SaaS提供元・AIモデル提供元のどこにあるかが複雑に絡みます。近年はAI連携機能を組み込むシステムも増え、AIが想定外の出力を返すいわゆるハルシネーションのように、従来の障害区分に収まりにくい事象も現れています。
こうした新しいタイプの不具合は、誰が原因を切り分け、どこまでを保守の範囲とするかを、RFPの段階で論点として示しておくと、後の責任論で迷いません。
RFPには、これらが起きたときに「誰が・どこまで・どの費用負担で対応するか」を定義する設問を入れます。曖昧なままだと、クラウド側の障害なのにベンダーに復旧を迫る、あるいは逆に放置される、というトラブルに発展します。
- クラウド側障害時の役割：ベンダーが状況把握と一次連絡を行い、復旧は事業者側に委ねるといった線引きが考えられます。
- 調査工数の精算：障害の調査にかかった工数を、別途精算するかどうかを決めます。
コントロール外の事象を最初に切り分けておくことは、SLAの例外条項とも整合します。責任分界点の明記は、平時より障害時にこそ効きます。
契約形態による準委任と請負の切り分け
アップデート対応の契約は、定常的な監視・適用・運用を準委任、まとまった更改や改修を請負に切り分けるのが一般的です（出典：ripla）。
RFPでは、どの業務を準委任とし、どの作業を成果物ベースの請負とするかを明示します。何に対して費用を払い、何が成果として保証されるのかが明確になります。
契約形態の切り分けは、責任の所在とも直結します。準委任は善管注意義務を負う一方で成果完成の義務はなく、請負は成果物の完成責任を負います。
日々の適用と大型の更改とでは、準委任と請負のどちらとして扱うかが分かれます。
- 日々の適用：最善を尽くす準委任として扱い、対応の範囲をRFPで明確にします。
- 大型の更改：決めた範囲を完成させる請負として扱い、成果物の完成責任を負わせます。
責任分界点は、コントロール外事象の扱いと契約形態の両面から設計すると、後の責任論が明快になります。
提案評価軸と見積もり比較の設計
RFPは送って終わりではなく、返ってきた提案の評価まで設計して初めて意味を持ちます。評価軸が曖昧だと、金額の安さだけで選んでしまい、対応品質の低いベンダーをつかむおそれがあります。
価格と品質のバランスを取った評価軸を、RFPの段階で用意しておくことが重要です。
価格配点を抑え対応体制を重視する評価軸
アップデート対応の評価では、価格の配点を意図的に抑え、対応体制やSLA達成の実績、属人化していない運用設計に重きを置くことを推奨します。
理由は、安く請けても品質が伴わなければ、結局インシデント対応で高くつくからです。年間保守費は開発費の15〜20%が相場（出典：ripla）です。そのため、極端に安い提案は、対応範囲の絞り込みや待機要員の薄さを疑うべきです。
価格以外に見たいのは、障害時の連絡体制と、担当者が替わっても回る運用です。
- 緊急時の連絡と夜間休日の対応：連絡体制や夜間休日の対応可否を、評価の項目として入れます。
- 担当者交代への備えと実績：担当者が抜けても回る体制かどうかと、過去の対応実績で見極めます。
これらを点数化すると、価格に引っ張られない多面的な比較ができます。価格配点を抑える設計は、目先の安さで失敗しないための発注側の自衛策だと言えます。
見積もり内訳の提示と妥当性の確認
RFPでは、見積もりを総額だけでなく内訳で提示するよう求めます。保守費は一般に、定期保守が20〜30%、監視が15〜25%、障害対応が25〜35%と、大きな割合を占めます。
残りは、問合せが10〜20%、軽微改修が10〜15%、管理報告が5〜10%です（出典：ripla）。この内訳を出してもらえば、各社が何にいくら見込んでいるかを比べられ、安さの理由や手厚さの根拠を読み解けます。
内訳のなかでも、障害対応の比重と軽微改修の枠は、体制の厚みがそのまま表れる部分です。
- 障害対応の比重：極端に低い提案は、いざというときの体制が薄い可能性があります。
- 軽微改修の枠：手厚ければ、日々の小さな変更要望にも柔軟に応えてもらえる期待が持てます。
内訳の提示を求めることは、ベンダーの提案を一段深く理解する手がかりになります。極端に安い提案の裏にあるベンダー側の事情も、ここから見えてきます。
多重下請けの構造や待機要員のコストは価格に反映される一方、安すぎる提案は対応範囲をひそかに絞り込んでいたり、いざというときの待機体制が薄かったりします。RFPで内訳と体制を具体的に問うことは、この「安さの裏側」を見抜く手段にもなります。
価格の数字だけでなく、どんな体制とコスト構造から出ているかまで読み解く設計が、失敗しない選定につながります。
引き継ぎ・セキュリティ・ドキュメントの要件
RFPで見落とされがちなのが、契約終了や担当交代を見据えた引き継ぎ要件と、セキュリティ・ドキュメントの要件です。アップデート対応は長期にわたる継続業務のため、いつか必ず体制が変わります。
そのときに困らないための条件を契約前のRFPに書き込んでおくことが、将来のリスクを下げます。
ドキュメント整備とソースコード帰属の要件
適用台帳・構成管理情報・手順書といったドキュメントは、ベンダーが整備して自社にも残す要件として書きます。これがないと、対応の中身がベンダーの中でブラックボックス化し、別のベンダーへ移管するときに引き継ぎが難航します。
何を・どの粒度で・どの頻度で更新して納品するかまで定めておくと、ドキュメントの形骸化を防げます。
あわせて、改修で生じた成果物やソースコードの著作権の帰属も、RFPで明確にしておくべき論点です。改修の成果物とソースコードのそれぞれについて、帰属の範囲を決めておく必要があります。
- 改修成果物の帰属：軽微改修（保守費内訳の10〜15%が目安、出典：ripla）で生じた成果物まで含めて定めます。
- ソースコードの著作権：独自パッケージへの派生をどう扱うかを、RFPの段階で明確にします。
帰属が曖昧だと、ソースコードの著作権を盾に移管を拒まれる、いわゆる法的ロックインに陥りかねません。ドキュメントと帰属の要件は、ロックインを未然に防ぐ予防策です。
セキュリティ基準と移行支援の要件
アップデート対応はセキュリティと表裏一体であるため、RFPには遵守すべきセキュリティ基準も明記します。インシデント発生時の報告フローを要件として示すと、ベンダーがどこまでの水準を担保するかが明確になります。
基準が曖昧だと、対応の質が委託先の良心任せになってしまいます。セキュリティは脆弱性対応や権限管理、ログの扱いまで具体的に書き、移行では契約終了時の引き継ぎを条件として求めます。
- 脆弱性対応・アクセス権限・作業ログ：対応の方針、権限の管理、ログの保全を、ベンダーに求める基準として書きます。
- 契約終了時の引き継ぎ：構成情報・台帳・運用ノウハウを後継ベンダーへ渡す協力義務を、契約に盛り込みます。
移管の際は新旧ベンダーの並行期間で二重に費用がかかりやすいため、移行の協力体制をあらかじめ取り決めておく意味は大きいです。
引き継ぎ・セキュリティ・ドキュメントの要件は、契約後の安心と将来の選択肢を守るための、RFPの隠れた重要項目です。
まとめ
ITシステムのアップデート対応RFPと要件定義書の骨子は、四つの要素です。(1)構成情報（OS・ミドル・ライブラリ・連携SaaS）の棚卸し、(2)SLAと処理速度を数値で示した対応範囲、(3)責任分界点と契約形態の明記、(4)価格配点を抑えた評価軸の設計です。
曖昧な依頼ではなく、定量的で揉めにくいRFPを書けるかどうかが、その後の運用品質と費用の妥当性を左右します。RFP作成では、まず構成情報の棚卸しから始め、SLAと責任分界点という揉めやすい論点を先に詰めておくことをおすすめします。これらが固まっていれば、各社から比較可能な提案を引き出し、価格だけに惑わされない選定ができます。
riplaはフルスクラッチ受託と国内運用保守の立場から、曖昧な要求の翻訳とRFP整理、そして作った後のアップデート対応まで一貫して支援します。要件定義の前提となる費用や契約の全体像は、あらためて完全ガイドをご確認ください。
▼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を創業。