運用保守のRFPと要件定義書では、責任分界点と数値のSLAを契約前に決めておくことが大切です。
成果物が見えにくい運用保守は、ここが曖昧だと「そこまでは契約に含まれていない」というすれ違いが後から起きます。全体像をまだ把握していない方は、まずソフトウェア運用保守の完全ガイドから読むと流れがつかめます。
▼全体ガイドの記事
・ソフトウェア運用保守の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
責任分界点を定義するRFPの要件
運用保守のRFPで、今もっとも重要で見落とされやすいのが、責任分界点の定義です。かつてのシステムは自社のサーバーで完結していましたが、今はクラウド基盤の上で動き、外部のSaaSやAPIと連携し、AI機能を組み込んでいることも珍しくありません。
こうした構成では、障害が起きたときに原因の所在と対応の責任が複雑になるため、RFPで境界を明確にしておかなければ、いざというときに責任の押し付け合いが起きかねません。
クラウド責任共有モデルを前提にした範囲の切り分け
クラウドサービスには「責任共有モデル」という考え方があり、クラウド基盤側が責任を持つ範囲と、利用者（およびその運用保守ベンダー）が責任を持つ範囲が分かれています。たとえば、クラウド基盤そのものの障害は基盤提供者の責任ですが、その上に構築したアプリケーションの設定や監視は利用者側の責任です。
そのため、RFPでは「クラウド基盤の障害時にベンダーは何をするのか（状況把握と報告までか、代替手段の実行までか）」を具体的に定めます。とくに重要なのは、ベンダーのコントロール外で起きる障害の扱いです。クラウド基盤の大規模障害や、連携先SaaSのAPI仕様の予告なき変更、AI機能が誤った出力をするハルシネーションなど、ベンダーが直接コントロールできない事象は確実に起こります。
その障害を「対象外」とするか、「監視・検知・報告・代替策の提示までは行う」と定めるかで、運用保守の実質的な価値は大きく変わります。多くのRFPはここを曖昧にしたまま契約し、クラウド側の障害時に「それはうちの責任ではない」と突き放されがちです。コントロール外の障害について、検知・報告・暫定対応のどこまでを求めるかを明記することが、運用保守RFPの肝です。
準委任と請負の使い分け
運用保守のRFPでは、契約形態も要件として明確にしておく必要があります。業務の性質によって、向いている契約形態が異なるためです。
- 定常的な運用業務：監視、バックアップ、問い合わせ対応などは準委任契約が適しています。
- 特定の改修やバージョンアップ：明確な成果物を完成させる業務は、請負契約が向いています。
準委任は、成果物よりも業務の遂行そのものを委託する契約で、どれだけの時間・体制で対応するかを定めます。請負は、何をいつまでに完成させるかを定めます。この切り分けが曖昧だと、「常駐して対応してほしい部分」と「成果物として納めてほしい部分」が混ざり、責任の所在が分からなくなります。
RFPの段階で業務ごとの契約形態を示しておくと、ベンダーは見積りを出しやすくなり、責任範囲も明確になります。
契約形態は法務上の責任の所在に直結するため、要件定義の段階で業務ごとにどちらが適切かを言葉にしておくと、運用開始後のトラブルを防ぎやすくなります。
曖昧な要求のSLA数値要件への翻訳
運用保守の要件定義で難しいのは、「安定して動いてほしい」「障害時はすぐ対応してほしい」といった曖昧な要求を、測定できる数値要件に置き換えることです。言葉のまま契約すると、「すぐ」が発注側では30分、ベンダーでは翌営業日と受け取られ、すれ違いが起きてしまいます。だからこそ、要件は数値で定義しておく必要があります。
稼働率・応答時間・復旧時間の数値定義
「安定稼働してほしい」という要求は、稼働率という数値に置き換えます。稼働率99.9%なら月の停止は約43分までで、99.5%なら月の停止許容はそれより長くなります（出典：ripla）。一見すると両者の差は小さく見えますが、許容される停止時間も対応体制も大きく変わり、費用に直結します。
そこで、自社の業務がどれだけの停止に耐えられるかを起点に、過剰でも過少でもない稼働率を定めることが大切です。「障害時はすぐ対応してほしい」という要求は、初報応答時間・エスカレーション時間・復旧時間に分けて数値にします。実務的な目安としては、初報応答が重大障害で15分以内・通常障害で2時間以内、エスカレーションが30分以内、回答が24時間以内という水準があります。
復旧は重大4時間以内・通常8時間以内、恒久対応は5営業日以内という水準もあります（出典：ripla）。要件では、障害の重大度をどう区分し（重大・通常・軽微など）、区分ごとにこの時間をどう約束するかを定めます。区分の基準が曖昧だと、「これは重大ではない」とベンダーに判断され、約束した時間が適用されなくなるため、区分の定義まで踏み込むことが大切です。
処理速度・性能の非機能要件の明記
運用保守の要件には、システムの性能を保つための非機能要件も含めます。たとえば「画面表示が遅くならないようにしてほしい」という要求は、処理速度の数値に置き換えます。実際のRFPでは「全画面の表示を3秒以内」といった処理速度の要件が定められることがあり（出典：ripla）、この基準を運用保守の中で維持・監視する責任をベンダーに求めます。
性能要件が曖昧だと、データ量の増加でシステムが徐々に遅くなっても、ベンダーは「契約上の責任ではない」と対応を見送れてしまいます。さらに、非機能要件には性能のほかにセキュリティと可用性も含めます。セキュリティでは、脆弱性が公表された際にいつまでにアップデートするかを、可用性ではバックアップの頻度と保管期間、障害時のデータ復旧の範囲を定めます。
こうした非機能要件は、運用が始まってから「遅い」「漏れる」「戻せない」という形で問題が表面化します。そのため、要件定義の段階で数値とともに明記しておくことが、運用保守の品質を契約で担保する方法です。曖昧な要求を残さず、すべて測定可能な数値に置き換えられているかどうかが、要件定義の質を左右します。
RFPの評価軸と見積り妥当性の判断
要件を数値にできたら、それをRFPにまとめ、複数のベンダーに提案を依頼します。運用保守のRFPは、機能の有無だけでなく、「どの品質で、どの体制で、いくらで」提供されるかを比べられるようにすることが目的です。とくに評価軸の設計と見積りの妥当性の判断が、ベンダー選定の質を決めます。
価格配点を抑え、品質・体制を重視する評価軸
運用保守のベンダー選定で陥りやすいのが、月額の安さだけで決めてしまうことです。価格を評価軸の中心に置くと、安くても対応の薄いベンダーが選ばれ、結局は障害が長引いて事業損失が膨らむという本末転倒が起きます。運用保守は安さで選ぶとかえって高くつく、という構造を押さえておくことが大切です。
そこで、RFPの評価軸では価格の配点を意図的に抑えます。あわせて、SLAの達成体制や障害対応の実績を見るとともに、ドキュメント整備や報告の質にも配点を厚くすることをおすすめします。評価で必ず確認したいのは、実際に運用を担う体制です。
提案時には経験豊富な担当者が出てきても、実運用は別の手薄なチームが担うケースがあります。そのため、RFPで体制図と担当者の経験を提示させ、エスカレーション時に誰がどう動くのかを確認します。価格・品質・体制を総合した評価軸を設計することで、目先の安さに惑わされず、長く安心して任せられるベンダーを選べます。
保守費の相場による見積りの妥当性判断
集まった見積りの妥当性を判断するには、相場観が欠かせません。年間の運用保守費は、開発費の15〜20%が目安とされ、規模別の月額は小規模で5〜15万円、中規模で15〜50万円、大規模で50〜200万円以上が一つの目安です（出典：ripla）。運用要員の人月単価は60万〜150万円とされます（出典：ripla）。
見積りがこの相場から大きく外れている場合は、その理由を確認します。安すぎる場合は監視や障害対応の体制が薄い可能性があり、一方で高すぎる場合は、不要な体制や中間マージンが乗っている可能性があります。要件定義とRFPが詳細であるほど、ベンダーは精緻な見積りを出さざるを得ません。
「運用保守一式」のようにまとめられた見積りは、何にいくらかかるかが見えず、定期保守と監視、障害対応を分けて費用を示してもらうことで、問い合わせと軽微改修、管理報告も含め、自社のニーズと照らして過不足を見極められます。riplaは、フルスクラッチ受託と国内運用保守を組み合わせ、責任分界点を明確にした要件整理と、内訳を開示した見積りの提示を重視しています。
運用設計・体制・報告の要件化
責任分界点とSLAの数値要件を定めたら、次は運用設計・体制・報告を要件に落とし込みます。どれだけ立派なSLAを掲げても、それを支える体制や報告の仕組みが要件になっていなければ、品質は保てません。そのため、RFPには運用の実務がどう回るのかを問う項目を盛り込み、提案で具体的に示させることが大切です。
運用設計の要件は数値要件と違って見落とされがちですが、ここが曖昧だと契約後の運用はうまく回りません。「稼働率99.9%を約束します」と提案に書かれていても、それを誰がどの体制で支えるのか、品質をどう報告するのかが定義されていなければ、数値は実態を伴いません。
運用が日々どう回り、何が報告され、変更にどう対応するのかという実務の設計まで要件に含めることで、RFPは運用開始後の現実に耐えるものになります。
対応体制・稼働時間・報告頻度の要件化
運用設計の要件では、まず対応体制と稼働時間を明確にします。平日日中のみの対応か、夜間休日も含む24時間365日か、オンコール体制があるかどうかは、SLAの実現可能性と費用を大きく左右します。重大障害の初報応答を15分以内（出典：ripla）と求めるなら、それを実現する監視と要員配置を体制要件として定める必要があります。
体制を要件に含めずにSLAだけを求めると、提案では数値を満たすと書かれていても、実態の伴わない契約になりかねません。あわせて、報告の頻度と内容も要件に定め、月次報告では、稼働率の実績や障害の発生件数と対応状況、問い合わせの傾向を示させ、改修の消化状況も共有させます。そうすれば、発注側は運用の実態を把握し続けられます。
報告は形式的な書類ではなく、品質を監視し、運用のブラックボックス化を防ぐための重要な仕組みです。報告が要件に入っていないと、運用はベンダー任せになり、品質の監視もシステムの状態も社内から見えなくなります。RFPでは、報告の書式と頻度まで具体的に求めておきましょう。
移行期間とドキュメント整備の要件
運用保守を新たに委託したり乗り換えたりする場合は、開始時の「移行期間」も要件に含めるべきです。新ベンダーが現行システムを把握するには引き継ぎ期間が要り、それを設けずに本番運用を求めると、初期に障害対応の質が落ちます。そのため、RFPには「移行期間として◯か月を設け、その間に現行の構成・運用手順・障害履歴を引き継ぐ」といった条件を盛り込み、提案で移行計画を示させます。
移行設計の有無は、運用立ち上げの安定性を左右します。さらに、運用保守の過程で発生するドキュメントも、整備と最新化を要件に含めます。設計書や運用手順書、監視設定を定められた頻度で更新し、障害対応履歴とあわせて、求めに応じて開示することを義務付けておけば、将来の保守移管時に二重コストや引き継ぎの難航を防げます（出典：ripla）。
ドキュメント要件は、入口の品質を守るだけでなく、長期にわたる運用の透明性と出口の自由度も支えます。riplaは、責任分界点の明確化から、SLAや体制、報告、ドキュメントの要件設計まで、発注企業と協働で支援しています。運用設計まで要件に落とし込んで初めて、RFPは実効性を持ちます。
軽微改修・仕様変更の扱いの線引き
運用設計の要件で見落とされがちなのが、軽微改修や仕様変更の扱いです。運用が始まれば、小さな画面修正やマスタ追加、業務変更に伴う仕様変更といった依頼が必ず発生します。これらを月額の保守に含めるのか、別途見積りの請負にするのかを要件で線引きしておかないと、「これは保守の範囲」「いや追加だ」というすれ違いが日常的に起きます。
軽微改修は保守費の10〜15%が目安とされ（出典：ripla）、月額に含める時間を示すと提案が比較しやすくなります。RFPでは、次の枠組みを示します。
- 月額に含む範囲：「月◯時間までの軽微改修は月額に含む」
- 別見積りの範囲：「それを超える改修や、まとまった機能追加は請負で別見積り」
- 依頼の流れ：依頼から着手・リリースまでのリードタイムと緊急改修の扱いを要件に含めると、期待値が揃います。
改修の線引きを曖昧にしたまま契約すると、発注側は「すぐ直してくれるはず」と期待し、ベンダーは「これは別費用」と構える、というズレが続きます。日々発生する改修こそ、要件定義の段階で扱いを明確にしておくことが、運用のストレスを大きく減らします。
要件定義は、発注のための書類を作る作業にとどまりません。運用開始後の数年間の品質をあらかじめ設計する作業だと捉えることが、ソフトウェア運用保守のRFPを成功させる鍵です。
まとめ
ソフトウェア運用保守のRFP・要件定義書・提案依頼書は、責任分界点の定義から始めるのが現代の鉄則です。クラウドの責任共有モデルを前提に、ベンダーのコントロール外の障害をどこまで対応範囲とするかを明記します。
そのうえで、定常運用は準委任、個別の改修は請負と、業務ごとに契約形態を整理します。次に、「安定」「すぐ対応」といった曖昧な要求を、測定可能な数値へ翻訳しきることが、要件定義の質を決めます。
数値の例は、稼働率99.9%と初報15分です。復旧4時間、処理速度3秒以内も挙げられます（出典：ripla）。
RFPでは価格配点を抑え、品質と体制を評価軸の中心に置きます。さらに、保守費の相場（開発費の15〜20%、月額は小5〜15万・中15〜50万・大50〜200万円）に照らして、見積りの妥当性を判断します（出典：ripla）。
数値で定義された要件があってこそ、運用開始後のすれ違いを防ぎ、品質を契約で担保できます。riplaは、フルスクラッチ受託と国内運用保守を組み合わせ、責任分界点の明確化からSLAの数値設計、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を創業。