IT運用保守を新たに発注したり、ベンダーを乗り換えたりするとき、その成否を最初に左右するのがRFP（提案依頼書）と要件定義書の精度です。運用保守のRFPは、開発のRFPと違って「完成すべき成果物」が明確でないため、要件が曖昧なまま見積を取ると、各社の提案が比較できないバラバラなものになり、契約後に「これは範囲外です」というトラブルが頻発します。とくにクラウドやSaaS、AIを組み合わせた現代のシステムでは、責任の境界をRFPで定義しておかないと、障害時の費用負担をめぐって深刻な揉め事になりかねません。
本記事は、IT運用保守のRFP・要件定義書・提案依頼書を、発注側が主導権を持って作るための実践的な解説です。クラウドの責任共有を前提にした責任分界点の定義、稼働率や応答時間といったSLAの数値要件、現場の曖昧な要望を測定可能な要件へ翻訳する方法、そして価格だけに偏らない提案評価軸の設計までを、SLA実値や費用相場の一次データとあわせて掘り下げます。なお、IT運用保守の費用相場や契約形態を含めた全体像を把握したい方は、まずIT運用保守の完全ガイドをご覧ください。本記事を読めば、ベンダー任せにしないRFPの骨格を自社で描けるようになります。
▼全体ガイドの記事
・IT運用保守の完全ガイド
責任分界点をRFPで定義する（クラウド責任共有前提）
現代のIT運用保守RFPで最重要なのに、もっとも抜けやすいのが「責任分界点」の定義です。システムがAWSやSaaS、外部APIの上に成り立っている以上、すべての障害を保守ベンダーがコントロールできるわけではありません。クラウド側の障害、連携SaaSの仕様変更、AIの誤動作といった「ベンダーのコントロール外」で起きる事象の責任と費用をRFPで明確にしておかないと、いざというときに誰も責任を取らない空白地帯が生まれます。
クラウド・SaaS障害の責任と費用をRFPに明記する
クラウドの責任共有モデルでは、インフラの可用性はクラウド事業者、その上のアプリケーションやデータは利用者側が責任を持ちます。RFPでは、この前提に立って「AWSのリージョン障害が起きたとき、保守ベンダーはどこまで対応するのか」「連携SaaSがAPI仕様を変更して連携が止まったとき、その改修費用は誰が負担するのか」を具体的に書き込む必要があります。これを曖昧にすると、クラウド側起因の障害で稼働率SLAを割っても「うちのせいではない」と責任を回避され、発注側だけが損害を被ることになります。
実務的には、RFPに「想定される障害の発生源（自社アプリ／クラウド基盤／連携SaaS／ネットワーク等）ごとに、保守ベンダーの対応範囲と費用区分を提案で明示すること」という要求を入れるのが有効です。そのうえで、コントロール外の事象に対しても「一次切り分けと状況報告は行う」「クラウド事業者への問い合わせ代行はする」といった最低限の役割を定義しておくと、空白地帯が埋まります。責任分界点をRFPの段階で言語化させることが、後の「想定外費用」をめぐる泥沼を防ぐ最大の予防策になります。
準委任か請負か、契約形態を要件として指定する
RFPでは、業務ごとに想定する契約形態も指定しておくと、提案の前提が揃います。日々の監視・障害対応・問い合わせ対応といった定常運用は、成果物が定義しにくいため準委任契約が基本です（出典：ripla）。一方、まとまった改修やバージョンアップのように「完成すべき成果物」が明確な作業は、請負契約として個別に発注するのが適しています。この区分をRFPで示しておくと、ベンダーは「どこまでが月額の準委任で、どこからが別見積の請負か」を明確に提案でき、発注側も費用の見通しを立てやすくなります。
契約形態を要件として整理しないまま発注すると、本来は請負で別見積になるべき大きな改修まで「保守の範囲でしょう」と期待してしまい、認識のズレからトラブルになります。RFPの段階で「定常運用は準委任、◯時間を超える改修や機能追加は請負で別途見積」という枠組みを示しておけば、双方の期待値が揃います。契約形態は法務リスクにも直結するため、運用保守のRFPでは技術要件と並んで明記すべき重要項目です。
あわせてRFPでは、契約期間と更新条件、解約の予告期間も要件として示しておくと安心です。運用保守は長期契約になりやすく、いざ不満が出ても解約しづらい構造に陥りがちです。最低契約期間が長すぎないか、自動更新の条件は妥当か、解約時にデータやドキュメントを確実に返してもらえるかを、契約の入り口で定義しておくことが、後のベンダーロックインを防ぐ布石になります。責任分界点と契約形態、そして出口の条件まで含めてRFPで言語化することが、発注側が主導権を保ち続けるための土台です。
SLAと非機能要件を数値で要件化する
運用保守のRFPで提案を正しく比較するには、SLA（サービス品質保証）と非機能要件を数値で要件化することが欠かせません。「安定して動かしてほしい」「障害には早く対応してほしい」といった定性的な表現では、各社が思い思いの前提で見積を出し、横並びの比較ができません。稼働率・応答時間・復旧時間といった指標を具体的な数値で示すことで、提案の土俵が揃います。
稼働率・応答時間・復旧時間の数値要件
SLAの数値要件は、一次データの実値を参考に設定すると現実的です。稼働率は99.9%（月の許容停止時間が約43分）か99.5%、初報応答は重大障害で15分・通常で2時間、エスカレーションは30分以内、暫定復旧は重大で4時間・通常で8時間、恒久対応は5営業日以内、といった水準が実務上の目安です（出典：ripla）。RFPには、これらの目標値を自社の事業重要度に合わせて記載し、「提案ではこの目標を満たせるか、満たすための体制をどう構築するか」を問います。
非機能要件としては、処理速度の数値も忘れてはいけません。実際のRFP例では「全画面を3秒以内で表示」といった性能要件が定められることがあります（出典：ripla）。運用保守のRFPでは、こうした性能を「維持し続ける」ことを要件に含め、性能が劣化したときの対応も範囲に入れます。数値で要件化しておけば、SLA未達時のペナルティ（月額の何%減額か）も具体的に議論でき、努力目標型ではなく実効性のある保証型のSLAを引き出せます。曖昧な期待を数値の約束へ変換することが、RFPの中核的な役割です。
現場の曖昧な要望を測定可能な要件へ翻訳する
要件定義の難所は、現場から上がってくる曖昧な要望を、測定可能な要件へ翻訳することです。「もっと早く対応してほしい」という声を、そのままRFPに書いても意味がありません。これを「重大障害は15分以内に第一報を入れる」という測定可能な基準へ翻訳して初めて、提案でき、達成・未達も判定できる要件になります。この翻訳作業こそが、発注側が運用保守の要件定義で果たすべき本質的な役割です。
翻訳の具体的な進め方としては、まず現場のヒアリングで「どんなときに、何に困っているか」を集め、それを「頻度・時間・件数・割合」といった測定可能な軸に落とし込みます。たとえば「問い合わせの返事が遅い」という不満は、「問い合わせへの回答は24時間以内」という要件に変換できます（出典：ripla）。曖昧な要望を放置したままRFPを出すと、提案は各社まちまちになり、契約後も「思っていたのと違う」が続きます。要望を要件へ翻訳する力が、RFPの質を決定づけるのです。
提案評価軸を設計する（価格偏重を避ける）
RFPの最後の要点は、提案をどう評価するかという評価軸の設計です。運用保守は長期にわたって付き合う相手を選ぶ行為であり、目先の価格だけで決めると、安かろう悪かろうのベンダーを引き当てて、結局は障害対応の遅さや改修費の上振れで高くつくことになります。評価軸を事前に設計し、価格配点を意図的に抑えることが、長く付き合える相手を選ぶコツです。
価格配点を抑え、体制・実績・SLA順守力を重視する
評価軸を設計するときは、価格の配点を全体の3〜4割程度に抑え、残りを体制・実績・SLA順守力・コミュニケーションといった非価格要素に振り分けるのが定石です。運用保守は人月単価60万〜150万円の専門人材が継続的に関わる業務であり（出典：ripla）、極端に安い提案は、待機要員を薄くしているか、多重下請けで品質管理が効いていない可能性があります。価格だけで選ぶと、いざ障害が起きたときに対応できる人がいない、という事態を招きかねません。
具体的な評価項目としては、24時間対応の体制があるか、類似システムの運用保守実績があるか、SLA未達時のペナルティを受け入れる姿勢があるか、障害時のエスカレーション体制が明確か、といった点を配点します。とくに、責任分界点や想定外費用の扱いをどれだけ誠実に提案に書き込んでいるかは、そのベンダーの信頼性を測る良い指標になります。価格の安さに目を奪われず、「長期で安心して任せられるか」という観点で評価軸を組むことが、運用保守のRFPでは決定的に重要です。
想定外費用の扱いを提案で明示させる
RFPで意図的に問うべきなのが、想定外費用の扱いです。OSSの脆弱性対応、データ復旧、クラウド側障害への対応など、契約時には想定しきれない事象が必ず発生します。これらをどう扱うか（月額に含むのか、都度見積か、上限を設けるのか）を提案で明示させることで、契約後の費用トラブルを大幅に減らせます。想定外費用への向き合い方は、ベンダーの誠実さを映す鏡でもあります。
たとえば、緊急のデータ復旧や、クラウド事業者の障害に伴う臨時対応について、「都度見積だが、事前に概算レンジを提示する」「年間で一定の予備工数枠を確保する」といった提案ができるベンダーは、運用の実態を理解していると言えます。逆に、想定外費用について何も触れない提案は、契約後に高額な追加請求を出してくるリスクがあります。riplaはフルスクラッチ受託と国内運用保守の立場から、こうした責任分界点と想定外費用を最初に正直に整理し、発注側が安心して長期委託できるRFP対応を重視しています。評価軸に想定外費用の扱いを含めることが、運用保守RFPの完成度を高めます。
移管・出口を見据えた要件をRFPに織り込む
運用保守のRFPでもう一つ忘れてはならないのが、契約の「出口」を見据えた要件です。運用保守は長期にわたるため、いつかはベンダーを乗り換える可能性があります。そのときに困らないよう、ドキュメントの整備義務やソースコードの著作権、移管支援の条件をRFPの段階で要件化しておくことが、将来のベンダーロックインを防ぐ布石になります。多くの発注側は入口の品質ばかりに目を奪われ、出口の設計を怠った結果、後で抜け出せなくなります。
出口の要件は、いざ乗り換えるときだけでなく、現ベンダーとの日常的な交渉力にも効いてきます。移管できる選択肢を確保していると分かっているベンダーは、保守費の値上げや改修の引き延ばしに対しても誠実に向き合わざるを得ません。逆に、出口を設計していない発注側は、不満があっても抜け出せず、言い値で契約を続けることになります。出口の要件化は、移管のためというより、長く対等な関係を保つための布石なのです。
ドキュメント整備と著作権の帰属を要件化する
RFPには、運用保守の過程で発生するドキュメントの整備と納品を要件として明記します。具体的には、設計書・運用手順書・監視設定・障害対応履歴・構成管理情報を、定められた頻度で最新化し、求めに応じて開示することを求めます。これらが揃っていれば、いざ別のベンダーに移管するときも、新ベンダーが短期間でキャッチアップでき、二重コストや移管期間の長期化を防げます。逆にドキュメントを要件化していないと、運用の実態がベンダーの頭の中だけに蓄積され、社内はブラックボックス状態になります。
あわせて、ソースコードや成果物の著作権の帰属も要件として示しておくことが重要です。著作権がベンダー側に残る契約だと、移管時に「これは当社の著作物だから渡せない」と主張され、乗り換えが法的な泥沼に発展します。RFPの段階で「ソースコードの著作権は発注側に帰属する、または少なくとも移管に必要な範囲で開示する」という条件を提示しておけば、後の法的ロックインを構造的に防げます。出口の自由度を入口で確保することが、長期の運用保守で発注側が交渉力を保つ唯一の方法です。
移管支援と引き継ぎ期間をRFPで担保する
RFPには、契約終了時の移管支援についても要件を盛り込みます。たとえば「契約終了の◯か月前から、新ベンダーへの引き継ぎに協力する」「引き継ぎに必要な資料の提供と、質疑対応の工数を確保する」といった条件です。これを契約に含めておかないと、いざ乗り換えるときに現ベンダーが非協力的になり、引き継ぎが進まず、結果として旧ベンダーへの保守費と新ベンダーのキャッチアップ費用が重なる二重コストが発生します。移管支援の有無は、長期の運用保守コストを大きく左右します。
さらに、最低契約期間と解約予告期間、自動更新の条件もRFPで確認しておくべき項目です。最低契約期間が長すぎたり、解約予告が半年前などと厳しすぎたりすると、不満があっても身動きが取れなくなります。出口の条件を入口のRFPで定義しておくことが、運用保守における発注側の自由度を守ります。riplaはフルスクラッチ受託と国内運用保守を組み合わせ、作った後も継続して伴走する立場から、ソースコードや成果物の権利関係を明確にし、移管時にも発注側が困らない誠実なRFP対応を重視しています。入口と出口の両方を要件化してこそ、RFPは長期にわたって発注側を守る道具になります。
想定外費用と予備工数枠を要件で先回りする
移管・出口の要件と並んで先回りしておきたいのが、想定外費用への備えです。OSSの脆弱性対応、データ復旧、クラウド側の障害に伴う臨時対応などは、契約時には金額を見積もりきれませんが、確実に発生します。RFPでこれらの扱いを「月額に含むのか、都度見積りか、年間の予備工数枠を設けるのか」を提案で明示させておけば、運用開始後に高額な追加請求で慌てる事態を防げます。想定外費用への向き合い方は、ベンダーが運用の実態をどれだけ理解しているかを映す鏡でもあります。
具体的には、RFPに「年間で一定の予備工数枠を確保し、想定外の緊急対応はその枠から充当する」「枠を超える場合は事前に概算レンジを提示する」といった条件を盛り込むよう求めます。軽微改修が保守費の10〜15%、障害対応が25〜35%という内訳の目安（出典：ripla）を踏まえ、これらを超える緊急対応がどう精算されるかを要件として固めておきます。入口の品質・出口の自由度・想定外費用の三つを要件で先回りすることで、RFPは契約後の不意打ちを構造的に減らし、発注側が予算と主導権の両方を守れる設計になります。
まとめ
IT運用保守のRFP・要件定義書で押さえるべきは、四つの柱です。第一にクラウド・SaaS・AIの責任共有を前提とした責任分界点の定義と契約形態（準委任／請負）の指定、第二に稼働率99.9%・初報応答15分・全画面3秒以内といったSLAと非機能要件の数値化、第三に現場の曖昧な要望を測定可能な要件へ翻訳すること、第四に価格配点を抑えて体制・実績・SLA順守力・想定外費用の扱いを重視する評価軸の設計です。これらをRFPに盛り込めば、提案が横並びで比較でき、契約後のトラブルを構造的に減らせます。
運用保守のRFPは、ベンダーに丸投げするのではなく、発注側が主導権を握って数値と責任範囲を定義することで、初めて実効性を持ちます。責任分界点と想定外費用を最初に正直に言語化させ、SLAを努力目標ではなく保証として引き出すことが、長く安心して任せられる委託の出発点です。riplaはフルスクラッチ受託と国内運用保守を組み合わせ、開発した後も継続して伴走する立場から、こうした現実的なRFP・要件定義づくりを支援します。費用相場や契約形態の詳細は、あらためて完全ガイドをご確認ください。
株式会社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を創業。