ITシステムアップデート対応のRFP/要件定義書/提案依頼書について

ITシステムのアップデート対応を外部の運用保守ベンダーに委託しようとするとき、最初の関門になるのがRFP（提案依頼書）と要件定義です。「とにかくセキュリティアップデートを面倒見てほしい」という曖昧な依頼のままでは、各社から比較しにくいバラバラの見積もりが返ってきて、適正価格も判断できません。アップデート対応のRFPは、何を・どのスピードで・どこまで対応してほしいかを定量的に書き切れるかどうかで、その後の契約品質が決まります。

本記事は、ITシステムのアップデート対応に関するRFP・要件定義書・提案依頼書の書き方を、発注企業の視点から実務的に解説します。対象システムと構成の棚卸し、対応範囲（OS・ミドル・SaaS連携・自社アプリ）の線引き、SLAと処理速度の数値要件、クラウド責任共有を前提とした責任分界点の明記、そして評価軸の設計まで、一次データとあわせて具体的に紹介します。読み終えるころには、自社で「比較可能で揉めにくいRFP」を書くための骨子が手に入るはずです。なお、アップデート対応の全体像をまだ把握していない方は、まずITシステムアップデート対応の完全ガイドから読むことをおすすめします。

▼全体ガイドの記事
・ITシステムアップデート対応の完全ガイド

対象システムと構成情報の棚卸し要件

RFPでまず書くべきは、アップデート対応の対象となるシステムの全体像と構成情報です。ここが曖昧だと、ベンダーは前提を勝手に置いて見積もるため、各社の金額がそろわず比較になりません。対象範囲を正確に棚卸しして提示することが、適正な提案を引き出す出発点です。

アップデート対応の対象は、サーバーOS、データベース、Webサーバー、アプリケーションフレームワーク、各種ライブラリと多岐にわたります。RFPには、これらの製品名と現行バージョン、そして分かる範囲でサポート期限（EOL）を一覧化して添付します。バージョンが分かると、ベンダーは「どれが期限間近で、どれだけの更改工数が要るか」を見積もれます。

この一覧化は、自社にとっても現状把握の好機です。意外と「何が・どのバージョンで動いているか」を正確に把握できていない現場は多いものです。RFPを書く過程で構成情報を棚卸ししておけば、契約後の適用台帳の土台にもなります。構成の一覧化は、見積もりの精度を上げると同時に、自社のIT資産管理を整える一石二鳥の作業です。

一覧には、現行バージョンとEOLに加えて、各コンポーネントが事業にとってどれだけ重要かの位置づけも添えると、提案の精度がさらに上がります。停止が許されない基幹に近い部分と、多少の遅延が許容される周辺機能とでは、求める対応スピードが変わるからです。重要度の濃淡を伝えておけば、ベンダーは限られた工数をどこに厚く配分すべきかを判断しやすくなります。構成情報は単なる製品リストではなく、「どこを優先して守るべきか」を示す地図として整えることに価値があります。

現代のシステムは、決済・地図・認証・通知などで外部SaaSのAPIに依存しています。RFPには、どの外部サービスのどのAPIに依存しているかを明示します。これらのSaaSは自社の都合と無関係に仕様を変更し旧バージョンを廃止するため、アップデート対応の重要な対象です。依存関係を書いておけば、ベンダーはAPI仕様変更への追従もスコープに含めて提案できます。

ここで合わせて検討すべきが、外部サービスの仕様変更に伴う改修を保守費に含めるか、別契約とするかという論点です。RFPの段階で「外部API変更時の調査・軽微改修（保守費内訳の10〜15%が目安、出典：ripla）の扱い」を問う設問を入れておくと、後の費用トラブルを未然に防げます。構成情報の棚卸しは、内部のOS・ミドルだけでなく、外部依存まで含めて初めて完成します。

対応範囲とSLA・処理速度の数値要件

RFPの核心は、対応してほしい範囲とそのスピードを「定量的に」書くことです。「迅速に対応」「適宜パッチを当てる」といった曖昧な表現では、各社が思い思いの水準で見積もるため比較できません。SLAという形で数値の要件を提示することが、揉めにくく比較可能なRFPの条件です。

RFPには、緊急度別の対応スピードをSLAとして書きます。たとえば、緊急の脆弱性は初報応答15分・暫定対応4時間以内、通常の更新は応答2時間・恒久対応5営業日以内、といった水準です（SLA実値の例、出典：ripla）。稼働率も99.9%（月43分の停止許容）や99.5%といった目標を明記します。これらの数値があると、ベンダーはその水準を満たす体制を前提に見積もるため、提案の質と価格が比較できる形でそろいます。

SLAを書くときは、努力目標型か保証型かも指定します。保証型で未達ペナルティ（月額の何%を減額するか）まで求めるなら、その条件もRFPに記載します。ただし後述する責任分界点と絡み、ベンダーのコントロール外が原因の場合はペナルティ対象外とする例外条項が現実には必要です。SLAは数値を掲げるだけでなく、達成判定の方法と例外条件まで設計してこそ実効性を持ちます。

アップデートで見落とされがちなのが、更新後も性能を維持する非機能要件です。OSやミドルのバージョンが上がると、これまでの処理速度が劣化することがあります。RFPには「全画面の応答3秒以内を維持する」といった処理速度の要件（RFP例、出典：ripla）を盛り込み、更新後もこの水準を満たすことを求めます。これにより、更新が性能を犠牲にしないことを担保できます。

性能だけでなく、可用性・セキュリティ・運用性といった非機能要件をRFPに数値で書いておくと、更新の品質基準が明確になります。アップデートは機能を変えない作業に見えて、実は非機能特性に影響を与えます。だからこそ、対応範囲の定義には機能維持だけでなく非機能の維持基準も含めるべきです。対応範囲とSLA・処理速度の数値要件は、アップデートRFPの説得力を支える二本柱だと言えます。

数値要件を書くときは、達成をどう判定するかの測定方法までセットで定義しておくと、後の認識のずれを防げます。たとえば「全画面の応答3秒以内」と書くだけでなく、どの環境で・どんな条件で・どう計測した値を基準とするかを明記します。測定の前提が曖昧だと、ベンダーと依頼者で「達成した・していない」の判断が食い違い、SLAの達成判定そのものが揉め事の火種になります。数値と測定方法を一体で定義することが、対応範囲を実効的なものにする仕上げの一手です。

クラウド責任共有を前提とした責任分界点の明記

モダンなIT環境のアップデートRFPでもっとも差がつくのが、責任分界点の明記です。クラウドやSaaSを前提にしたシステムでは、「どこまでがベンダーの責任で、どこからが発注側やクラウド事業者の責任か」が曖昧なまま契約すると、いざ障害が起きたときに責任の押し付け合いになります。責任共有モデルを前提に分界点を書き切ることが、揉めない契約の鍵です。

クラウド事業者側の大規模障害、連携SaaSの一方的なAPI仕様変更、AI連携機能の予期せぬ挙動など、ベンダーがコントロールできない領域で起きる事象は確実に存在します。RFPには、これらが起きたときに「誰が・どこまで・どの費用負担で対応するか」を定義する設問を入れます。曖昧なままだと、クラウド側障害なのにベンダーに復旧を迫る、あるいは逆に放置される、というトラブルに発展します。

たとえば、クラウド側障害時はベンダーが状況把握と一次連絡を行い、復旧は事業者側に委ねる、その間の調査工数は別途精算する、といった整理が考えられます。こうした「コントロール外」の事象を最初に切り分けておくことが、SLAの例外条項とも整合します。責任分界点の明記は、平時より障害時にこそ効く、契約の保険のような役割を果たします。

近年はAI連携機能を組み込むシステムも増え、AIが想定外の出力を返すいわゆるハルシネーションのような、従来の障害区分に収まりにくい事象も現れています。こうした新しいタイプの不具合について、誰が原因を切り分け、どこまでを保守の範囲とするかを、RFPの段階で論点として提示しておくと、後の責任論で迷いません。モダンなIT環境では、想定外の事象が「自社・ベンダー・クラウド事業者・SaaS提供元・AIモデル提供元」のどこに起因するかが複雑に絡みます。だからこそ、コントロール外の定義を丁寧に書き切ることが、責任の押し付け合いを避ける最大の備えになります。

アップデート対応の契約は、定常的な監視・適用・運用は準委任、まとまった更改や改修は請負、と切り分けるのが一般的です（出典：ripla）。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の段階で書き込んでおくことが、将来のリスクを大きく下げます。

RFPには、適用台帳・構成管理情報・手順書といったドキュメントを、ベンダーが整備し自社にも残すことを要件として書きます。これがないと、対応の中身がベンダーの中だけにブラックボックス化し、いざ別のベンダーへ移管しようとしたときに引き継ぎが難航します。何を・どの粒度で・どの頻度で更新して納品するかまで定めておくと、ドキュメントの形骸化を防げます。

あわせて、改修で生じた成果物やソースコードの著作権の帰属も、RFPで明確にしておくべき論点です。帰属が曖昧だと、独自パッケージへの派生やソースコードの著作権を盾に移管を拒まれる、いわゆる法的ロックインの泥沼に陥りかねません。アップデートに伴う軽微改修（保守費内訳の10〜15%が目安、出典：ripla）の成果物まで含めて帰属を定めておくことが、将来のベンダー変更の自由度を確保します。ドキュメントと帰属の要件は、ロックインを未然に防ぐ予防策です。

アップデート対応はセキュリティと表裏一体であるため、RFPには遵守すべきセキュリティ基準も明記します。脆弱性対応の方針、アクセス権限の管理、作業ログの保全、インシデント発生時の報告フローといった事項を要件として示すことで、ベンダーがどこまでのセキュリティ水準を担保するかが明確になります。これらが曖昧だと、対応の質が委託先の良心任せになってしまいます。

さらに、将来のベンダー変更に備えた移行支援の要件も入れておくと安心です。契約終了時に、構成情報・台帳・運用ノウハウを後継ベンダーへ引き継ぐ協力義務を契約に盛り込んでおけば、移管時の二重コストや引き継ぎ難航のリスクを抑えられます。移管の際は新旧ベンダーの並行期間で二重に費用がかかりやすいため、その負担を最小化する協力体制をあらかじめ取り決めておく意味は大きいです。引き継ぎ・セキュリティ・ドキュメントの要件は、契約後の安心と将来の選択肢を守るための、RFPの隠れた重要項目です。

まとめ

ITシステムのアップデート対応RFP・要件定義書を整理すると、(1)対象システムと構成情報（OS・ミドル・ライブラリ・連携SaaS）の棚卸し、(2)SLAと処理速度を数値で定義した対応範囲、(3)クラウド責任共有を前提とした責任分界点と契約形態の明記、(4)価格配点を抑え内訳提示を求める評価軸の設計、という四つの要素が骨子になります。曖昧な依頼ではなく、定量的で揉めにくいRFPを書けるかどうかが、その後の運用品質と費用の妥当性を決定づけます。

RFP作成では、まず自社の構成情報の棚卸しから始め、SLAと責任分界点という揉めやすい論点を先に詰めておくことをおすすめします。これらが固まっていれば、各社から比較可能な提案を引き出し、価格だけに惑わされない選定ができます。riplaはフルスクラッチ受託と国内運用保守の立場から、曖昧な要求の翻訳とRFP整理、そして作った後のアップデート対応まで一貫して支援します。要件定義の前提となる費用や契約の全体像は、あらためて完全ガイドをご確認ください。

株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。