運用保守のRFPや要件定義書では、動き続ける状態をどう保証してもらうかを書きます。責任分界を明記し、曖昧な要求を数値要件に直し、価格の配点を抑えた評価軸を設けると、各社の提案を比べられるようになります。
全体像から確認したい方は、SE/SIerの運用保守の完全ガイドを先にお読みください。
▼全体ガイドの記事
・SE/SIerの運用保守の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
クラウド責任共有を前提にした責任分界の記述
現代の運用保守RFPで最も重要で、かつ抜けやすいのが、責任分界点の記述です。SaaS・クラウド・AI連携が当たり前になった今、障害の原因がベンダーのコントロール外にあるケースが急増しています。
クラウド事業者側の障害、連携SaaSのAPI仕様変更、AIのハルシネーションといった事象が起きたとき、誰がどこまで責任を負うのかを決めておく必要があります。
費用を誰が持つのかをRFPの段階で定めておかないと、障害が起きてから泥沼の押し付け合いになります。
ベンダーのコントロール外障害のRFPでの定義
クラウドのリージョン障害でシステムが停止したとき、保守ベンダーに復旧の義務はなくても、状況把握と顧客への報告、復旧後の動作確認は担ってほしいはずです。
RFPには、障害時に保守ベンダーがどこまで受け持つかと、その費用を誰が持つかを書いておきます。「直せない障害でも、何をしてくれるのか」を要件として書くと、提案各社の運用設計の差が見えてきます。
責任分界の記述では、稼働率SLAの「対象範囲」を明確にすることも欠かせません。稼働率99.9%（月の停止許容約43分）を要求する場合でも（出典：ripla）、それが自社開発部分だけを対象にするのかを決めておく必要があります。
特に、クラウド基盤の障害を含めるかどうかで、ベンダーが負うリスクは大きく変わります。基盤の障害込みで99.9%を保証させると、ベンダーは責任を取れず、高い見積もりを出すか辞退してしまいます。
責任の境界線を現実的に引くことが、適正な提案を引き出す鍵です。
RFPに盛り込む主な項目は、障害時の責任範囲と、連携先の仕様変更への対応です。
- 障害時の責任範囲：一次切り分け、状況報告、復旧支援のうち、保守ベンダーが受け持つ範囲
- 連携先の仕様変更：追従改修を月額に含めるか、別見積もりにするかの扱い
準委任か請負かの契約形態のRFPでの指定
運用保守の契約形態は、業務の性質に応じて準委任と請負を使い分けます。定常的な運用は、成果物ではなく稼働を提供する準委任が一般的です。
一方、特定の軽微改修や仕様変更のように明確な成果物を伴う作業は、請負やSESで対応するのが通例です。
契約形態を曖昧にしたまま発注すると、後で「これは準委任の範囲なので別途見積もりです」という争いが起きます。
法務の面でも、準委任と請負では瑕疵担保や成果責任の扱いが異なります。そのため、契約形態の指定は、トラブル時の責任を左右する要件定義事項として扱ってください。
RFPには、どの業務をどの契約形態で委託したいかを明示し、提案側に契約形態の前提を揃えてもらいます。そのうえで、提案の回答では、この2点を分けて示してもらいます。
- 定常運用：監視、障害対応、問い合わせ対応を、準委任で月額に含める範囲
- 改修と仕様変更：月額の範囲外として、都度請負で見積もる作業の範囲
曖昧な要求を数値要件に翻訳する書き方
運用保守のRFPで提案がバラつく最大の原因は、要求が曖昧なことです。「迅速に対応してほしい」「安定稼働させてほしい」という表現は、人によって解釈が分かれるため、各社が自社に都合のよい前提で見積もります。
比較可能な提案を引き出すには、こうした曖昧な要求を、誰が読んでも同じ意味になる数値要件に翻訳する必要があります。
SLAの数値化（応答・復旧・稼働率）
「迅速に対応」は、応答時間の数値に翻訳します。一次データの実務水準を参考にすると、初報応答は重大障害15分・通常障害2時間、エスカレーション30分、回答24時間、復旧目標は重大障害4時間・通常障害8時間です。
さらに、恒久対応は5営業日といった具体値で要件化できます（出典：ripla）。「安定稼働」は稼働率の数値に翻訳し、99.9%（月の停止許容約43分）または99.5%のいずれを求めるかをRFPに明記します（出典：ripla）。
発注側が数値を提示すると、提案側は「その水準を満たすために必要な体制と費用」を具体的に積み上げて見積もるため、比較可能性が一気に高まります。
障害の重要度区分（重大・通常・軽微など）を定め、区分ごとに応答・復旧時間を変えることも、現実的な方法です。すべての障害に15分応答を求めると、過剰な体制が必要になり費用が跳ね上がります。
業務への影響の大きさで区分し、重大障害だけに厳しいSLAを課せば、コストと品質のバランスが取れます。曖昧な要求の翻訳は、数字を入れる作業であると同時に、「どこに厳しさを集中させるか」を設計する作業でもあります。
SLAの回答では、この2点を数値で示してもらいます。
- 応答時間：初報応答とエスカレーションまでの時間を、重要度ごとに分けた数値
- 稼働率と復旧時間：稼働率の水準と、重大障害・通常障害それぞれの復旧目標の数値
処理速度などの性能要件のRFPでの数値化
運用保守のRFPでは、障害対応だけでなく、システムが満たすべき性能水準も数値で定義しておくと、保守の評価基準になります。実際のRFP例では、「全画面の表示を3秒以内」といった処理速度の要件が設定されることがあります（出典：ripla）。
性能要件があれば、保守の過程で性能が落ちたときに改善を求める根拠になります。一方、性能要件のないRFPでは、遅くなっても「もともとそういうものです」と言われて終わってしまいます。
数値化できる要件は、応答時間・稼働率・処理速度のほかにもあります。たとえば、バックアップの保持世代数や復元の所要時間も、数値で書けます。
RFPに数値要件のリストを設け、各社にその達成可否と前提を回答させると、提案の精度が揃います。曖昧さを残した項目は、後の追加費用やトラブルの火種になりがちです。
リストには、性能と運用の両方の数値を入れておきます。
- 性能要件：全画面の表示時間など、劣化を客観的に判定できる処理速度
- 運用要件：バックアップの取得頻度、監視の間隔、月次報告の提出期限
価格配点を抑えた評価軸の設計
RFPで集めた提案をどう評価するか、その評価軸の設計もまた要件定義の一部です。運用保守の提案を価格だけで選ぶと、安かろう悪かろうの体制を選ぶことになり、結局は障害多発や追加費用で高くつきます。
価格の配点は意図的に抑え、運用設計の質や体制、ドキュメント整備の方針を重く見る評価軸を、RFPの段階で示しておきます。そうすると、長期的に満足できる委託先を選びやすくなります。
費用内訳の提示の必須要件化
価格を一式で出させると、各社の前提が見えず比較できません。RFPでは、費用を機能別の内訳で提示するよう義務づけます。
定期保守・監視・障害対応・問い合わせ対応・軽微改修・管理報告という費目で分けて見積もらせると、費用の内訳を相場と照らして妥当性を判断できます。相場の内訳は、定期保守20〜30%、監視15〜25%、障害対応25〜35%、問い合わせ10〜20%、軽微改修10〜15%、管理報告5〜10%です（出典：ripla）。
年間保守費は開発費の15〜20%が目安であり（出典：ripla）、この相場から外れる提案は、その理由を問うべきです。
運用要員の人月単価は60万〜150万円が相場とされます（出典：ripla）。
極端に安い提案は、待機要員を持たず属人的に回す薄い体制か、多重下請けで責任が曖昧になっている可能性があります。内訳の提示を必須にすると、価格の安さの「中身」を評価できるようになります。
内訳では、体制と単価の対応、待機要員と下請けの扱いを確かめます。
- 単価と人月：提案の体制と単価から、何人月の金額かを逆算できる内訳
- 待機要員と下請け：待機要員の有無と、多重下請けの有無を示す回答
ロックイン回避のRFP要件への組み込み
将来のベンダー乗り換えを見据えるなら、RFPの段階でロックイン回避を要件化しておくべきです。
ドキュメントと権利の要件を後から契約に追加しようとしても、ベンダー側に交渉力が移っており、独自パッケージ派生やソースコード著作権を盾に移管を拒まれる「法的ロックイン」に陥りがちです。
評価軸としては、「契約終了時にスムーズに別ベンダーへ移管できる状態を、平時からどう維持するか」という設問を設け、その回答の具体性を評価します。
ドキュメントを継続的に整備し、属人化を避ける運用を提案できるベンダーは、ロックインのリスクが低く、長期的に健全な関係を築けます。
RFPは目先の委託先を決める書類であると同時に、数年後に困らないための保険でもあります。その視点で評価軸を設計します。
契約後に加えにくい項目は、最初の契約で定めておきます。
- ドキュメントの納品：運用手順書、障害対応履歴、構成情報を成果物として定期的に納める義務
- 権利と引き継ぎ：ソースコードの著作権の帰属と、契約終了時の引き継ぎ協力義務
移管・引き継ぎとドキュメント納品の要件定義
運用保守のRFPで見落とされがちなのが、「契約が始まるとき」と「契約が終わるとき」の引き継ぎに関する要件です。
入口は、新規にベンダーを切り替える場合の移管受け入れです。出口は、将来このベンダーから別のベンダーへ移る場合の引き渡しです。この入口と出口の要件を定義しておかないと、移管時の混乱や、ドキュメント不足による実質的なロックインを招きます。
RFPは目先の運用だけでなく、契約のライフサイクル全体を見据えて書くべきものです。
移管受け入れ期間と二重コストのRFPでの明示
既存システムの保守を新しいベンダーに切り替える場合、RFPには「移管受け入れ（引き継ぎ）」の要件を書きます。
保守移管は通常2〜3か月を要し、その間は旧ベンダーへの保守費と新ベンダーへの学習・調査費が並行して発生する二重コストが避けられません。
移管期間をRFPで明示しておくと、移管の巧拙を提案段階で評価できます。
移管期間中に新ベンダーが何を理解し、どのドキュメントを引き継ぐのかを、受け入れ要件として具体的に並べておきます。
移管では、旧ベンダーの協力をどう取り付けるかも論点になります。新ベンダー側のRFPだけでは旧ベンダーは動かないため、現行契約に引き継ぎ協力義務がないと、移管そのものが難航します。
年間保守費は開発費の15〜20%が相場とされます（出典：ripla）。
移管初年度はこの相場に二重コストが上乗せされることを前提に、複数年のTCOで評価する設計をRFPに織り込んでおくべきです。
移管の回答では、期間の見込みと、旧環境の情報の扱いを確かめます。
- 移管期間と体制：受け入れにかける期間と、移管計画および移管費用の別建て提示
- 旧環境の情報：提供される前提と、情報が不足した場合の調査工数の扱い
ドキュメント納品の頻度と粒度の要件化
将来の出口を確保するうえで決定的なのが、ドキュメント納品の要件です。
RFPには、ドキュメントをどの粒度で、どの形式で納品するかを明記します。納品物の一覧に具体的な文書名と更新頻度を入れて要件化すると、ブラックボックス化を防ぐ手段になります。
「ドキュメントは整備します」という曖昧な約束では、いざ移管しようとしたときに「最新化されていない」「担当者の頭の中にしかない」という事態に陥ります。
契約終了時には、運用ノウハウも含めて別ベンダーへ引き継ぐ協力を、提供義務としてRFPに書き込んでおきます。
契約終了後の第三者開示の権利も、要件として明示します。
後から契約に加えようとすると、ベンダー側に交渉力が移り、独自パッケージ派生やソースコード著作権を盾に拒まれる「法的ロックイン」に陥りがちです。出口の要件を入口のRFPで握ることが、数年後の自由を守る最大の防衛策になります。
ドキュメントの納品では、頻度と粒度、そして権利の扱いを決めます。
- 納品物の一覧：運用手順書、構成情報、障害対応履歴、改修の経緯ごとの更新頻度
- 権利と引き渡し：契約終了時の一式の引き渡しと、著作権の帰属、利用・改変の範囲
運用体制・連絡体制とセキュリティの要件定義
SLAや費用の数値要件を固めても、それを実行する「体制」と「連絡の仕組み」、そして「セキュリティ」の要件が抜けていると、いざというときに機能しません。
誰が、いつ、どう動くのかをRFPで定義しておかないと、障害時に「担当者が捕まらない」「夜間は対応しない」といった想定外に直面します。
比較可能な提案を引き出すには、運用体制・連絡体制・セキュリティも、SLAと同じ精度で要件化しておく必要があります。
対応時間帯・エスカレーション経路のRFPでの定義
運用体制の要件では、まず「いつ対応するか」を定義します。平日日中のみか、夜間・休日も含む24時間365日か、対応時間帯によって必要な体制と費用は変わります。
すべてを24時間対応にすると過剰な費用になります。そのため、重大障害だけ夜間も対応し、軽微なものは翌営業日とするといったメリハリを、RFPで指定します。
運用要員の人月単価は60万〜150万円が相場とされます（出典：ripla）。対応時間帯の広さは見積もりに直結するため、自社に本当に必要な範囲を見極めて要件化することが、費用の妥当性を保つ鍵です。
連絡体制では、エスカレーション経路を要件として明示します。障害発生時に誰が一次受けし、どの基準で誰へつなぎ、最終的にどこまで上げるのか。この経路が曖昧だと、初報応答15分・エスカレーション30分といったSLAを掲げても（出典：ripla）、実際には連絡が滞ります。
窓口の一本化、緊急連絡先、報告のフォーマットと頻度を要件に含め、提案側に体制図とともに回答させると、各社の運用設計の実力が見えてきます。体制は「人数」だけでなく「動き方」まで要件化しておきます。
連絡体制の回答では、窓口と報告の決め方を確かめます。
- 窓口と緊急連絡先：窓口の一本化と、緊急時の連絡先の明記
- 報告の形式：報告のフォーマットと頻度、体制図を添えた回答
セキュリティ・コンプライアンスの要件の明記
運用保守のRFPでは、セキュリティとコンプライアンスの要件も欠かせません。脆弱性情報への対応も、要件として定義します。
OSSのサポート終了（EOL）への対応をどこまで保守でカバーするかも、ここで明確にしておくべき論点です。
保守の対応範囲が曖昧なまま契約すると、いざ脆弱性が見つかったときに「対応は範囲外」とされ、想定外の追加費用や、最悪の場合はセキュリティインシデントを招きます。
取り扱うデータの性質によっては、個人情報保護や業界固有の規制への準拠も要件になります。
クラウド環境では、セキュリティの責任がクラウド事業者とユーザー企業・SE・SIerの間で分担される「責任共有モデル」が前提になります。そのため、どの層のセキュリティを保守ベンダーが担うのかを、要件として切り分けておく必要があります。
セキュリティとコンプライアンスの要件は、平時には見えにくいものの、有事には事業の存続を左右するため、SLAと同等の重みでRFPに記述すべきです。
セキュリティの回答では、脆弱性への対応と、データの管理の仕方を確かめます。
- 脆弱性と監視：パッチの適用基準、不正アクセス監視の有無、インシデント時の報告義務
- データの管理：アクセス権限、操作ログの保全、保管場所や暗号化の方法
まとめ
SE・SIerの運用保守のRFP・要件定義書で比較可能な提案を引き出す鍵は、「責任分界をクラウド前提で明文化し、曖昧な要求を数値要件に翻訳し、価格配点を抑えた評価軸を設計する」という三点に集約されます。クラウド事業者障害やSaaSのAPI変更といったコントロール外の事象について責任範囲を定め、準委任か請負かの契約形態を指定します。
初報応答15分・復旧4時間・稼働率99.9%・全画面3秒といった数値で要求を翻訳すると、各社の提案が同じ土俵に乗ります（出典：ripla）。
RFPでは、作るものの仕様を書くよりも、「動き続ける状態をどう保証してもらうか」を言語化することが大切です。
費用内訳の提示を必須にし、移管受け入れとドキュメント納品の要件を入口で握ってロックイン回避を組み込めば、目先の安さに惑わされず、数年先まで健全に付き合える委託先を選べます。
riplaは、フルスクラッチ受託と国内運用保守の立場から、責任分界と数値SLAを織り込んだ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を創業。