システムの運用保守を外部に委託しようとするとき、最も悩ましいのが「RFP（提案依頼書）や要件定義書に、運用保守の要件をどう書けばよいか」という問題です。開発のRFPなら機能要件を列挙すればよいのですが、運用保守は「止めずに守り続ける」という継続的なサービスが対象であり、品質を曖昧な言葉で書くと、ベンダーごとにバラバラな前提で見積もりが返ってきて比較になりません。「迅速に対応します」「しっかり監視します」といった定性的な記述では、いざ障害が起きたときに「想定と違う」というトラブルに直結します。
本記事は、運用保守のRFP・要件定義書・提案依頼書をどう作るかを、発注企業の視点から実務的に解説する「要件定義特化」の解説です。クラウドの責任共有モデルを前提にした責任分界点の明文化、稼働率や応答・復旧時間を数値で書くSLA要件、価格配点を抑えた提案評価軸、そして曖昧な要求をベンダーに正しく伝える翻訳の技術まで、一次データとあわせて具体的に解説します。なお、運用保守の全体像をまだ把握していない方は、まず運用保守の完全ガイドから読むことをおすすめします。読み終えるころには、ベンダーから精度の高い提案を引き出す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はフルスクラッチ受託と国内運用保守の立場から、この責任分界点の明文化を最重視しています。
想定外費用の手当てを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はフルスクラッチ受託と国内運用保守を組み合わせ、責任分界点まで踏み込んだ運用保守の要件定義と、作った後も続く伴走を一貫して支援します。
株式会社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を創業。