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