サービス運用保守のRFP/要件定義書/提案依頼書について

Webサービスやクラウドサービスの運用保守を外部に委託しようとするとき、成否を分けるのがRFP（提案依頼書）と要件定義書の質です。「とにかく運用保守をお願いしたい」という曖昧な依頼でベンダーに丸投げすると、提示される見積りは各社バラバラで比較できず、契約後に「それは範囲外です」というトラブルが頻発します。とくにクラウドサービスでは、自社とクラウド事業者・運用ベンダーの間で責任がどう分かれるのか（責任共有モデル）を前提にしないと、「誰がどこまで面倒を見るのか」が宙に浮き、障害時に責任のなすり合いが起こります。

本記事は、SaaSやWebサービス全般の運用保守におけるRFP・要件定義書・提案依頼書の作り方を、責任共有モデルを前提とした要件整理・曖昧要求の翻訳・RFP記載項目・評価軸という4つの軸で体系的に解説する「要件定義特化」の記事です。クラウドネイティブ前提のRFP設計、業務部門の曖昧な要求をどう運用要件に翻訳するか、価格の配点を20点以下に抑える評価設計まで、一次データとあわせて具体的に整理します。読み終えるころには、自社で運用保守のRFPを書き起こすための骨格が描けるはずです。なお、サービス運用保守の全体像をまだ把握していない方は、まずサービス運用保守の完全ガイドから読むことをおすすめします。

責任共有モデルを前提にした要件整理

クラウドサービスの運用保守でRFPの土台になるのが、責任共有モデルの理解です。クラウド上で動くサービスは、インフラの一部をクラウド事業者が、その上のアプリケーションやデータを自社や運用ベンダーが管理します。この責任の分かれ目を曖昧にしたままRFPを書くと、「OSのパッチ適用は誰がやるのか」「データ消失時の復旧責任は誰にあるのか」が宙に浮き、障害時に責任のなすり合いが起こります。要件整理の出発点は、この責任分界を一つひとつ明文化することです。

責任分界を明記するとは、運用保守の作業項目を一覧化し、それぞれを「自社」「クラウド事業者」「運用ベンダー」のどこが担うのかを表で整理することです。OSのパッチ適用、ミドルウェアのバージョンアップ、バックアップの取得と復元検証、監視のしきい値設定、障害時の一次対応、データの暗号化といった項目を一つずつ割り当てます。この表をRFPに添付すれば、ベンダーは「自分が何を担うのか」を正確に理解したうえで見積もりを出せ、各社の提案が同じ前提で比較できるようになります。

責任分界が曖昧なまま契約すると、深刻なトラブルを招きます。とくにセキュリティ事故が起きたとき、「設定不備は自社の責任か、ベンダーの監視漏れか」をめぐって責任のなすり合いになり、最悪の場合は訴訟に発展します。これは運用保守の失敗事例として典型的なパターンです。RFPの段階で責任分界を表で固めておくことが、こうした事故時の紛争を未然に防ぐ最大の防衛策になります。曖昧さを残さないことが、要件整理の鉄則です。

責任分界とあわせて要件化すべきが、SLAとRTO・RPOです。「安定して動かしてほしい」では要件になりません。稼働率99.8%以上、応答3秒以内の達成率93%、障害通知30分以内100%、重大障害は年2回まで、復旧6時間以内・4時間以内の遵守率95%、24時間以内の解決率95%といった具体的な数値を、RFPで求める水準として明記します。SaaSではこれにRTO（目標復旧時間）とRPO（目標復旧時点）を加え、「障害時にどれだけ早く、どの時点まで戻すか」を要件として定めます。

SLA要件を定めるときは、努力目標型にするか目標保証型にするかも明記します。目標保証型は未達時にペナルティを伴うため、ベンダーにとって重い約束になり、その分見積りも上がります。過剰品質を求めればコストが膨らみ、品質を緩めればトラブルが増えるため、自社のサービスにとって本当に必要な水準を見極めることが大切です。SLA・RTO・RPOを測定可能な数値として要件化することが、後で「言った・言わない」の水掛け論を防ぎ、比較可能な提案を引き出す前提になります。これらは前述した運用保守の機能とも密接に関わるため、関連記事もあわせてご覧ください。

業務部門の曖昧な要求を運用要件に翻訳する

運用保守の要件定義でつまずきやすいのが、業務部門から上がってくる要求が曖昧なことです。「落ちないようにしてほしい」「問い合わせたらすぐ対応してほしい」といった声を、そのままベンダーに伝えても要件にはなりません。これらの感覚的な要求を、測定可能な運用要件に翻訳する作業こそ、要件定義の腕の見せどころです。翻訳を怠ると、ベンダーは何を作ればよいか分からず、提案も見積りもばらつきます。

翻訳の具体例を見てみましょう。「落ちないようにしてほしい」という要求は、「稼働率99.8%以上を保証し、月間のダウンタイムは何分以内に抑える」という形に翻訳します。「すぐ対応してほしい」は、「障害通知は検知から30分以内に100%実施し、重大障害は復旧4時間以内の遵守率95%を満たす」と変換します。このように、感覚的な言葉を数値とその測定方法に置き換えることで、初めてベンダーが約束できる要件になります。

翻訳の際に重要なのは、業務部門に「その水準が本当に必要か」を問い返すことです。稼働率を99.9%から99.99%へ上げると、必要な冗長構成や監視体制が跳ね上がり、コストが大きく増えます。業務部門は「高いほど良い」と考えがちですが、サービスの性質によっては99.5%で十分なこともあります。曖昧な要求を翻訳する過程は、過剰品質によるコスト増を防ぐ機会でもあります。要件定義の担当者は、業務部門とベンダーの間に立つ「翻訳者」として、必要十分な水準を見極める役割を担います。

曖昧な要求の翻訳や責任分界の整理は、専門知識を要する難しい作業です。社内に運用保守の知見を持つ人材がいない場合、RFPの作成自体をITコンサルなどの外部に委託する選択肢があります。第三者がRFPを作ることで、自社では気づけない論点（責任分界の抜け、SLA水準の妥当性、想定外費用の項目）を網羅でき、特定ベンダーに有利な偏った要件になることも防げます。RFP作成の外部委託は、その後の見積り比較やベンダー選定の精度を大きく高めます。

RFP作成を外部委託する際は、その委託先が実際の運用も担うのか、RFP作成のみを請け負うのかを区別しておくと、利益相反を避けられます。RFP作成と運用受託を切り分ければ、より客観的な要件が期待できます。ただし、外部委託にも費用がかかるため、サービスの規模や重要度に応じて、内製でやり切るか外部に頼るかを判断します。要件定義は運用保守プロジェクト全体の品質を左右する上流工程であり、ここに相応のリソースを投じる価値は十分にあります。

RFPに盛り込むべき項目と契約形態

責任分界とSLA要件が固まったら、それをRFPという形に組み立てます。RFPは、ベンダーに提案を求めるための文書であり、ここに記載すべき項目に漏れがあると、提案も漏れます。とくに「含まれない業務」や「免責事項」を明記することが、後のトラブルを防ぐうえで重要です。あわせて、準委任か請負かという契約形態の選択も、RFPの前提として整理しておく必要があります。

運用保守のRFPに盛り込むべき主な項目は次のとおりです。
・対象サービスの概要とシステム構成（クラウド環境・技術スタック）
・運用保守の作業範囲と責任分界表（含まれる業務／含まれない業務）
・求めるSLA水準（稼働率・応答時間・障害通知・復旧時間・RTO/RPO）
・監視・バックアップ・障害対応・改修の各要件
・体制とエスカレーションフロー（対応時間帯・連絡経路）
・想定外費用の取り扱い（OSS保守・データ復旧・大規模改修）
・契約形態・契約期間・解約条件

これらを網羅することで、ベンダー各社が同じ前提で提案でき、比較が成立します。

とくに見落とされやすいのが、想定外費用の取り扱いです。利用しているOSS（オープンソースソフトウェア）のサポート切れ対応や、障害時のデータ復旧作業など、通常の保守費に含まれない作業が発生したとき、どう費用を扱うのかを事前に決めておかないと、後から高額な追加請求に驚くことになります。また、HW交換後の故障部品の所有権がどちらにあるかなど、細かな取り決めも契約段階で明記しておくと、トラブルを避けられます。RFPは「想定外をいかに減らすか」という観点で項目を点検することが大切です。

運用保守の契約形態は、準委任と請負のどちらにするかで法的な性質が変わります。準委任は「善管注意義務をもって業務を遂行する」契約で、成果物の完成責任は負いません。監視や定型的な運用業務は準委任が一般的です。一方、請負は「成果物の完成」を約束する契約で、特定の改修やシステム改善を発注する場合に向きます。運用保守では、定常運用を準委任、個別の改修を請負と使い分けるケースもあります。どちらを選ぶかで、責任の重さと費用が変わるため、RFPの前提として明確にしておきます。

契約段階では、対象範囲・含まれない業務・免責の三点を明記することが、法務リスクを抑える鍵です。「どこまでが運用保守の責任か」が曖昧だと、障害時に責任の所在をめぐって紛争になります。とくにセキュリティ事故では、損害賠償の範囲や免責の条件が争点になりやすいため、契約書での取り決めが重要です。RFPと要件定義で責任分界を固め、契約書でそれを法的に裏づける。この一連の流れが、運用保守を安心して委託するための基盤になります。riplaはフルスクラッチ受託と国内運用保守の立場から、契約形態の選択と責任分界の整理を支援しています。

提案評価の軸と見積りの妥当性判断

RFPを発行して提案を集めたら、いよいよ評価です。ここで価格の安さだけで選ぶと、運用保守では高い確率で失敗します。安いベンダーは体制が薄かったり、SLAの遵守実績が乏しかったりして、結局は障害対応に追われTCOがかさみます。評価軸の設計と、見積りの妥当性を見抜く目が、ベンダー選定の成否を決めます。

運用保守のベンダー選定では、価格配点を20点以下に抑えるのが定石です。100点満点の評価のうち、価格に20点しか配分しないということは、残りの80点を技術力・体制・SLA遵守の実績・提案内容といった質的な要素で評価するということです。運用保守は長期にわたって品質が問われる契約のため、初期の価格よりも「数年間にわたって安定した品質を出せるか」が重要です。価格偏重で選ぶと、安かろう悪かろうのベンダーに当たり、障害多発で結局TCOが膨らみます。

評価項目には、SLAの遵守実績、障害対応の体制（24時間対応の可否、エスカレーション経路）、過去の類似サービスの運用実績、ドキュメント整備や引き継ぎへの姿勢、そしてAIOpsなど省力化への取り組みを含めると、運用品質を多面的に評価できます。前述のとおり、既存ベンダーをあえてRFPに参加させ、競争を通じて条件を見直して継続するケースも30〜40%あります。評価は「新しいベンダーを選ぶ」ことだけが目的ではなく、「最適な条件を引き出す」プロセスでもあると捉えてください。

見積りの妥当性を判断するには、運用保守のコスト構造を知っておくことが役立ちます。一次データでは、保守はソフトウェア全体コストの40〜80%（平均60%）を占め、保守作業の約30%が調査・分析に費やされるとされます。この相場感を持っていれば、「不自然に安い見積り」や「根拠の薄い高額見積り」を見抜けます。極端に安い見積りは、必要な作業が抜けている可能性が高く、契約後に追加費用を請求される危険があります。

見積りの変動要因として、システムの理解容易性やドキュメント整備度が大きいことも押さえておきましょう。同じ規模のシステムでも、ドキュメントが整っていれば保守は安く、整っていなければ調査に時間がかかって高くなります。見積りを比較する際は、各社が前提としているシステムの理解度や作業範囲が揃っているかを確認することが重要です。前提が違えば、金額の比較は意味をなしません。責任分界表とSLA要件で前提を揃えたRFPがあってこそ、見積りの妥当な比較が可能になるのです。riplaはフルスクラッチ受託と国内運用保守の立場から、見積りの構造的な評価を支援しています。

まとめ

サービス運用保守のRFP・要件定義は、責任共有モデルを前提とした要件整理、業務部門の曖昧な要求の運用要件への翻訳、RFP記載項目の網羅、価格偏重を避ける評価軸の4つを押さえることで、比較可能で実効性のある提案を引き出せます。自社・クラウド事業者・運用ベンダーの責任分界を表で固め、SLA・RTO・RPOを測定可能な数値で定め、想定外費用の扱いまで明記する。そして評価では価格配点を20点以下に抑え、技術力と体制を重視する。この一連の設計が、運用保守の品質を上流で決定づけます。

要件定義は、面倒で時間のかかる工程ですが、ここを丁寧にやり切るかどうかが、運用保守プロジェクト全体の成否を分けます。曖昧なまま委託すれば、障害時の責任なすり合いや想定外費用に苦しみ、丁寧に要件化すれば、安心して長期にわたり任せられる関係を築けます。riplaはフルスクラッチ受託と国内運用保守を組み合わせ、責任分界の明確化・曖昧要求の翻訳・SLA設計・見積り評価までを一貫して支援します。全体像の確認には、あらためて完全ガイドをご活用ください。

株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。