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