ITシステムの保守運営を外部に委託する際、発注の成否を分けるのがRFP（提案依頼書）と要件定義の精度です。開発のRFPは比較的書きやすい一方、保守運営のRFPは「何をどこまで保証してほしいのか」を数値で表現するのが難しく、曖昧なまま発注した結果、いざ障害が起きてから「それは契約範囲外です」と言われる、というトラブルが後を絶ちません。保守は形のないサービスだからこそ、要件を数値と条件で固めることが重要になります。
本記事は、ITシステム保守運営のRFP・要件定義書・提案依頼書をどう作るかを、発注側の視点で具体的に解説します。クラウドの責任共有を前提とした記載、曖昧な要求を測定可能な要件へ翻訳する方法、価格配点を抑えた評価軸の設計、稼働率や処理速度といった数値要件の書き方まで、SLA実値や費用相場といった一次データとあわせて掘り下げます。なお、ITシステム保守運営の全体像をまだ把握していない方は、まずITシステム保守運営の完全ガイドから読むことをおすすめします。
▼全体ガイドの記事
・ITシステム保守運営の完全ガイド
クラウド責任共有を前提にした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はフルスクラッチ受託と国内運用保守を組み合わせ、曖昧な要求の翻訳から出口を塞がない要件設計まで一貫して支援します。全体像の確認には、あらためて完全ガイドをご活用ください。
株式会社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を創業。