開発のRFPとは性質が違い、運用サポートでは、稼働率や応答時間などのサービス品質、責任分界点、契約形態を文書で定めます。
目に見えにくいサービスの質を曖昧にすると、提案各社を比べられず、契約後のトラブルの火種にもなります。全体像は、ITシステム運用サポートの完全ガイドで先に確認できます。
▼全体ガイドの記事
・ITシステム運用サポートの完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
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の稼働率算定から除外するが、状況連絡と暫定対応は標準対応に含める」や「連携SaaSのAPI仕様変更に伴う改修は別途見積もりとする」といった整理があります。
この責任分界の要件化は、競合のRFPテンプレートが見落としがちな差別化ポイントです。さらに、運用後の紛争を未然に防ぐ最大の備えにもなります。
- SLA算定の対象か除外か：事象ごとに、稼働率の算定に含めるか外すかを決める
- 追加対応の費用負担：追加対応が必要になった場合に、誰がどこまで費用を負担するかを取り決める
準委任・請負の契約形態の指定
責任分界と密接に関わるのが、契約形態の指定です。運用サポートは、業務の性質によって準委任契約と請負契約を使い分けます。
一般に、監視や定型運用のように「成果物ではなく業務の遂行」を委託する定常運用は準委任契約が適します。一方で、特定の改修や移行のように「成果物の完成」を約束させたい業務は請負契約が適します。
この区別が大切なのは、契約形態によってベンダーが負う責任の重さが変わるからです。準委任は、善管注意義務に基づいて業務を遂行する責任を負い、請負は成果物を完成させる責任を負います。
両者を混同すると、「成果を約束したはずなのに、努力義務しかないと言われた」といった齟齬が生まれます。そこで、RFPで契約形態の前提を明示し、提案各社に契約形態ごとの責任範囲を確認しておくと、後の認識違いを防げます。
SLAの数値、責任分界点、契約形態の三つは互いに連動しています。そのため、RFPではこれらを一体として要件化することが、揺るがない運用契約の基礎になります。
- 業務ごとの契約形態：どの業務を準委任と請負のどちらで想定しているかを示す
- 責任範囲：契約形態ごとに、ベンダーが負う責任の範囲を回答させる
曖昧な要求の提案可能な要件への翻訳
RFPを作る際に多くの企業がつまずくのが、現場の漠然とした不満や要望を、ベンダーが提案できる具体的な要件に翻訳する作業です。「今のシステムが不安定で困っている」「問い合わせの対応が遅い」といった声をそのままRFPに書いても、ベンダーは何をどう改善すればよいか提案できません。このため、曖昧な要求を測定可能な要件に変換することが、良いRFPの条件になります。
現状の課題の定量化とRFPへの落とし込み
曖昧な要求を翻訳する第一歩は、現状の課題を数字で示すことです。「不安定で困っている」なら過去半年の障害発生件数や停止時間を集計し、「対応が遅い」なら問い合わせから回答までの平均時間を測ります。
この数字を出すには、まず運用対象システムの全体像を洗い出しておく必要があります。具体的には、どのシステムがどのクラウドやサーバー上で動き、どのSaaSと連携しているか、利用者数や取引量はどれくらいかを一覧にします。
この情報がRFPに含まれていないと、提案各社は規模感をつかめません。その結果、見積もりが過大になったり、前提が各社でバラバラになったりします。
曖昧さを残したRFPでは、曖昧な提案しか引き出せません。
- 改善目標：現状の値から、どこまで改善するかの目標値を定める
- システム構成と規模：対象システムの構成と、利用者数や取引量の規模感
RFPには、たとえば「現状の障害月◯件を◯件以下に」「現状の平均対応◯時間を◯時間以内に」のように書けます。
対応範囲と除外範囲の明記
要件を明確にするうえで意外と効くのが、対応範囲と除外範囲を両方明記することです。やってもらうことだけでなく、やらないことも書いておきます。運用サポートの範囲は、監視・障害対応・定期メンテナンスといった標準業務のほかに、軽微改修や機能追加、データ復旧や利用者教育などです。含めるか別料金にするかで揉めやすい領域も、数多くあります。
データ復旧やOSS（オープンソース）の保守、クラウド側の障害対応は、想定外の費用になりやすいため、意思決定の段階で手当てしておくべきです。
RFPで対応範囲を問わないまま契約すると、いざ必要になったときに高額な追加請求を受け、予算が崩れます。こうした事態を防ぐには、どちらにも入らない作業を残さないことが大切です。範囲が明確であるほど、提案各社の見積もりを比べられ、契約後のトラブルも減ります。
- 範囲の区分：「標準に含む」「別途見積もり」「対象外」のどれかを、業務ごとに示させる
- 一覧表：対応範囲と除外範囲を1つの表にまとめる
価格偏重を避ける評価基準の設計
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・クラウド時代の責任分界点まで踏み込んだ要件整理と、作った後も継続的に伴走する運用設計を支援しています。全体像の確認には、あらためて完全ガイドをご活用ください。
▼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を創業。