ITシステム保守運営のRFP（提案依頼書）と要件定義書では、責任の範囲と数値の条件をどこまで書けるかが、発注の成否を分けます。
発注側が要件で決めるべきは、責任の範囲、数値の条件、契約形態、評価の配点、引き継ぎと報告です。全体像はITシステム保守運営の完全ガイドで先に確認できます。
▼全体ガイドの記事
・ITシステム保守運営の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
クラウド責任共有を前提にしたRFPの書き方
現代の保守運営RFPで最初に押さえるべきは、クラウドの責任共有モデルを前提とした記載です。AWSやAzureといったクラウド基盤の上でシステムを動かす以上、障害の原因がクラウド事業者側にあるのか、その上のアプリケーション側にあるのかで、保守ベンダーが負える責任は変わります。
この責任分界点をRFPで曖昧にしておくと、障害時に「クラウド側の問題なので当社の責任外」と切り返され、誰も対応しない空白地帯が生まれます。
クラウド障害・SaaS連携・AIの責任分界の明記
RFPには、クラウド基盤の障害時にベンダーが行う対応（一次切り分け・連絡・代替手段の提示など）を具体的に書き込みます。
クラウド側の復旧自体はベンダーにはできなくても、状況を切り分けて報告し、復旧後の正常性確認まで担ってもらうことはできます。
だからこそ、この「コントロール外の障害でも、何を・どこまでやるか」を要件化することが、現代の保守RFPの肝です。
同様に、連携している外部SaaSのAPI仕様変更や、AI機能のハルシネーション（誤った出力）といった、ベンダーのコントロール外の事象についても、対応範囲を明記します。
たとえば「連携先SaaSのAPI仕様変更が通知された場合、影響調査と改修見積もりを何営業日以内に提示する」といった形で書きます。
これらをRFP段階で要件化しておけば、後から「想定外だった」として追加費用や対応拒否が生じるのを防げます。曖昧さは保守トラブルの温床であり、責任分界を明記することが、それを未然に断ちます。
コントロール外の障害でも、ベンダーに担ってもらえる対応の中心は、切り分けと報告、そして復旧後の確認です。
- 切り分けと報告：原因がクラウド基盤側かアプリ側かを見極め、関係者へ伝える
- 復旧後の確認：クラウド側の復旧はベンダーの役割でなくても、正常性の確認は対応範囲に含める
責任分界を書くときのコツは、障害のシナリオを具体的に想定し、それぞれで誰が・何を・どこまでやるのかを一覧にすることです。
たとえば、クラウド基盤の広域障害や連携SaaSのAPI停止、AI機能の誤出力などの典型シナリオに、自社アプリのバグも加えて想定します。
ベンダーの対応範囲と費用区分をシナリオごとに表で整理しておくと、提案者も自社も認識を揃えられます。
競合の保守解説の多くは、このコントロール外の障害に踏み込んでいません。ここをRFPで具体化することが、現代の保守要件でもっとも差がつくポイントです。
抽象的に「責任分界を明確にする」と書いても、要件としては不十分です。シナリオベースで落とし込むことが、要件化の質を決めます。
準委任・請負の契約形態の指定
保守運営のRFPでは、契約形態の指定も欠かせない要件です。日常的な監視や問い合わせ対応といった定常運用は、成果物ではなく業務の遂行を約束する準委任契約が一般的です。
一方、特定の改修を完成させて納品する作業は、成果物の完成を約束する請負契約が適します。この区別を曖昧にすると、後の認識にずれが生じます。
RFPでは、業務の性質ごとに想定する契約形態を分けて示しておくと、提案を比較しやすくなります。たとえば、定常運用は準委任、個別改修は都度の請負またはSES（システムエンジニアリングサービス）といった組み合わせです。
あわせて、契約終了時のドキュメント引き継ぎ義務や、ソースコードの権利関係も要件として明記すべきです。
ここを詰めておかないと、将来ベンダーを変更したいときに「ソースコードの著作権を盾に移管を拒否される」という法的ロックインに陥りかねません。
契約形態と権利関係は、保守の入口で固めておく要件です。
契約の種類で、おもに次の点に差が出ます。
- 責任の所在：業務を遂行する義務か、成果物を完成させる義務か
- 瑕疵対応：不具合が見つかったときに、どこまでを誰が負うか
契約形態を指定するのは、準委任と請負で責任の性質がまったく異なるためです。準委任は業務を誠実に遂行する義務（善管注意義務）を負うもので、成果物の完成までは保証しません。
請負は成果物の完成を約束し、不具合があれば契約不適合責任を負います。日常の監視や問い合わせ対応のような終わりのない業務に請負を当てはめると無理が生じ、特定の改修のような完成すべき成果物に準委任を使うと、品質責任が曖昧になります。
業務の性質に合った契約形態をRFPで指定しておくことが、後の責任論争を避ける土台になります。
「保守一式」のように丸めた契約は、トラブルの火種になります。
曖昧な要求の測定可能な要件への翻訳
保守RFPでもっとも多い失敗が、「安定して動かしてほしい」「障害には迅速に対応してほしい」といった曖昧な要求を、そのまま要件にしてしまうことです。
これらは聞こえは良いものの、測定できないため契約上の約束になりません。要件定義の本質は、こうした曖昧な期待を、数値と条件で測定可能なものに翻訳することにあります。
稼働率・応答時間・復旧時間の数値定義
「迅速に対応」を翻訳すると、初報応答は重大障害で15分以内・通常障害で2時間以内、エスカレーションは30分以内になります。また、復旧は重大障害で4時間以内・通常障害で8時間以内です。
恒久対応については、5営業日以内といった数値になります（出典：ripla）。
「安定して」を翻訳すれば、稼働率99.9%（月間ダウンタイム約43分以内）や99.5%といった指標になります（出典：ripla）。
RFPには、これらの目標値を障害の重大度別に記載し、提案者が約束できる水準を回答させます。
処理速度のような性能要件も、忘れずに含めます。RFPの例では、「全画面の表示を3秒以内」といった応答性能を要件化するケースがあります（出典：ripla）。
性能はユーザー体験に直結するため、保守の中で「劣化していないか」を継続監視する対象になります。数値要件を書くときのコツは、達成可能で測定可能な水準にすることです。
理想を追って稼働率100%などと書けば、コストが跳ね上がるか、提案者が誰も応じられなくなります。現実的な数値に翻訳することが、要件定義の腕の見せどころです。
数値目標で測る時間は、おもに次の指標になります。
- 初報応答：障害を受けて、最初の連絡を返すまでの時間
- エスカレーション：担当者から上位の担当者へ引き上げるまでの時間
数値要件を翻訳する際は、自社にとっての「重大」「通常」「軽微」の定義もあわせて言語化しておく必要があります。
同じ「障害」でも、たとえば受注が止まる障害と、社内用の管理画面が一部使えない障害では、求める対応速度が違います。
RFPに「業務への影響度で重大度を分類し、それぞれにこの数値目標を適用する」と書いておけば、提案者は重大度判定の運用まで含めて見積もれます。
逆に重大度の定義が曖昧だと、いざ障害が起きたときに「これは重大か通常か」で揉め、対応が遅れます。数値だけでなく、その数値を適用する条件まで翻訳することが、実効性のある要件につながります。
SLA未達時のペナルティと判定方法の要件化
数値目標は、未達時のペナルティまで要件化して初めて、SLAとして機能します。
RFPには、「稼働率が目標を下回った月は、保守費の何%を減額する」といった減額のルールと、その判定方法を盛り込みます。減額相場は月額の数%から十数%程度が一つの目安です。
とくに重要なのが「未達の判定方法」です。実務では、障害の原因がクラウド側か自社側かがうやむやになり、ペナルティが適用されないケースがあります。
ペナルティは「設定すること」より「適用されること」が肝心であり、判定の客観性を要件に含めることが、形だけの条項にしないための鍵です。
判定方法を決めないままでは、ペナルティは実効性のある要件にはなりません。これを防ぐには、判定の前提をRFP段階で明確に定義しておく必要があります。
- 計測の基準：どの監視ツールの数値を正とするか
- 除外の条件：計画停止や、クラウド事業者起因の扱い
ペナルティ要件を書くときは、減額の上限と発動条件も併記しておくと現実的です。減額幅が大きすぎると、ベンダーがリスクを織り込んで保守費を引き上げ、結局は発注側が割高な費用を払うことになります。
逆に小さすぎれば抑止力になりません。月額の数%という相場を踏まえつつ、自社にとってダウンタイムが致命的かどうかで水準を決めます。
ペナルティは、罰として運用するより、未達が続いた場合に体制の見直しを協議する「改善トリガー」として位置づけるほうが、長期的な関係では機能しやすいものです。
要件定義では、減額の数字だけでなく、その運用思想まで設計しておくと、保守関係が対立的にならずに済みます。
価格配点を抑えた評価軸の設計
RFPの締めくくりは、提案をどう評価するかという評価軸の設計です。ここで価格の配点を大きくしすぎると、安かろう悪かろうの提案を選んでしまいます。結果として障害対応の品質が低くなり、かえって高くつくことになります。
保守運営は長期にわたる伴走であり、目先の価格だけで選ぶべき領域ではありません。
体制・実績・対応品質への配点
価格配点を抑える代わりに、配点を寄せるべきは「体制」「実績」「対応品質」です。
これらは長期の安定運用に直結する要素であり、価格よりも重視されるべきです。
費用の妥当性を判断する際は、保守費の相場観を持っておくと役立ちます。年間保守費は開発費の15〜20%が目安で、規模別の月額は、小規模で5〜15万円、中規模で15〜50万円、大規模で50〜200万円以上です。
また、人月単価は運用要員で60万〜150万円が一般的です（出典：ripla）。極端に安い提案には注意が必要で、待機要員を十分に確保していないか、対応範囲が狭い可能性があります。
評価軸では、価格を「相場から外れていないか」のチェックに使い、優劣は品質・体制で決める設計が望ましいです。
安さに飛びついた結果、いざ障害時に動ける人がいなかった、というのは保守でもっとも避けたい失敗です。そこで、評価項目は次の観点で組み立てます。
- 体制と実績：障害時に動ける要員の人数とスキル、類似システムの運用実績
- 対応品質：初報や復旧の対応プロセスの具体性、ドキュメント整備の方針
移管容易性と出口戦略の評価項目への組み込み
見落とされがちですが、評価軸には「将来、別ベンダーへ移管しやすいか」という出口戦略も含めるべきです。契約時は良好でも、数年後に乗り換えたくなる可能性は常にあります。
そのとき、ドキュメントが整備され、ソースコードの権利が自社にあり、独自パッケージへの過度な依存がないことが、スムーズな移管を可能にします。
移管のしやすさは、契約直後には価値が見えにくいものの、数年後にベンダーとの関係が悪化したときに、自社の交渉力を決定づける要素になります。
RFPの要件と評価項目に移管の観点を入れておくと、法的ロックインのリスクを入口で下げられます。
riplaはフルスクラッチ受託と国内運用保守の立場から、こうした出口を塞がない要件設計と、作った後も自社で判断できる状態を保つ伴走を重視しています。
要件定義では、いま欲しい保守を書くことに加えて、「将来の自由度を確保する」視点で組み立てることが、長期的な保守コストを抑えることにつながります。
移管の観点として、おもに次の内容があります。
- ドキュメントとソースコード：納品の範囲と、著作権の帰属
- 独自パッケージ：採用したときの影響
引き継ぎ・移管と報告体制の要件化
RFP・要件定義の締めくくりとして欠かせないのが、契約開始時の「引き継ぎ要件」と、契約終了時の「移管要件」、そして運用中の「報告体制の要件」です。
これらは目先の保守サービスそのものではないため後回しにされがちです。ただ、ここを曖昧にすると、立ち上げの混乱や終了時のトラブル、運用中の不透明さを招きます。
入口・運用・出口の三局面で、要件として明文化しておくことが大切です。この三局面を押さえると、保守はサービス内容だけでなく、関係そのものも設計された状態になります。
立ち上げ時の引き継ぎ期間と並行運用の要件化
新たに保守ベンダーへ運用を引き継ぐ際、いきなり全面的に切り替えると、新ベンダーがシステムを理解しきれないまま障害に直面し、初動が遅れるリスクがあります。
RFPには、引き継ぎ期間をどれだけ確保するか、その間に旧体制と並行運用するか、初回の本番障害を一緒に対応してもらうかといった、立ち上げの段取りを要件として書き込みます。
新ベンダーは本番障害を一度経験して初めて知見が定着するため、この並行期間の設計が安定稼働への近道になります。
あわせて、引き継ぎ時に旧ベンダーや自社から新ベンダーへ渡すべき情報を、要件として列挙しておきます。
渡す情報が揃っていないと、新ベンダーは調査から始めることになり、立ち上げが長引きます。引き継ぎ要件を明確にすることは、立ち上げ時の二重コストや空白期間を抑える手立てでもあります。
引き継ぎは、渡す情報と期間を契約で決めてこそ円滑に進みます。
渡す情報には、次のような内容があります。
- 設計と運用の資料：システム構成図、運用手順書、障害対応履歴
- 設定と権限：監視設定、アカウント情報
レポート項目と定例会の頻度の要件への記載
運用が始まってからの透明性を確保するのが、報告体制の要件です。RFPには、月次レポートにどの指標を含めるか、定例会をどの頻度で開くかを書き込みます。
レポートには、稼働率やSLAの達成状況、障害件数と内容を含めるのが定石です。さらに、問い合わせ件数や実施した定期保守、再発防止のための恒久対応も、報告項目に加えます。
管理・報告は保守費の5〜10%を占める正規の業務であり（出典：ripla）、要件として明示すれば形骸化を防げます。
報告体制を要件化する狙いは、保守をブラックボックスにしないことにあります。レポートと定例会で運用の実態が見えれば、発注側は保守費の妥当性を判断でき、経営層への説明責任も果たせます。
定例会で今後のリスクや改善提案を議論する場を設ければ、保守は「言われたことをやる作業」から「システムを継続的に良くする伴走」へと変わります。
RFPの段階で「どんな報告を、どの頻度で求めるか」を要件として書いておくことが、長期にわたる良好な保守関係の土台になります。報告は運用の品質を映す鏡であり、要件化する価値の高い項目です。
報告の仕組みは、月次レポートと定例会の役割を分けて組み立てます。
- 月次レポート：運用の実態を、毎月の報告として受け取る
- 定例会：今後のリスクや改善提案を話し合う場
まとめ
ITシステム保守運営のRFPと要件定義を成功させる鍵は、(1)クラウド責任共有を前提に、責任分界点と契約形態を明記することです。
続けて、(2)曖昧な要求を稼働率99.9%・初報15分・復旧4時間といった測定可能な数値とペナルティに翻訳し、(3)価格配点を抑えて体制・実績・対応品質と移管容易性に配点を寄せます。
さらに、(4)立ち上げの引き継ぎ、終了時の移管、運用中の報告体制まで要件化する。この一連の流れに集約されます（出典：ripla）。
保守は形のないサービスだからこそ、数値・条件・出口戦略を要件で固めることが、後のトラブルと想定外費用を防ぎます。
要件定義の本質は、いま欲しい保守を書き出すことに加えて、コントロール外の障害や将来の移管まで見据え、自社の自由度を守ることにあります。
とくに、引き継ぎ・移管・報告という保守サービスそのものではない局面まで要件化しておくと、立ち上げから終了まで一貫した安心が得られます。
まずは現行システムの責任分界点と数値目標を整理し、相場観を持ったうえで評価軸を設計してください。
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を創業。