ITシステムの保守管理を外部ベンダーに委託する際、発注の成否を最初に左右するのが、RFP（提案依頼書）と要件定義書の精度です。保守の要件は、新規開発の要件と違って「動くものを作る」ではなく「どんな品質で、どこまでの範囲を、いくらで維持するか」という、定量化しにくい約束を文書に落とし込む難しさがあります。要件が曖昧なまま発注すると、各社の見積もりが横並びで比較できず、契約後に「それは保守範囲外です」というトラブルに直結します。だからこそ、保守管理のRFP・要件定義には独自の作法が必要です。
本記事は、ITシステム保守管理のRFP・要件定義書・提案依頼書をどう書くべきかを、発注企業の視点から実務的に解説する「要件定義特化」の記事です。クラウドの責任共有を前提とした責任分界点の明記、曖昧な要求を定量要件に翻訳する方法、価格の配点を抑えた評価軸の設計、SLAや処理速度の数値要件の書き方まで、SLA実値などの一次データとあわせて整理します。読み終えるころには、ベンダーに正しく比較見積もりを出させるRFPの骨格が描けるはずです。なお、ITシステム保守管理の全体像をまだ把握していない方は、まずITシステム保守管理の完全ガイドから読むことをおすすめします。
▼全体ガイドの記事
・ITシステム保守管理の完全ガイド
責任分界点を明記する保守RFPの前提設計
保守管理のRFPで、現代もっとも重要かつ抜けやすいのが「責任分界点」の明記です。今日のシステムは、自社サーバーだけで完結せず、クラウド（AWS等）の上で、複数のSaaSと連携し、ときにAI機能を組み込んで動いています。そのため、障害が起きたときに「それは誰の責任で、誰が費用を負担するのか」が、従来のオンプレミス時代より格段に複雑になっています。この前提を整理せずに保守RFPを書くと、後で必ず揉めます。
背景には、国内のITインフラサービス市場が拡大し続けている事情もあります。一次データでは、国内ITインフラサービス市場は2024年の2兆2,685億円から2029年に3兆674億円へ、年平均6.2%で成長すると見込まれ（出典：IDC）、マネージドサービス市場も2024年に4兆1,380億円と前年比5.2%増の規模に達しています。クラウドや外部サービスを前提とした運用が当たり前になるほど、責任分界点を要件として描く重要性は増しています。
クラウド責任共有モデルを前提にした範囲定義
クラウド上で動くシステムでは、クラウド事業者が物理基盤やネットワークを担い、利用者がその上のアプリケーションやデータを担うという責任共有の構造があります。保守RFPでは、この前提を明示したうえで、「クラウド事業者側で起きた障害（リージョン障害など）に対して、保守ベンダーはどこまで何をするのか」を要件として定義する必要があります。クラウド側の障害は保守ベンダーのコントロール外ですが、その際の状況把握・連絡・代替手段の検討までを保守範囲に含めるのか否かは、明記しなければ宙に浮きます。
同様に、連携先SaaSのAPI仕様変更への対応も、責任分界の論点です。外部サービスの仕様が予告なく変わって連携が止まったとき、その改修は通常の保守費に含まれるのか、別途の軽微改修扱いになるのかを、RFPの段階で取り決めておくべきです。これらの「ベンダーのコントロール外」の障害に対する責任と費用の考え方は、競合の保守提案でも抜け落ちやすい論点であり、ここを明記したRFPを出せるかどうかが、発注側の成熟度を表します。曖昧にせず、責任の境界を地図のように描くことが、後のトラブルを防ぎます。
準委任・請負の切り分けをRFPに織り込む
保守RFPでは、契約形態の前提も明確にしておくべきです。定常的な運用は準委任、明確な成果物を伴う改修は請負やSESといった形で切り分けるのが一般的です。準委任は「善良な管理者としての注意義務を果たして役務を提供する」契約であり、請負は「成果物の完成」を約束する契約です。この違いを理解せずにRFPを書くと、見積もりの前提がベンダーごとにバラバラになり、比較できません。
実務では、月額固定の運用保守を準委任で結びつつ、大きな改修案件はその都度請負で個別見積もりとする組み合わせが多く見られます。RFPでは「定常運用部分」と「改修・追加開発部分」を分けて要件を提示し、それぞれの契約形態と費用の建て付けを明示することで、各社の提案を同じ土俵で比べられるようになります。契約形態の切り分けを発注側が先に設計しておくことが、フェアな比較見積もりの前提になります。
曖昧な要求を定量要件に翻訳する要件定義
保守RFPで失敗するもう一つの典型が、要求が曖昧なまま書かれていることです。「安定して動かしてほしい」「何かあったらすぐ対応してほしい」といった願望レベルの言葉は、要件ではありません。これらをベンダーが見積もれる定量要件に翻訳することこそ、保守要件定義の核心です。曖昧な要求は、ベンダーごとに解釈が分かれ、安く見せたい会社は最小限に、手厚い会社は過剰に見積もるため、価格がまったく比較できなくなります。
SLAの数値要件をRFPに明記する
「すぐ対応してほしい」という願望は、SLAの数値要件に翻訳して初めて意味を持ちます。RFPには、求める稼働率（例：99.9%、月間で約43分の停止許容、または99.5%）、初報応答時間（重大障害15分・通常2時間）、エスカレーション時間（30分）、回答時間（24時間）、復旧時間（重大4時間・通常8時間）、恒久対応の期限（5営業日）といった数値を、自社の業務の重要度に応じて明記します（出典：ripla）。これらの数値があって初めて、ベンダーは必要な体制とコストを正確に見積もれます。
ここで重要なのは、SLAを「努力目標」とするのか「保証」とするのかを明示することです。努力目標型は未達でもペナルティがなく、保証型は未達時に減額などのペナルティが発生します。RFPで保証型を求める場合は、未達時の減額相場（月額の何%か）と、その判定方法までを要件として書くべきです。SLAペナルティは、原因が有耶無耶にされて適用されないケースもあるため、「何をもって未達と判定するか」を曖昧にしないことが実効性を生みます。数値だけでなく、その数値が守られなかったときの扱いまで定義してこそ、要件定義は完成します。
処理速度など非機能要件の数値化
保守要件では、稼働率だけでなく性能（処理速度）の非機能要件も数値化しておくと、品質の劣化を防げます。たとえばRFPの例では、全画面の表示を3秒以内にするといった処理速度の要件が示されることがあります（出典：ripla）。保守の過程でデータ量が増えたり改修が重なったりすると、徐々に性能が劣化することがあるため、維持すべき性能水準を数値で定義しておくことが重要です。
非機能要件には、性能のほかにセキュリティ（脆弱性対応の期限）、可用性（稼働率）、運用性（監視・バックアップの方式）などが含まれます。これらを「当たり前に守られるもの」と思い込まず、RFPに明文化しておくことで、保守ベンダーは何を維持すべきかを正確に把握できます。曖昧な要求を定量要件へ翻訳するこの作業は手間がかかりますが、ここを丁寧にやるほど、契約後の「言った言わない」のトラブルが減り、複数社の見積もりを公平に比較できるようになります。
価格配点を抑えた評価軸の設計と提案依頼
RFPの最後の肝が、提案を評価する軸の設計です。保守管理は長く付き合う領域だからこそ、目先の安さだけで選ぶと、品質や継続性で痛い目を見ます。だからこそ、評価軸において価格の配点を意図的に抑え、体制・実績・SLA達成への姿勢といった質的な項目を重視する設計が推奨されます。価格を満点基準にすると、待機要員を削った薄い体制の安値提案が有利になり、いざというときに対応してもらえないリスクが高まるためです。
価格・体制・実績のバランスを取る配点
評価軸の配点は、価格を抑えめにし、保守体制・障害対応力・技術理解・ドキュメント整備力・継続性といった質的項目に重みを置くのが実務的です。保守費は開発費の15〜20%が目安とされますが（出典：ripla）、この相場から大きく外れて安い提案は、何かを削っている可能性を疑うべきです。逆に高すぎる場合は、多重下請けや過剰な待機要員コストが上乗せされていないかを内訳で確認します。価格は「安さ」ではなく「相場との整合性と内訳の妥当性」で評価するのが賢明です。
RFPでは、評価項目と配点をあらかじめ提示しておくと、ベンダーがどこに注力すべきかを理解し、的を射た提案を出してくれます。価格配点を抑えることを事前に伝えれば、各社は無理な値下げ競争ではなく、体制や品質で差別化しようとします。これは結果的に、発注側にとって質の高い保守を引き出すことにつながります。評価軸の設計は、単なる採点表ではなく、ベンダーの提案の方向性をコントロールする戦略的なツールなのです。
引き継ぎ・移管しやすさをRFPで問う
保守RFPでは、将来の引き継ぎや移管のしやすさを評価項目に入れておくことも重要です。具体的には、運用ドキュメントの整備方針、ソースコードや構成情報の取り扱い、契約終了時の引き継ぎ協力の範囲を、提案依頼として問います。ドキュメント不足は移管が難航する最大の原因であり、入口の契約時点で出口（移管）のしやすさを担保しておくことが、将来のベンダーロックインを防ぎます。
あわせて、ソースコードの著作権や独自パッケージの取り扱いも、RFPで確認しておくべき論点です。これらが曖昧なまま契約すると、後にベンダーを変えたいときに「著作権はこちらにある」と移管を拒まれる泥沼に陥る恐れがあります。riplaはフルスクラッチ受託と国内運用保守の立場から、要件定義の段階でこうした出口の条件まで含めて整理し、発注側が将来も選択肢を持ち続けられる契約づくりを重視しています。良いRFPとは、今の保守だけでなく、将来の乗り換えやすさまで見据えた文書なのです。
移行受け入れと報告体制の要件を定める
保守RFPでは、保守が始まる「入口」の移行受け入れ要件と、保守が続く「日常」の報告体制要件も、忘れずに定義しておくべきです。前者は現行ベンダーからの引き継ぎを円滑にするための要件、後者は契約後に品質を継続的に把握するための要件であり、どちらも抜けると、契約後の運用が混乱します。要件定義で見落とされやすいのが、まさにこの引き継ぎと日常運用の取り決めです。機能や障害対応の要件は詳しく書いても、移行と報告の段取りは「やってくれるだろう」と曖昧にされがちで、ここが後の不満の温床になります。
現行調査と移行受け入れ期間の要件化
新たに保守を委託する場合、新ベンダーは現行システムの構成や業務ロジックを理解する立ち上げ期間を必要とします。RFPでは、この現行調査と移行受け入れの期間をどう設けるか、その間の費用と品質をどう扱うかを要件として明記しておくべきです。移行リスクとして二重コスト・ドキュメント不足・引き継ぎ難航は避けられないため、立ち上げ期間中に新旧ベンダーがどう協力するかを取り決めておくことが、スムーズな移管の前提になります。この立ち上げを軽視すると、保守開始直後の障害で新ベンダーが立ち往生し、初期から信頼を損なうことになりかねません。
具体的には、現行ベンダーからどのドキュメント（構成情報、障害対応手順、運用手順書）を引き継ぐか、新ベンダーが現行調査にどれだけの工数を見込むか、移行期間中のSLAをどう緩和するかといった点を要件化します。この立ち上げ期間を曖昧にすると、引き継ぎが終わらないまま本番運用が始まり、初期の障害対応が後手に回ります。入口の移行受け入れをきちんと要件として設計しておくことが、契約後の混乱を防ぎ、保守の品質を早期に安定させます。
月次報告・定例会の運用要件を明記する
保守が始まった後の品質を継続的に把握するには、報告体制の要件をRFPに書き込んでおくことが欠かせません。具体的には、月次でどんな内容のレポートを提出するか、SLAの実績値（稼働率、応答時間、復旧時間）を報告に含めるか、定例会をどの頻度で開くかを要件化します。保守費内訳で管理報告が5〜10%を占めるとされるように（出典：ripla）、報告にはコストがかかるからこそ、何をどこまで報告させるかを発注側が定義しておくべきです。報告の様式や項目を発注側があらかじめ指定しておけば、ベンダーごとにばらつくこともなく、比較や蓄積がしやすくなります。
報告要件で大切なのは、レポートを「形だけの報告書」にしないことです。実績値とSLA目標を並べて示させ、未達があった場合は原因と再発防止策まで報告させる、という運用を要件に盛り込むことで、月次報告が改善のPDCAを回す材料になります。定例会も、単なる進捗確認ではなく、傾向の共有と次の打ち手を議論する場として位置づけると、保守の質が継続的に高まります。riplaはフルスクラッチ受託と国内運用保守の立場から、報告を品質改善の起点にする運用設計を重視しており、要件定義の段階でこうした日常運用の取り決めまで一緒に整理することを推奨しています。
契約終了時の引き継ぎ義務を要件に含める
入口の移行受け入れと同じくらい重要なのが、契約終了時、つまり出口の引き継ぎ義務を要件として書いておくことです。保守を委託するときは契約を結ぶことばかりに目が向きがちですが、いざ別ベンダーへ乗り換えたいときに「引き継ぎには応じない」と言われると、移管が泥沼化します。RFPの段階で、契約終了時にどのドキュメントを提供するか、どこまで引き継ぎに協力するか、その費用負担はどちらかを要件として明記しておくべきです。
あわせて、運用中に蓄積されるドキュメント（障害履歴、構成変更の記録、手順書）を、契約期間中も発注側がいつでも参照・保有できるようにする要件を入れておくと、出口の自由度が一段と高まります。ドキュメント不足は移管が難航する最大の原因であるため、出口の条件を入口で要件化しておくことが、将来のベンダーロックインを構造的に防ぎます。良いRFPとは、今の保守の品質だけでなく、契約を終えるときの円滑さまで見据えて、入口と出口の両方を要件に織り込んだ文書なのです。
こうした出口の要件は、ソースコードの著作権や独自パッケージの取り扱いと一体で整理しておくと、より実効性が高まります。著作権の帰属が曖昧なまま契約すると、引き継ぎ義務を要件に書いていても、権利を盾に移管を拒まれる余地が残るためです。要件定義の段階で、ドキュメント・権利・引き継ぎ協力の三点をセットで取り決めておくことが、発注側が将来も選択肢を持ち続けるための、もっとも確実な備えになります。
まとめ
ITシステム保守管理のRFP・要件定義を整理すると、その骨格は「クラウド責任共有を前提に責任分界点を明記し、曖昧な要求をSLAや処理速度の数値要件へ翻訳し、価格配点を抑えた評価軸で体制と継続性を重視する」という三本柱に集約されます。SLAの数値（稼働率99.9%、初報15分、復旧4時間など）や保守費の相場（開発費の15〜20%）を具体的に書き込むことで、ベンダーは正確に見積もれ、発注側は各社を公平に比較できます。責任分界・契約形態・移管しやすさといった、競合提案で抜けやすい論点まで網羅することが、良いRFPの条件です。
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を創業。