ITシステムの運用サポートを外部に委託するため、RFP（提案依頼書）や要件定義書を作成しようとして、「開発のRFPは書いたことがあるが、運用の要件はどう書けばいいのか分からない」と手が止まっていないでしょうか。運用サポートのRFPは、機能要件が中心の開発RFPとは性質が異なり、稼働率や応答時間といったサービス品質の要件、責任分界点、契約形態など、目に見えにくい「サービスの質」を文書で定義する必要があります。ここを曖昧にしたまま発注すると、提案各社の比較ができず、契約後にトラブルの火種を抱えることになります。
本記事は、ITシステム運用サポートのRFP・要件定義書・提案依頼書をどう作り込むかを掘り下げる「要件定義特化」の解説です。SLAや処理速度を数値で定義する方法、クラウドの責任共有を前提とした責任分界点の明記、曖昧な要求を提案可能な要件へ翻訳する技術、そして価格偏重を避ける評価基準の設計まで、一次データとあわせて実務的に解説します。なお、運用サポートの全体像をまだ把握していない方は、まずITシステム運用サポートの完全ガイドから読むことをおすすめします。
▼全体ガイドの記事
・ITシステム運用サポートの完全ガイド
SLAと処理速度を数値で定義する要件
運用サポートのRFPで最初に取り組むべきが、サービス品質を数値で定義することです。「迅速に対応すること」「高い可用性を確保すること」といった定性的な表現では、提案各社が異なる前提で見積もるため、比較ができません。稼働率、応答時間、復旧時間といった指標を具体的な数字で示してこそ、各社を同じ土俵で評価できます。
稼働率・応答時間・復旧時間の数値要件の書き方
SLAの数値要件は、いくつかの軸を組み合わせて定義します。可用性については稼働率99.9%（月間で約43分の停止まで許容）や99.5%といった水準を、障害の重要度を区分したうえで設定します（出典：ripla）。応答時間については、初報応答を重大障害で15分・通常で2時間、エスカレーションを30分、一次回答を24時間以内、というように段階ごとに定めます。
復旧時間も同様に、暫定復旧を重大4時間・通常8時間、恒久対応を5営業日以内、と定義します（出典：ripla）。ここで大切なのは、障害の重要度区分（重大・通常など）を先に定義し、各区分にそれぞれの数値を割り当てることです。さらに、システムの性能要件として「全画面の表示を3秒以内」といった処理速度をRFPに明記する例もあります（出典：ripla）。これらの数値があることで、運用後に「遅い」「対応が遅れた」といった主観的な不満を、客観的な基準で評価できるようになります。数値化は、品質を担保すると同時に、揉めごとを防ぐ予防線でもあるのです。
SLA未達時のペナルティ条項をどう書くか
SLAを数値で定義したら、それが未達だった場合にどうするかをRFPで問うことも重要です。一般に、稼働率や復旧時間がSLAを下回った場合、月額費用の一定割合を減額するというペナルティ条項が用いられます。この実効性を確保するには、減額の相場（月額の何%か）と、ペナルティが発動する条件を具体的に定めておく必要があります。
注意すべきは、ペナルティ条項が形だけになりがちな現実です。障害の原因が「自社側かベンダー側か有耶無耶」のまま、責任が曖昧になってペナルティが適用されない、というケースが少なくありません。これを防ぐには、後述する責任分界点を明確にし、「どの事象が誰の責任で、どの場合にペナルティが発動するか」をRFPの段階で問うことが欠かせません。SLAは数値を定めるだけでなく、未達時の措置と、その措置が確実に発動する仕組みまで含めて要件化してはじめて、実効性を持ちます。ペナルティの相場感と発動条件を提案各社に明示させることが、骨抜きを防ぐ鍵になります。
クラウド責任共有を前提とした責任分界点の要件
現代の運用サポートRFPで、競合の多くが抜け落としているのが、クラウドやSaaSと連携した環境を前提にした責任分界点の定義です。システムがクラウド上で動き、複数のSaaSとAPIで連携している以上、障害の原因が自社・ベンダー・クラウド事業者・連携SaaSのどこにあるかで、責任の所在が変わります。この線引きをRFPで先に決めておかないと、運用開始後に「これは誰の領域か」で延々と揉めることになります。
ベンダーのコントロール外障害をどう扱うか定義する
運用サポートのRFPで明確にすべき最重要論点が、「ベンダーのコントロール外で起きる障害」の扱いです。クラウド事業者側の広域障害、連携SaaSのAPI仕様変更による不具合、生成AIを組み込んだ機能でのAIの誤った出力（ハルシネーション）など、運用ベンダーが直接制御できない事象は確実に存在します。これらを「障害だからベンダーが全部対応する」と暗黙に期待するのは危険です。
RFPでは、こうした外部要因による事象について、ベンダーがどこまで対応するか（状況把握と連絡、暫定対応の範囲）、それがSLAの対象に含まれるか除外されるか、追加対応が必要な場合の費用負担はどうなるかを、提案で明らかにするよう求めます。たとえば「クラウド事業者起因の広域障害はSLAの稼働率算定から除外するが、状況連絡と暫定対応は標準対応に含める」「連携SaaSのAPI仕様変更に伴う改修は別途見積もりとする」といった整理です。この責任分界の要件化こそが、競合のRFPテンプレートが見落としがちな差別化ポイントであり、運用後の紛争を未然に防ぐ最大の保険になります。
準委任・請負の契約形態をRFPで指定する
責任分界と密接に関わるのが、契約形態の指定です。運用サポートは、業務の性質によって準委任契約と請負契約を使い分けます。一般に、監視や定型運用のように「成果物ではなく業務の遂行」を委託する定常運用は準委任契約が適し、特定の改修や移行のように「成果物の完成」を約束させたい業務は請負契約が適します。RFPでは、どの業務をどちらの契約形態で想定しているかを示しておくと、提案の前提が揃います。
この区別が重要なのは、契約形態によってベンダーが負う責任の重さが変わるからです。準委任は善管注意義務に基づき業務を遂行する責任、請負は成果物を完成させる責任、という違いがあります。両者を混同すると、「成果を約束したはずなのに、努力義務しかないと言われた」といった齟齬が生まれます。RFPで契約形態の前提を明示し、提案各社に契約形態ごとの責任範囲を確認することで、後の認識違いを防げます。SLAの数値、責任分界点、契約形態の三つは互いに連動しており、RFPではこれらを一体として要件化することが、揺るがない運用契約の基礎になります。
曖昧な要求を提案可能な要件へ翻訳する
RFPを作る際に多くの企業がつまずくのが、現場が抱える漠然とした不満や要望を、ベンダーが提案できる具体的な要件に翻訳する作業です。「今のシステムが不安定で困っている」「問い合わせの対応が遅い」といった声をそのままRFPに書いても、ベンダーは何をどう改善すればよいか提案できません。曖昧な要求を、測定可能な要件に変換することが、良いRFPの条件です。
現状の課題を定量化してRFPに落とし込む
曖昧な要求を翻訳する第一歩が、現状の課題を数字で可視化することです。「不安定で困っている」なら、過去半年の障害発生件数や停止時間を集計する。「対応が遅い」なら、問い合わせから回答までの平均時間を測る。こうして現状を定量化すれば、RFPに「現状の障害月◯件を◯件以下に」「現状の平均対応◯時間を◯時間以内に」といった改善目標として書けるようになります。
この定量化には、運用対象システムの全体像を棚卸しすることが前提になります。どのシステムが、どのクラウド・サーバー上で動き、どのSaaSと連携しているか、利用者数や取引量はどれくらいか、といった現状を一覧化します。この情報がRFPに含まれていないと、提案各社は規模感をつかめず、見積もりが過大になったり、前提が各社でバラバラになったりします。現状の課題を数字で示し、対象システムの構成を明らかにすることが、提案の精度を揃える土台です。曖昧さを残したRFPは、曖昧な提案しか引き出せません。
対応範囲と除外範囲を両方明記する
要件を明確にするうえで意外と効くのが、「やってもらうこと」だけでなく「やらないこと」も明記することです。運用サポートの範囲は、監視・障害対応・定期メンテナンスといった標準業務のほかに、軽微改修・機能追加・データ復旧・利用者教育など、含めるか別料金にするかで揉めやすい領域が数多くあります。これらをRFPで「標準に含む」「別途見積もり」「対象外」と仕分けして問えば、提案の前提が明確になります。
とくに、データ復旧やOSS（オープンソース）の保守、クラウド側の障害対応といった想定外費用になりやすい領域は、意思決定の段階で手当てしておくべきです。RFPでこれらの扱いを問わずに契約すると、いざ必要になったときに高額な追加請求を受け、予算が崩れます。対応範囲と除外範囲を表形式で整理し、グレーゾーンを残さないことが、運用サポートのRFPを実務的に機能させるコツです。範囲が明確であればあるほど、提案各社の見積もりは比較しやすくなり、契約後のトラブルも減ります。
価格偏重を避ける評価基準の設計
RFPの締めくくりとして設計すべきが、提案を評価する基準です。運用サポートで価格だけを重視して最安値の業者を選ぶと、品質が伴わず、結局は障害対応に追われてかえって高くつくことがあります。価格と品質のバランスを取る評価基準を、あらかじめ設計しておくことが重要です。
価格配点を抑え品質・体制を重視する評価軸
評価基準を設計するときの定石が、価格の配点を意図的に抑えることです。価格に過度な比重を置くと、品質を犠牲にした安値提案が有利になり、運用開始後に痛い目を見ます。そこで、SLAの達成体制、障害対応のプロセス、運用体制の人員と経験、ドキュメント整備の方針、責任分界点への理解といった品質・体制面の項目に十分な配点を割り当て、価格はそれらを満たしたうえでの比較材料と位置づけます。
価格を評価する際も、初期費用や月額の表面的な安さだけでなく、総保有コスト（TCO）で見ることが大切です。年間保守費は開発費の15〜20%が目安とされ、規模別の月額は小規模5〜15万円、中規模15〜50万円、大規模50〜200万円以上が相場です（出典：ripla）。この相場から大きく外れて安い提案は、必要な業務が抜けているか、追加費用が後から積み上がる可能性を疑うべきです。評価基準で価格配点を抑えることは、品質を担保しながら、安かろう悪かろうの落とし穴を避けるための設計なのです。
移管・引き継ぎのしやすさを評価項目に入れる
見落とされがちですが、評価基準に「将来、別のベンダーへ移管する際のしやすさ」を入れておくことを強くおすすめします。運用サポートは長期にわたる関係になりますが、いつかは契約終了や乗り換えの局面が来ます。そのとき、ドキュメントが整備されていなかったり、独自パッケージへの依存でロックインされていたりすると、移管が泥沼化します。
そこでRFPでは、ドキュメントの整備方針、ソースコードや構成情報の開示範囲、契約終了時の引き継ぎ協力の取り決めを問い、これを評価項目に含めます。とくにソースコードの著作権の帰属や、独自パッケージへの依存度は、将来のロックインリスクに直結するため、契約段階で確認しておくべきです。入口のRFPで出口（移管）のことまで設計しておくことが、特定ベンダーへの過度な依存を避け、長期的な交渉力を保つことにつながります。良いRFPは、契約を結ぶときだけでなく、契約を解くときのことまで見据えて作られているのです。
まとめ
ITシステム運用サポートのRFP・要件定義書を作るうえで核心になるのは、目に見えにくいサービスの質を数値と文書で定義することです。SLAは稼働率99.9%や初報応答15分・復旧4時間といった数値で定め、未達時のペナルティと発動条件まで問う。クラウド責任共有を前提に、ベンダーのコントロール外障害の扱いと契約形態（準委任・請負）を明記する。現状の課題を定量化し、対応範囲と除外範囲を両方示して曖昧さを排する。そして評価基準では価格配点を抑え、品質・体制と移管のしやすさまで評価項目に入れる。これらが揃って、はじめて比較可能で揺るがないRFPになります。
RFPを書くときに忘れてはいけないのは、入口の発注時点で出口の移管まで見据えることです。責任分界点と移管のしやすさを要件化しておくことが、長期的な交渉力とコストの透明性を守ります。riplaはフルスクラッチ受託と国内運用保守の立場から、SaaS・クラウド時代の責任分界点まで踏み込んだ要件整理と、作った後も継続的に伴走する運用設計を支援します。全体像の確認には、あらためて完全ガイドをご活用ください。
株式会社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を創業。