ITシステムの維持管理を外部に委託するとき、その成否を最初に左右するのが、RFP（提案依頼書）と要件定義の精度です。開発の発注なら「何を作るか」を書けば見積もりが取れますが、維持管理は「作ったものを、これからどう守り続けてもらうか」を発注する行為です。形のある成果物がないだけに、要件が曖昧なまま発注すると、ベンダーごとに見積もりの前提がバラバラになり、比較すらできません。さらに、契約後になって「それは保守の範囲外です」と言われ、想定外の追加費用に苦しむことになります。
本記事は、ITシステム維持管理のRFP・要件定義書・提案依頼書をどう作り込むかを掘り下げる「要件定義特化」の解説です。対象範囲と現状をどう棚卸しするか、SLAや処理速度をどう数値で要件化するか、クラウドの責任共有を前提にどう責任分界を定義するか、そして価格に偏らない評価軸をどう設計するかを、一次データとあわせて具体的に解説します。なお、ITシステム維持管理の全体像をまだ把握していない方は、まずITシステム維持管理の完全ガイドから読むことをおすすめします。
▼全体ガイドの記事
・ITシステム維持管理の完全ガイド
対象範囲と現状を棚卸しするRFPの土台
維持管理のRFPで最初にやるべきは、「何を、どこまで守ってほしいのか」という対象範囲と現状の棚卸しです。ここが曖昧だと、ベンダーは見積もりの前提を自分で勝手に置くしかなく、結果として各社の提案が比較不能なバラバラの内容になります。発注側が現状を正確に開示できているかどうかが、良質な提案を引き出せるかの分かれ目になります。
システム構成と現行運用を開示する記載項目
RFPには、対象システムの構成を具体的に書き込みます。サーバーの台数と種別、利用しているOSやミドルウェア、データベース、連携している外部システムやSaaS、利用者数やアクセス傾向、稼働しているOSSライブラリの一覧などです。加えて、現在どんな運用が行われているか（監視の有無、バックアップの頻度、過去1年の障害件数とその内容）も開示します。この情報があって初めて、ベンダーは「どれだけの手間がかかるシステムか」を正しく見積もれます。
ここで意識したいのが、維持管理費の相場感です。年間保守費は開発費の15〜20%が一つの目安とされ、規模別の月額は小規模で5〜15万円、中規模で15〜50万円、大規模で50〜200万円以上が目安です（出典：ripla）。自社のシステムがどの規模帯に位置するのかを、構成情報をもとにベンダーと共通認識にしておくと、提示された見積もりが妥当かどうかを判断しやすくなります。現状開示を怠ると、ベンダーはリスクを見越して高めの見積もりを出すか、後から「想定と違った」と追加費用を請求してくることになります。
保守範囲と範囲外を明示する要件化
対象範囲の棚卸しで特に重要なのが、「保守の範囲に含めるもの」と「含めないもの」を明示的に線引きすることです。維持管理の業務は、定期保守・監視・障害対応・問い合わせ対応・軽微改修・管理報告という構成で成り立っています（出典：ripla）。RFPでは、このそれぞれについて、どこまでを月額の定額に含め、どこからを別途見積もりとするかを定義します。特にトラブルになりやすいのが、OSSライブラリの脆弱性対応、データ復旧作業、大幅な仕様変更といった、グレーゾーンになりやすい業務です。
これらを「範囲外」とするなら、その場合の費用算出方法（人月単価や時間単価）まで要件化しておくと安心です。人月単価は運用要員で60万〜150万円、サービス委託で月20万〜50万円が目安とされます（出典：ripla）。範囲を曖昧にしたまま「何かあったら相談」では、いざというときに見積もりの根拠で揉めます。RFPの段階で「軽微改修は月◯時間まで定額に含む」「それを超える改修は時間単価◯円」というように、できる限り定量的に線引きすることが、後の想定外費用を防ぐ最大の防波堤になります。
SLAと処理速度を数値で要件化する
維持管理のRFPで品質を担保する核心が、SLA（サービスレベル合意）と処理速度の数値要件です。「安定して動かしてほしい」「障害があれば早く直してほしい」といった定性的な希望では、達成したかどうかを後から検証できません。曖昧な要求は、ベンダーにとって都合よく解釈される余地を残します。だからこそ、品質を測定可能な数値として要件化することが、維持管理の発注では決定的に重要になります。
稼働率・応答・復旧時間の数値要件と相場
SLAの要件化では、稼働率・初報応答時間・復旧時間を具体的な数値で定めます。実値の相場としては、稼働率は99.9%（月あたり約43分の停止許容）または99.5%、初報応答は重大障害で15分・通常障害で2時間、エスカレーションは30分、回答は24時間以内、復旧時間は重大障害で4時間・通常障害で8時間、恒久対応は5営業日が一つの目安です（出典：ripla）。RFPには、自社の事業にとってどの水準が必要かを、業務の重要度に応じて記載します。
注意したいのは、稼働率の目標を闇雲に厳しくしないことです。99.9%と99.99%では、求められる冗長構成や監視体制が大きく変わり、当然ながら費用も跳ね上がります。自社の業務が、本当に分単位の停止も許されないのか、それとも数時間の停止なら許容できるのかを冷静に見極め、過剰品質にならない水準を要件化することが、費用対効果の高い維持管理につながります。また、SLA未達時のペナルティ（減額条項）を盛り込むなら、未達の判定基準と適用方法まで具体的に定義しておかないと、原因が有耶無耶になって実効性を失います。
処理速度などの非機能要件を定量化する
SLAと並んで要件化すべきが、処理速度をはじめとする非機能要件です。維持管理は安定稼働を保つだけでなく、利用者が快適に使える性能を維持する責務も負います。RFPの例では、「全画面の表示を3秒以内」といった処理速度の数値要件を明記するケースがあります（出典：ripla）。こうした性能の基準をあらかじめ定めておけば、運用中にレスポンスが劣化したとき、それが許容範囲を超えたかどうかを客観的に判断でき、改善の交渉がしやすくなります。
非機能要件には、処理速度のほかにも、同時接続数の上限、データ量の増加に対する対応、セキュリティの基準などが含まれます。これらは「動いていれば良い」という機能要件とは別の軸であり、見落とされがちですが、利用者の満足度や事業継続性に直結します。RFPで非機能要件を定量化しておくことの価値は、運用が始まってから「遅い」「重い」といった主観的なクレームを、数値という共通の物差しで議論できるようにする点にあります。曖昧な期待値のまま委託すると、性能をめぐる水掛け論に巻き込まれることになります。
クラウド責任共有を前提に責任分界を定義する
現代のITシステム維持管理のRFPで、もっとも見落とされがちで、かつ最も重要なのが、クラウドの責任共有モデルを前提にした責任分界点の定義です。自社システムが、クラウド基盤や複数の外部SaaSと連携して動いている以上、障害の原因は「ベンダーがコントロールできる範囲」だけにとどまりません。この前提を要件定義に織り込まないと、いざ障害が起きたときに「それは弊社の責任ではない」という押し問答に陥ります。
クラウド・SaaS障害という「コントロール外」の要件化
RFPでは、障害を「ベンダーが直接コントロールできるもの」と「コントロール外のもの」に分けて、それぞれの対応を要件化します。コントロール外の典型が、クラウド事業者側で起きた大規模障害、連携先SaaSのAPI仕様変更、そしてAIを組み込んだシステムにおける予期せぬ挙動です。これらはベンダーの過失ではないため、復旧そのものを保証させることはできません。しかし、「監視して速やかに検知する」「状況を報告する」「代替手段や暫定対応を講じる」という役割は要件化できます。
たとえば連携SaaSのAPI仕様が変更されると、自社システムとの連携が突然動かなくなることがあります。RFPで「連携先の仕様変更を継続的に監視し、影響が見込まれる場合は事前に検知して改修の見積もりを提示する」と要件化しておけば、ある日突然連携が壊れて慌てる事態を防げます。コントロール外の事象についても「何をどこまで責任を持つか」を明文化することこそ、モダンな環境の維持管理RFPの肝です。障害ゼロは保証できなくても、障害時の振る舞いは要件として定義できるのです。
準委任・請負の契約形態を要件に組み込む
責任分界の定義は、契約形態の選択とも密接に関わります。維持管理では、日々の定常運用は成果を約束しない準委任契約、明確な成果物を伴う作業は請負契約、というように業務の性質に応じて使い分けるのが一般的です（出典：ripla）。準委任は「善良な管理者としての注意義務をもって業務を遂行する」契約であり、特定の成果（たとえば障害ゼロ）を保証するものではありません。この性質を理解せずに準委任で契約し、後から「障害が起きたのは契約違反だ」と主張しても通りません。
RFPの段階で、どの業務をどの契約形態で発注するつもりかを示しておくと、ベンダーからの提案の前提が揃い、比較しやすくなります。また、将来のベンダー乗り換えに備えて、契約終了時のドキュメント引き渡しや後継ベンダーへの協力義務を要件に含めておくことも、責任分界の定義の一部です。これを最初の契約に盛り込んでおかないと、いざ移管しようとしたときに引き継ぎを拒まれ、法的ロックインの泥沼に陥ります。責任分界とは、平常時だけでなく、契約を終えるときの責任までを見据えて定義するものなのです。
価格に偏らない評価軸を設計する
RFPを出して複数のベンダーから提案が集まったとき、それをどう評価するかの軸を、あらかじめ設計しておく必要があります。ここで陥りやすい罠が、価格の配点を高くしすぎることです。維持管理は長期にわたる継続的な関係であり、目先の安さだけで選ぶと、品質や対応力の低さで後悔します。評価軸の設計は、RFPを作る段階から始まっているのです。
価格配点を抑え品質・体制を重視する評価設計
評価軸を設計するときは、価格の配点を意図的に抑え、品質・対応体制・実績といった定性的な軸に十分な比重を置くことが推奨されます（出典：ripla）。具体的な評価項目としては、SLA達成の体制、障害対応の実績と事例、担当者の技術力と専門性、報告やコミュニケーションの質、そして自社の業務領域への理解度などが挙げられます。これらを点数化し、価格はあくまで複数の評価軸の一つとして位置づけることで、安かろう悪かろうのベンダーを選んでしまうリスクを下げられます。
背景として知っておきたいのが、保守費が高止まりしやすい構造です。多重下請けの構造や、いつでも対応できるよう待機している要員のコストが、見積もりに乗っていることがあります。だからこそ、提示された価格の安さだけでなく、「その価格でどんな体制が組まれ、誰が実際に手を動かすのか」まで提案させ、評価することが大切です。極端に安い提案は、実は対応が手薄だったり、後から追加費用で帳尻を合わせる前提だったりすることもあります。価格の裏側にある体制を読み解く評価軸こそ、長期的な失敗を避ける鍵です。
曖昧な要求を翻訳して提案の質を引き上げる
RFPの質を高める最後の鍵が、社内の曖昧な要求を、ベンダーが提案できる形へ「翻訳」することです。現場からは「とにかく止まらないようにしてほしい」「何かあったらすぐ動いてほしい」といった漠然とした要望が上がってきます。これをそのままRFPに書いても、各社が思い思いに解釈してしまい、提案の比較ができません。発注側の役割は、こうした曖昧な要求を、稼働率や応答時間といった測定可能な要件へ変換することです。
この翻訳には、自社の業務とITの両方を理解した知見が必要です。もし社内にその知見が乏しければ、要件定義の段階から伴走してくれるパートナーの力を借りるのも一つの選択です。riplaはフルスクラッチ受託と国内運用保守の立場から、現場の曖昧な要望を整理し、測定可能なSLAや非機能要件へ落とし込む支援を行っています。良いRFPは、ベンダーに丸投げする文書ではなく、自社が何を求めているかを自ら言語化し、提案の土俵を整える文書です。要件定義に手間をかけるほど、その後の運用は安定し、想定外の費用やトラブルは減っていきます。
まとめ
ITシステム維持管理のRFP・要件定義を振り返ると、その精度は四つの要素で決まります。対象範囲と現状の棚卸し（保守範囲と範囲外の線引き）、SLAと処理速度の数値要件化（稼働率99.9%、初報15分〜2時間、復旧4〜8時間、全画面3秒以内など）、クラウド責任共有を前提にした責任分界の定義、そして価格に偏らない評価軸の設計です。これらを具体的に書き込むほど、ベンダーの提案は比較可能になり、契約後の想定外費用やトラブルは減っていきます。
維持管理の発注は、形のない「守り続ける活動」を約束させる行為です。だからこそ、曖昧な要求を測定可能な要件へ翻訳し、コントロール外の事象まで含めて責任を明文化する手間が、後の安定を生みます。まずは自社システムの現状を棚卸しし、本当に必要なSLA水準を見極めることから着手してください。riplaはフルスクラッチ受託と国内運用保守を組み合わせ、要件定義の段階から伴走し、現場の要望を実効性のある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を創業。