システム運用保守を外部に委託する際、最初の関門になるのが「RFP（提案依頼書）や要件定義書に、何をどこまで書けばよいのか」という問題です。開発のRFPと違い、運用保守のRFPは目に見える成果物が少なく、稼働率や応答時間といった抽象的なサービス品質を言葉で定義しなければなりません。ここが曖昧なまま発注すると、ベンダーごとに前提がバラバラの見積もりが集まり、比較もできなければ、契約後に「それは保守範囲外です」というトラブルにも発展します。
本記事は、システム運用保守のRFP・要件定義書・提案依頼書を、発注企業が自力で書けるようになることを目指す「要件定義特化」の解説です。とくにクラウドやSaaS連携を前提とした責任共有の明文化、曖昧な要求を測定可能な要件へ翻訳する方法、価格偏重を避ける評価軸の設計、SLAや処理速度の数値要件の書き方を、一次データの相場とあわせて具体的に解説します。読み終えるころには、ベンダーを公平に比較できるRFPの骨格が描けるはずです。なお、システム運用保守の全体像をまだ把握していない方は、まずシステム運用保守の完全ガイドから読むことをおすすめします。
▼全体ガイドの記事
・システム運用保守の完全ガイド
クラウド責任共有を前提にしたRFPの書き方
現代の運用保守RFPで、もっとも見落とされやすく、かつ後で揉めるのが「責任分界点」です。多くのシステムはAWSなどのクラウド上で動き、外部SaaSとAPI連携しています。クラウドの障害、連携先SaaSの仕様変更、AIのハルシネーションといった「ベンダーのコントロール外」で起きる事象を、誰がどう扱うかをRFPで明記しておかないと、障害時に責任のなすり合いが起こります。
クラウド障害・SaaS仕様変更の責任分界を明記する
RFPには、想定される「ベンダーのコントロール外」の事象を列挙し、それぞれについて誰が一次対応し、誰がコストを負担するかを書きます。たとえば「クラウド基盤側の大規模障害が起きた場合、ベンダーは状況把握と当社への報告を行うが、復旧そのものはクラウド事業者の責任とする」「連携SaaSのAPI仕様変更への追従改修は、月額保守費と別の有償対応とする」といった具合です。こうした境界線を先に引いておくと、見積もりの前提が揃い、ベンダー比較が公平になります。
とくにAIを組み込んだシステムでは、AIが誤った出力をする「ハルシネーション」をどう扱うかが新しい論点です。AIの出力品質をどこまでベンダーの責任とするか、人間による確認をどの工程に挟むかを要件として書いておかないと、「AIが間違えたのはベンダーの瑕疵か」という不毛な議論になります。モダンなIT環境の運用保守RFPでは、こうした新しい責任分界をあらかじめ言語化しておくことが、競合の優等生フレームの一歩先を行く要件設計になります。
準委任か請負かを要件として整理する
運用保守のRFPでは、契約形態の前提も整理しておく必要があります。日々の監視やヘルプデスクといった定常運用は、専門的な役務を継続提供する準委任契約が一般的です。一方、改修プロジェクトのように明確な成果物を納める作業は請負契約やSESが適しています（出典：ripla）。この二つを混在させたまま発注すると、責任の所在が曖昧になります。
RFPでは、委託業務を「定常運用（準委任）」と「都度の改修案件（請負等）」に分け、それぞれの契約形態を明示すると、後の契約交渉がスムーズになります。とくに準委任では成果の完成を保証しないため、「何をもって役務提供とみなすか」をSLAなどで具体化しておくことが重要です。契約形態を要件段階で意識しておくことが、契約後の法務トラブルを未然に防ぎます。
曖昧な要求を測定可能な要件へ翻訳する
運用保守の要件定義でつまずく最大の原因は、要求が「安定して動いてほしい」「障害にはすぐ対応してほしい」といった主観的な言葉のまま放置されることです。これでは測定も評価もできず、ベンダーは曖昧さを織り込んで保守的に（＝高めに）見積もります。要件定義の仕事は、こうした曖昧な要求を、誰が見ても同じ意味になる測定可能な要件へ翻訳することです。
「すぐ対応」を時間の数値へ落とし込む
「障害にはすぐ対応してほしい」という要求は、そのままでは要件になりません。これを「重大障害は初報応答15分以内、復旧4時間以内、通常障害は初報応答2時間以内、復旧8時間以内、恒久対応は5営業日以内」といった具体的な時間に落とし込みます（出典：ripla）。こうした数値があって初めて、ベンダーは必要な体制を見積もれ、発注側は提案を横並びで比較できます。
同様に、「常に安定して」は稼働率99.9%（月あたり許容停止約43分）や99.5%という数値に、「定期的にメンテナンスを」は月次・四半期といった頻度に翻訳します（出典：ripla）。翻訳のコツは、自社が本当に必要とする水準を見極めることです。すべてを最高水準にするとコストが跳ね上がるため、「この業務は数時間止まっても致命的ではない」といった現実を踏まえ、要件にメリハリをつけることが、過剰品質と過剰コストを避ける鍵になります。
保守範囲の内と外を一覧で線引きする
要件定義でもう一つ重要なのが、保守範囲の「内」と「外」を明確に一覧化することです。監視・障害対応・定期メンテナンス・軽微改修・問い合わせ対応など、どこまでを月額保守費に含め、どこからを別途有償とするかを表にして示します。とくに軽微改修については「○人日／月までは保守費内、それを超える改修は別途見積もり」といった上限を定めると、双方の認識がずれません。
この線引きを曖昧にすると、契約後に「これも保守に含まれると思っていた」「いや、それは範囲外だ」という認識の食い違いが頻発します。RFPの段階で「含むもの・含まないもの・条件付きで含むもの」を表で明示しておけば、ベンダーは前提を揃えて見積もりでき、発注側はサービス内容を正確に比較できます。範囲の明確化こそ、運用保守の要件定義の中核作業だと言えます。
範囲を翻訳する際にもう一つ意識したいのが、対象システムの構成情報をRFPに添付することです。利用しているOS・ミドルウェア・言語・フレームワークのバージョン、連携している外部システムやSaaS、想定される利用者数やデータ量といった前提を提示しないと、ベンダーは想像で見積もるしかなく、提案の精度が下がります。前提情報が揃っているRFPほど、ベンダーは具体的な体制を提案でき、後から「聞いていなかった」という追加費用も生まれにくくなります。曖昧さの翻訳とは、品質要件を数値化するだけでなく、判断材料となる前提を漏れなく開示することまで含むのです。
価格偏重を避ける評価軸の設計
RFPの最終段階で問われるのが、集まった提案をどう評価するかです。ここで価格の配点を高くしすぎると、品質を犠牲にして安さで勝負したベンダーが選ばれ、結果として障害多発や追加費用で高くつく、という本末転倒が起こります。運用保守は長期の継続契約であるため、評価軸の設計が長い目で見たコストと品質を左右します。
価格の配点を抑え、体制と実績を評価する
運用保守のRFP評価では、価格の配点を意図的に抑え、提案体制・実績・対応品質・継続性といった非価格要素に重みを置くことが推奨されます。具体的には、対応体制（要員のスキル・人数・対応時間帯）、類似システムの運用実績、SLA達成へのコミット、ドキュメント整備や引き継ぎへの姿勢などを評価項目に立て、それぞれに配点を割り振ります。価格はあくまで「適正範囲に収まっているか」を見る要素にとどめるのが健全です。
適正範囲の物差しには相場が使えます。年間保守費は開発費の15〜20%が目安、運用要員の人月単価は60万〜150万円といった一次データを基準に（出典：ripla）、極端に安い提案は「何かを削っているのではないか」と疑い、極端に高い提案は内訳の説明を求めます。価格を絶対評価ではなく相場との比較で見ることで、安かろう悪かろうの罠を避けられます。
移管・乗り換えを見据えた継続性を評価項目に入れる
運用保守は長期契約ですが、いつか別のベンダーへ移管する可能性も見据えておくべきです。評価軸には「ドキュメントを整備し、第三者でも運用を引き継げる状態を保つか」「ソースコードや設定情報を発注者が把握できる形で管理するか」といった継続性・移管容易性の項目を入れておきましょう。これにより、特定ベンダーへの過度な依存（ロックイン）を未然に防げます。
RFPの段階で「契約終了時には運用ドキュメント一式を引き継ぐこと」を要件として明記しておけば、将来の乗り換え時に引き継ぎが難航するリスクを下げられます。riplaはフルスクラッチ受託と国内開発の立場から、発注者がいつでも全体像を把握できる透明な運用を重視しており、こうした移管容易性の要件は健全なベンダー関係の前提になります。評価軸に継続性を組み込むことが、長期の安心につながります。
SLAと処理速度の数値要件の書き方
RFPの心臓部となるのが、SLA（サービス品質保証）と処理速度に関する数値要件です。これらは運用保守の品質を客観的に測る基準であり、ここを具体的に書けるかどうかで、RFP全体の精度が決まります。抽象論を排し、検証可能な数値で品質を定義しましょう。
稼働率・応答・復旧をSLA条文に落とす
SLA要件は、稼働率・応答時間・復旧時間の三本柱で書きます。稼働率は99.9%（月あたり許容停止約43分）や99.5%といった水準を、応答時間は重大15分・通常2時間、エスカレーション30分、回答24時間、復旧時間は重大4時間・通常8時間、恒久対応5営業日といった数値を要件として明記します（出典：ripla）。これらを表形式で整理し、障害の重大度区分（ランク分け）の定義もあわせて示すことで、ベンダーは前提を揃えて提案できます。
SLA要件を書くときに忘れてはならないのが、未達時の扱いです。目標を達成できなかった場合に、原因報告や改善計画の提出を求めるのか、保守費の減額（ペナルティ）まで定めるのかを要件に含めます。ただしペナルティは、原因が有耶無耶になって適用されない現実もあるため、「どの指標が、どの測定方法で、どの期間に未達なら適用されるか」まで具体化しておくことが、実効性を持たせる鍵です。
処理速度・性能の数値をRFPに明記する
SLAに加えて、システムの性能に関する数値要件も書いておくと、運用保守の品質基準がより明確になります。たとえば「全画面のレスポンスは3秒以内」といった処理速度要件は、RFPでよく用いられる指標です（出典：ripla）。応答速度が劣化したときに「何をもって遅いとするか」の基準があれば、性能改善の責任範囲もはっきりします。
処理速度要件を書くときは、対象画面や処理、想定する同時アクセス数、測定条件まで含めて定義すると、運用フェーズでの検証がぶれません。性能は利用者数の増加とともに劣化しがちなため、「想定ユーザー数の範囲では○秒以内を維持する」という条件付きの要件にすると現実的です。riplaはフルスクラッチ受託と国内開発の立場から、こうした数値要件を要件定義の段階で発注者と一緒に詰め、運用後の品質基準として機能させることを重視しています。数値で品質を語れるRFPこそ、良いベンダーを引き寄せる土台になります。
まとめ
システム運用保守のRFP・要件定義書を作るときの要点を振り返ると、第一にクラウドやSaaS連携を前提とした責任分界点を明記すること、第二に「すぐ対応」「安定して」といった曖昧な要求を時間や稼働率の数値へ翻訳し保守範囲の内外を一覧化すること、第三に価格の配点を抑えて体制・実績・継続性を評価軸に据えること、第四にSLA（稼働率99.9%、初報応答15分など）と処理速度（全画面3秒以内など）を検証可能な数値要件として書くこと、の四点に集約されます。いずれも一次データの相場を物差しに、過剰品質と過剰コストを避けることが大切です。
運用保守の要件定義で本当に大切なのは、「ベンダーに丸投げできる立派な書類」を作ることではなく、「自社が本当に必要とする品質を、誰が見ても同じ意味になる言葉で定義する」ことです。数値で品質を語れる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を創業。