運用保守のRFPや要件定義書では、業務範囲と責任分界点を線引きし、SLAを数値で定めることが要になります。開発のRFPと違い、運用保守は「止めずに守り続ける」継続的なサービスが対象のため、書き方も変わります。運用保守の全体像は、運用保守の完全ガイドにもまとめています。
▼全体ガイドの記事
・運用保守の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
運用保守RFPにおける業務範囲と前提の明文化
運用保守RFPの出発点は、委託したい業務範囲を曖昧さなく書き出すことです。運用保守は、監視、バックアップ、障害対応、定期メンテナンス、問い合わせ対応、軽微改修などの機能から成ります。そのため、どこまでを委託するかを機能ごとに切り分けて書く必要があります。
さらに、どこを社内に残すかを明示しないと、提案も見積もりも噛み合いません。範囲の線引きこそが、RFPの精度を決める土台になります。
保守費の内訳構造に沿った業務範囲の記述
業務範囲を漏れなく書くには、保守費の内訳構造を下敷きにするのが有効です。保守費は一般に、定期保守20〜30%、監視15〜25%、障害対応25〜35%の割合になります。残りの区分は、問い合わせ対応10〜20%、軽微改修10〜15%、管理報告5〜10%です（出典：ripla）。
区分ごとに「何を、どの頻度で、どこまで委託するか」を記述すれば、ベンダーは見積もりの根拠を揃えやすく、発注側も提案を同じ物差しで比較できます。
特に注意したいのは軽微改修の扱いです。「軽微改修は月◯時間まで定額に含む」「それを超える改修は別途見積もり」といった線引きを書いておかないと、リリース後に「これは保守の範囲外」という追加費用の応酬になります。
仕様変更対応やアップデート対応も同じ考え方で、計画的なバージョンアップを保守に含むのか、別契約とするのかを明記します。範囲を内訳構造に沿って具体的に書くことが、後の費用トラブルを防ぐ最大の予防策です。
- 区分ごとの委託範囲：保守費の内訳のすべての区分について、内容と頻度
- 社内に残す業務：委託しない範囲を、機能ごとに明示する
契約形態（準委任・請負）の要件への織り込み
運用保守のRFPでは、契約形態も要件として明確にしておく必要があります。一般に、監視や問い合わせ対応のような定常的な運用業務は準委任契約、明確な成果物を伴う改修は請負契約というように、性質に応じて使い分けます。
準委任は「善管注意義務をもって業務を遂行する」契約で、成果を約束しません。これに対し請負は「完成した成果物」を約束します。この違いを理解せずに契約すると、責任の所在をめぐって揉めることになります。
RFPで契約形態の枠組みを示しておくと、ベンダーは提案の前提を組みやすくなります。
契約形態をRFPに織り込んでおけば、法務上のリスクを早い段階で減らせます。
- 契約形態の区分：定常運用、改修、仕様変更対応ごとの準委任と請負の使い分け
- 引き継ぎとドキュメント：契約終了時の引き継ぎ範囲と、ドキュメントの権利関係
軽微改修や仕様変更対応は、請負にするかその都度見積もりとするか、といった枠組みも考えられます。
引き継ぎやドキュメントの権利関係も要件に含めておくと、将来のベンダー変更（保守移管）の際にスムーズです。
クラウド責任共有を前提とした責任分界点の定義
現代の運用保守RFPで最も差がつくのは、責任分界点の定義です。多くのシステムがクラウドや外部SaaSと連携して動く今、障害の原因が自社システムなのか、クラウド基盤なのか、連携先のSaaSなのかを切り分ける必要があります。
ここを曖昧にしたまま委託すると、いざ障害時に「うちの責任ではない」という押し付け合いが起き、復旧が止まってしまいます。
責任共有モデルに基づく対応範囲の線引き
クラウドには「責任共有モデル」という考え方があり、クラウド事業者が責任を持つ範囲（物理基盤やネットワークなど）と、利用者側が責任を持つ範囲（アプリケーションやデータ、設定など）が分かれています。
RFPでは、この前提に立って「保守ベンダーはどこまでの責任を負うのか」を明確に線引きする必要があります。
たとえば、クラウド基盤自体の大規模障害は保守ベンダーのコントロール外にあり、SLAの対象外とするのが一般的です。
発注者は、連携先SaaSのAPI仕様変更によって自社システムが動かなくなった場合、その改修を保守の通常範囲に含むのか、別費用とするのかをRFPで定義しておきます。
AIを組み込んだシステムなら、AIの誤った出力（ハルシネーション等）にどう対処するかも論点になります。
こうした「ベンダーのコントロール外で起きる障害」の責任と費用は、事前に決めておくことが欠かせません。競合がほとんど触れない論点ですが、現代のRFPの要所になります。
riplaは、フルスクラッチ受託と国内運用保守の立場から、この責任分界点の明文化を最も重視しています。
- 対応範囲の境界：自社・クラウド基盤・連携先SaaSのうち、保守ベンダーが受け持つ範囲
- API仕様変更の費用：通常保守に含める改修と、別費用とする改修の区分
想定外費用の手当てのRFPへの明記
責任分界点と表裏一体なのが、想定外費用の手当てです。OSSライブラリのサポート終了に伴う緊急対応、データ復旧、クラウド側の障害に起因する作業などは、平時には発生しないものの、起きると高額になる費用です。
そのため、誰がどう負担するかをRFPで定義しておきます。書いておかないと、いざその事態になったときに費用負担で揉め、対応が遅れます。
実務的には、表形式で整理すると分かりやすくなります。
想定外費用の扱いを先に決めておけば、障害発生時に費用を理由に判断をためらうことがなくなり、復旧を最優先で進められます。RFPの段階でこの手当てを書ける発注者は、運用フェーズで大きく有利です。
- 負担区分の整理：通常保守、別途見積もり、クラウド事業者への直接請求の区分
- 想定外作業の区分け：データ復旧やクラウド基盤障害の作業ごとの区分の割り当て
たとえば、クラウド基盤障害の作業は実費精算とする、といった決め方があります。
SLAと処理速度の数値要件化
運用保守RFPの品質要件は、必ず数値で書きます。「迅速に」「安定して」といった形容詞は、ベンダーごとに解釈が分かれ、比較も検証もできません。
稼働率や応答・復旧時間、処理速度を具体的な数字で要件化すると、提案の質が揃い、契約後の運用評価もしやすくなります。
稼働率・応答時間・復旧時間の数値記載
SLA要件の中核は、稼働率と応答・復旧時間です。たとえば、稼働率を99.9%（月間の停止許容は約43分）または99.5%と定めたり、初報応答を重大障害15分・通常2時間、エスカレーションを30分と定めたりします。
発注者は、復旧目安を重大4時間・通常8時間、恒久対応を5営業日とするなど、具体値をRFPに明記します（出典：ripla）。
数値で示した要件があるため、ベンダーは必要な体制を見積もれ、発注者は提案を横並びで比較できます。
ここで重要なのは、求める水準を一律に最高へ設定しないことです。稼働率を99.9%にするか99.5%にするかで、必要な監視体制やオンコール体制が変わり、費用も変わります。
止まると事業が止まる基幹システムなら高い稼働率を、多少止まっても影響の小さいシステムなら現実的な水準を求めるなど、業務の重要度に応じて要件を調整します。
過剰なSLAは過剰なコストを招くため、自社に本当に必要な水準を見極めて数値にすることが、費用対効果の高いRFPの鍵です。
- 稼働率の水準：業務が止まったときの影響に見合う値
- 初報応答と復旧の時間：エスカレーションや恒久対応の期限まで含めた時間の区分
ペナルティ条項と処理速度要件の盛り込み
SLAを数値で書いたら、未達だった場合のペナルティ条項も要件に含めます。たとえば、稼働率や復旧時間を満たせなかった場合に、月額保守費の一定割合を減額する、といった取り決めです。
ただし、原因が誰にあるかが曖昧なままだと、ペナルティは適用されないことが多くなります。そのため、責任分界点の定義とセットで、どんな場合にペナルティが発動するのかを明確に書く必要があります。
実効性のあるペナルティ条項があってこそ、SLAは確かな約束になります。
運用保守の対象が性能を重視するシステムなら、処理速度の要件も数値で書きます。あるRFPの例では「全画面の表示を3秒以内」といった具体的な性能要件を定めています（出典：ripla）。
応答速度が遅いと利用者の生産性が落ちるため、保守の中でパフォーマンスをどう維持するかも要件化する価値があります。
国内のITインフラサービス市場は、2024年の2兆2,685億円から2029年に3兆674億円（年平均成長率6.2%）へ拡大すると見込まれています（出典：IDC）。
運用品質への投資は今後も重要性を増します。
SLA・ペナルティ・処理速度を数値で要件化することが、精度の高い運用保守RFPの要諦です。
- 未達時のペナルティ：原因の所在と、発動する場合の条件
- 処理速度の要件：全画面の表示時間など、性能を測る具体値
提案評価軸の設計と曖昧な要求の翻訳
RFPを出した後、提案をどう評価するかも事前に設計しておく必要があります。
運用保守では、価格だけで選ぶと、品質を落として安く見せたベンダーを選んでしまうリスクがあります。
評価軸の設計と、現場の曖昧な要求をベンダーに正しく伝える翻訳の技術が、良い委託先を選ぶうえでの決め手になります。
価格配点を抑えた品質・体制重視の評価軸
運用保守の提案評価では、価格の配点を意図的に抑えるのが定石です。価格だけを最重視すると、ベンダーは監視を薄くしたり障害対応の体制を絞ったりして見かけの金額を下げ、結果として運用品質が犠牲になります。
評価軸では、SLAの達成見込みや障害対応の体制、エスカレーション設計を見ます。加えて、ドキュメント整備の方針、過去の運用実績、担当者の継続性といった品質・体制面の項目を厚めに配点します。
人月単価の妥当性も評価の材料になります。運用要員の単価は一般に60〜150万円/人月が目安とされ（出典：ripla）、極端に安い提案は、経験の浅い要員や薄い体制を疑う必要があります。
安さの裏に何があるかを見抜くには、見積もりの内訳と体制図の提出を求め、価格と品質のバランスで評価するのが有効です。価格配点を抑えた評価軸は、長期にわたって安定した運用を得るための賢明な投資判断です。
- 提出を求める資料：見積もりの内訳と体制図
- 安い提案の見極め：要員の経験や体制の厚みという観点
曖昧な要求の測定可能な要件への翻訳
現場から上がってくる要求は、しばしば曖昧です。「もっと安定させてほしい」「障害があっても困らないようにしたい」といった声を、そのままRFPに書いてもベンダーは見積もれません。
これらを「稼働率99.9%」「重大障害は4時間以内に復旧」「夜間も30分以内に初動」といった測定可能な要件へ翻訳するのが、発注側の重要な仕事です。曖昧な要求を数値や具体的な振る舞いに落とし込むことで、ベンダーは初めて正確に応えられます。
翻訳の際は、「その要求の裏にある本当の困りごとは何か」を掘り下げると精度が上がります。
たとえば「安定させたい」の背景に「月末の締め処理が止まると経理が回らない」という事情があるなら、月末の特定時間帯の稼働を手厚く保証する、といった具体的な要件に変換できます。
riplaは、フルスクラッチ受託と国内運用保守の立場から、現場の曖昧な要求を測定可能な要件へ翻訳し、責任分界点まで含めた精緻なRFP・要件定義に落とし込む支援を一貫して重視しています。
要件定義の質が、運用フェーズの成否をほぼ決めるのです。
- 数値にする項目：稼働率、初動までの時間、復旧までの時間
- 振る舞いの記述：障害時にベンダーが行う作業と、その完了の目安
まとめ
運用保守のRFP・要件定義書・提案依頼書を作るうえで核になるのは、業務範囲を保守費の内訳構造に沿って明文化することです。
クラウドの責任共有モデルを前提に責任分界点と想定外費用を定義し、SLAと処理速度を数値で要件化して、価格配点を抑えた評価軸で提案を選ぶことも、欠かせません。
稼働率99.9%や復旧目安4時間、人月単価60〜150万円といった一次データを基準にすれば、曖昧さのない要件を書けます（出典：ripla）。
とりわけ、ベンダーのコントロール外で起きる障害の責任と費用を事前に決めておくことが、現代のRFPで最も差がつく部分です。
RFPを作るときに大切なのは、現場の曖昧な要求を「測定可能な要件」へ翻訳する姿勢です。形容詞で書かれた願望を数値と具体的な振る舞いに変換できれば、ベンダーから精度の高い提案を引き出せ、契約後の運用評価も明快になります。
riplaはフルスクラッチ受託と国内運用保守を組み合わせ、責任分界点まで踏み込んだ運用保守の要件定義と、作った後も続く伴走を一貫して支援します。
▼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を創業。