ソフトウェア運用保守を外部に委託するとき、プロジェクトの成否を大きく左右するのが、保守のRFP（提案依頼書）と要件定義です。運用保守は開発と違って成果物が目に見えにくく、「いつまでに、どの品質で、どこまで対応してもらうか」を契約前に数値で定義しておかないと、後から「そこまでは契約に含まれていない」というすれ違いが必ず起きます。とくに現代のシステムは、クラウドや外部SaaS、AIと連携して動くため、「どこまでがベンダーの責任範囲なのか」という責任分界点を要件として明文化することが、従来以上に重要になっています。
本記事は、ソフトウェア運用保守のRFP・要件定義書・提案依頼書を、発注企業の視点から具体的に解説する「要件定義特化」の記事です。クラウドの責任共有モデルを前提とした責任分界点の定義、曖昧な要求を測定可能なSLA数値へ翻訳する方法、稼働率や処理速度といった非機能要件の書き方、そして価格配点を抑えて品質を評価するRFPの作り方まで、運用保守の実務に即して掘り下げます。読み終えるころには、ベンダーに渡すRFPの骨子が描けるはずです。なお、運用保守の全体像をまだ把握していない方は、まずソフトウェア運用保守の完全ガイドから読むことをおすすめします。
▼全体ガイドの記事
・ソフトウェア運用保守の完全ガイド
責任分界点を定義するRFPの要件
運用保守のRFPで、現代もっとも重要かつ見落とされやすいのが、責任分界点の定義です。かつてのシステムは自社のサーバーで完結していましたが、今のシステムはクラウド基盤の上で動き、外部のSaaSとAPIで連携し、AI機能を組み込んでいることが珍しくありません。こうした構成では、障害が起きたときに「どこに原因があり、誰が対応する責任を負うのか」が複雑になります。この責任の境界をRFPで明確にしておかないと、いざ障害時に責任の押し付け合いが起きます。
クラウド責任共有モデルを前提に範囲を切る
クラウドサービスには「責任共有モデル」という考え方があり、クラウド基盤側が責任を持つ範囲と、利用者（およびその運用保守ベンダー）が責任を持つ範囲が分かれています。たとえばクラウド基盤そのものの障害は基盤提供者の責任ですが、その上に構築したアプリケーションの設定や監視は利用者側の責任です。RFPでは、この責任共有モデルを前提に、「クラウド基盤の障害時にベンダーは何をするのか（状況把握と報告までか、代替手段の実行までか）」を具体的に定義します。
とくに重要なのが、ベンダーのコントロール外で起きる障害の扱いです。クラウド基盤の大規模障害、連携先SaaSのAPI仕様の予告なき変更、AI機能が誤った出力をするハルシネーションなど、ベンダーが直接コントロールできない事象は確実に存在します。これらをRFPで「対象外」と切り捨てるのか、「監視・検知・報告・代替策の提示までは行う」と定義するのかで、運用保守の実質的な価値はまったく変わります。多くのRFPはここを曖昧にしたまま契約し、いざクラウド側の障害が起きたときに「それはうちの責任ではない」とベンダーに突き放されます。コントロール外の障害について、検知・報告・暫定対応のどこまでを求めるかを要件として明記することが、現代の運用保守RFPの肝です。
準委任か請負かを要件として明確にする
運用保守のRFPでは、契約形態をどうするかも要件として明確にする必要があります。一般に、監視やバックアップ、問い合わせ対応といった定常的な運用業務は、成果物ではなく業務の遂行そのものを委託する準委任契約が適しています。一方、特定の改修やバージョンアップのように、明確な成果物を完成させる業務は請負契約が向いています。この切り分けを曖昧にすると、「常駐して対応してほしい部分」と「成果物として納めてほしい部分」が混在し、責任の所在が分からなくなります。
RFPの段階で、定常運用は準委任、個別の改修案件は請負、というように業務の性質ごとに契約形態を整理して提示すると、ベンダーは見積りを出しやすくなり、責任範囲も明確になります。準委任では「どれだけの時間・体制で対応するか」を、請負では「何をいつまでに完成させるか」を定義します。契約形態は法務上の責任の所在に直結するため、要件定義の段階で曖昧なまま進めず、業務ごとにどちらが適切かを言語化しておくことが、運用開始後のトラブルを防ぎます。
曖昧な要求をSLAの数値要件へ翻訳する
運用保守の要件定義でもっとも難しいのが、「安定して動いてほしい」「障害時はすぐ対応してほしい」といった曖昧な要求を、測定可能な数値要件へ翻訳することです。曖昧な言葉のまま契約すると、「すぐ」が発注側にとっては30分、ベンダーにとっては翌営業日、というすれ違いが起きます。要件は、必ず数値で定義する必要があります。
稼働率・応答時間・復旧時間を数値で定義する
「安定稼働してほしい」という要求は、稼働率という数値に翻訳します。稼働率99.9%なら月の停止は約43分まで、99.5%なら月の停止許容はそれより長くなります（出典：ripla）。一見すると99.9%と99.5%の差は小さく見えますが、許容される停止時間も対応に必要な体制も大きく変わり、費用にも直結します。自社の業務がどれだけの停止に耐えられるかを起点に、過剰でも過少でもない稼働率を要件として定めることが大切です。
「障害時はすぐ対応してほしい」という要求は、初報応答時間・エスカレーション時間・復旧時間に分解して数値化します。実務的な目安としては、初報応答が重大障害で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は、提案を横並びで比較できるだけでなく、契約後の運用そのものを安定させます。SLAの数値が現場の体制と報告で支えられ、改修の扱いが明確で、移行とドキュメントが整っていれば、運用は予測可能なものになります。要件定義は単に発注のための書類づくりではなく、運用開始後の数年間の品質をあらかじめ設計する作業だと捉えることが、ソフトウェア運用保守のRFPを成功させる鍵です。
まとめ
ソフトウェア運用保守のRFP・要件定義書・提案依頼書は、責任分界点の定義から始めるのが現代の鉄則です。クラウド責任共有モデルを前提に、ベンダーのコントロール外の障害をどこまで対応範囲とするかを明記し、定常運用は準委任・個別改修は請負と契約形態を整理する。そのうえで「安定」「すぐ対応」といった曖昧な要求を、稼働率99.9%、初報15分、復旧4時間、処理速度3秒以内（出典：ripla）といった測定可能な数値へ翻訳しきることが、要件定義の質を決めます。
RFPでは価格配点を抑え、品質と体制を評価軸の中心に据え、保守費の相場（開発費の15〜20%、月額小5〜15万/中15〜50万/大50〜200万：出典ripla）に照らして見積りの妥当性を判断します。数値で定義された要件こそが、運用開始後のすれ違いを防ぎ、品質を契約で担保します。riplaはフルスクラッチ受託と国内運用保守を組み合わせ、責任分界点の明確化からSLAの数値設計、RFP作成までを発注企業と協働で支援します。全体像の確認には、あらためて完全ガイドをご活用ください。
株式会社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を創業。