Webサービスやクラウドサービスの運用保守を委託するとき、成否を分けるのはRFP（提案依頼書）と要件定義書の質です。
曖昧な依頼のまま丸投げすると、見積りを比べられず、契約後には「それは範囲外です」というトラブルが頻発します。全体像はサービス運用保守の完全ガイドで確認できます。
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
責任共有モデルを前提にした要件整理
クラウドサービスの運用保守では、RFPの土台になるのが責任共有モデルの理解です。クラウド上のサービスでは、インフラの一部をクラウド事業者が管理し、その上のアプリケーションやデータは自社か運用ベンダーが管理します。
この責任の分かれ目があいまいなままRFPを書くと、「OSのパッチ適用は誰がやるのか」「データ消失時の復旧責任は誰にあるのか」が宙に浮きます。その結果、障害時に責任のなすり合いが起こります。
そのため、要件整理は責任分界を一つずつ明文化するところから始めます。
自社・クラウド事業者・ベンダーの責任分界の明記
責任分界を明記するとは、運用保守の作業項目を一覧にして、それぞれを「自社」「クラウド事業者」「運用ベンダー」のどこが担うのかを表で整理し、担当を一つずつ確認することです。
この表をRFPに添付すれば、ベンダーは自分が担う範囲を正確に理解して見積もりを出せ、各社の提案も同じ前提で比べられるようになります。
責任分界があいまいなまま契約すると、深刻なトラブルを招きます。特にセキュリティ事故では、「設定不備は自社の責任か、ベンダーの監視漏れか」をめぐって責任のなすり合いになり、最悪の場合は訴訟に発展します。これは運用保守の失敗事例として典型的なパターンです。
RFPの段階で責任分界を表にして固めておけば、こうした紛争を未然に防げます。要件整理では、曖昧さを残さないことが基本です。
担当が曖昧になりやすい作業は、たとえば次のようなものです。
- OS・ミドルウェア・データ：パッチ適用、バージョンアップ、データの暗号化
- バックアップ・監視・障害対応：取得と復元検証、しきい値の設定、一次対応
SLA・RTO・RPOの測定可能な要件化
責任分界とあわせて要件にすべきなのが、SLAとRTO・RPOです。「安定して動かしてほしい」という言い方では、要件として測れません。
RFPには、稼働率や応答時間などを、測れる数値で水準として明記します。SaaSでは、これにRTO（目標復旧時間）とRPO（目標復旧時点）を加えます。障害時にどれだけ早く、どの時点まで戻すかを要件として定めるためです。
SLA要件では、努力目標型にするか目標保証型にするかも明記します。目標保証型は未達時にペナルティを伴うため、ベンダーにとって重い約束になり、その分見積りも上がります。
過剰な品質を求めればコストが膨らみ、品質を緩めればトラブルが増えます。そのため、自社のサービスにとって本当に必要な水準を見極めることが大切です。
SLA・RTO・RPOを測定可能な数値で要件化しておくと、後で「言った・言わない」の水掛け論を防げます。比較できる提案を引き出す前提にもなります。これらは運用保守の機能とも密接に関わるため、関連記事もあわせてご覧ください。
測れる数値で書いた水準は、たとえばこのように並びます。
- 稼働と応答：稼働率99.8%以上、応答3秒以内の達成率93%
- 障害対応と復旧：障害通知30分以内100%、重大障害は年2回まで、復旧6時間以内・4時間以内の遵守率95%、24時間以内の解決率95%
業務部門の曖昧な要求の運用要件への翻訳
運用保守の要件定義でつまずきやすいのは、業務部門から上がってくる要求が曖昧なことです。
「落ちないようにしてほしい」「問い合わせたらすぐ対応してほしい」といった声は、そのままベンダーに伝えても要件になりません。こうした感覚的な要求を測定可能な運用要件に翻訳する作業は、要件定義の腕の見せどころです。
翻訳を怠ると、ベンダーは何を作ればよいか分からず、提案も見積りもばらつきます。
「落ちないように」の稼働率と復旧時間への変換
翻訳の具体例を見ていきます。「落ちないようにしてほしい」という要求は、「稼働率99.8%以上を保証し、月間のダウンタイムは何分以内に抑える」という形に翻訳します。
「すぐ対応してほしい」は、「障害通知は検知から30分以内に100%実施し、重大障害は復旧4時間以内の遵守率95%を満たす」と変換します。このように、感覚的な言葉は数値とその測定方法に置き換えて初めて、ベンダーが約束できる要件になります。
翻訳の際は、業務部門に「その水準が本当に必要か」を問い返すことが欠かせません。たとえば、稼働率を99.9%から99.99%へ上げると、必要な冗長構成や監視体制が跳ね上がり、コストが増えます。
業務部門は「高いほど良い」と考えがちですが、サービスの性質によっては99.5%で十分なこともあります。曖昧な要求を翻訳する過程は、過剰品質によるコスト増を防ぐ機会でもあります。
要件定義の担当者は、業務部門とベンダーの間に立つ翻訳者として、必要十分な水準を見極める役割を担います。
感覚的な言葉を数値に変えるときは、稼働と障害の二つの面で考えます。
- 稼働率：ダウンタイムの上限（月間の分数）
- 障害対応：通知までの時間と、重大障害の復旧時間
RFP作成自体の外部委託
曖昧な要求の翻訳や責任分界の整理は、専門知識を要する難しい作業です。社内に運用保守の知見を持つ人材がいない場合は、RFPの作成そのものをITコンサルなどの外部に委託する選択肢があります。
第三者がRFPを作ると、自社では気づけない論点（責任分界の抜け、SLA水準の妥当性、想定外費用の項目）を網羅できます。さらに、特定ベンダーに有利な偏った要件になることも防げます。
RFP作成を外部に委託すると、その後の見積り比較やベンダー選定の精度も高まります。
運用を担う会社と要件を書く会社を分けておけば、利益相反を避けやすく、より客観的な要件が期待できます。
ただし、外部委託にも費用がかかるため、内製でやり切るか外部に頼るかは、サービスの規模や重要度に応じて決めます。要件定義は運用保守プロジェクト全体の品質を左右する上流工程であり、ここに相応のリソースを投じる価値は十分にあります。
委託先を選ぶときは、利益相反が起きない形になっているかを基準にします。
- 実運用の担当：RFP作成と運用受託を同じ会社が担うかどうか
- 要件の客観性：特定のベンダーに偏らない要件になっているか
RFPに盛り込むべき項目と契約形態
責任分界とSLA要件が固まったら、それをRFPという形に組み立てます。RFPは、ベンダーに提案を求めるための文書であり、ここに記載すべき項目に漏れがあると、提案も漏れます。
とくに「含まれない業務」や「免責事項」を明記することが、後のトラブルを防ぐうえで重要です。あわせて、準委任か請負かという契約形態の選択も、RFPの前提として整理しておく必要があります。
RFPに必ず盛り込むべき項目
RFPに項目が抜けると、提案も抜けてしまいます。
- 運用保守のRFPに盛り込む主な項目は次のとおりです。
- 対象サービスの概要とシステム構成（クラウド環境・技術スタック）
・運用保守の作業範囲と責任分界表（含まれる業務／含まれない業務）
・求めるSLA水準（稼働率・応答時間・障害通知・復旧時間・RTO/RPO）
・監視・バックアップ・障害対応・改修の各要件
・体制とエスカレーションフロー（対応時間帯・連絡経路）
・想定外費用の取り扱い（OSS保守・データ復旧・大規模改修）
・契約形態・契約期間・解約条件
これらを網羅すると、ベンダー各社が同じ前提で提案でき、比較が成立します。
特に見落とされやすいのが、想定外費用の取り扱いです。利用しているOSS（オープンソースソフトウェア）のサポート切れ対応や障害時のデータ復旧作業など、通常の保守費に含まれない作業が発生したときに、費用の扱いが問題になります。
どう費用を扱うかを事前に決めておかないと、後から高額な追加請求に驚くことになります。さらに、HW交換後の故障部品の所有権がどちらにあるかといった細かな取り決めも、契約段階で明記しておくと、トラブルを避けられます。
RFPは、想定外をいかに減らすかという観点で項目を点検することが大切です。
準委任と請負の選択と法務リスク
運用保守の契約形態は、準委任と請負のどちらにするかで法的な性質が変わります。準委任は「善管注意義務をもって業務を遂行する」契約です。
運用保守では、定常運用を準委任、個別の改修を請負と使い分けるケースもあります。どちらを選ぶかで責任の重さと費用が変わるため、RFPの前提として明確にしておきます。
契約段階では、対象範囲・含まれない業務・免責の三点を明記することが、法務リスクを抑える鍵です。「どこまでが運用保守の責任か」があいまいだと、障害時に責任の所在をめぐって紛争になります。
特にセキュリティ事故では、損害賠償の範囲や免責の条件が争点になりやすいため、契約書での取り決めが重要です。RFPと要件定義で責任分界を固め、それを契約書で法的に裏づけます。
この一連の流れが、運用保守を安心して委託するための基盤になります。riplaはフルスクラッチ受託と国内運用保守の立場から、契約形態の選択と責任分界の整理を支援しています。
この2つは、どこまでの結果に責任を負うかで性質が変わります。
- 準委任：監視や定型的な運用業務に一般的で、成果物の完成責任は負わない
- 請負：成果物の完成を約束し、特定の改修やシステム改善に適する
提案評価の軸と見積りの妥当性判断
RFPを発行して提案が出そろったら、いよいよ評価に入ります。ここで価格の安さだけで選ぶと、運用保守では高い確率で失敗します。
安いベンダーは体制が薄かったり、SLAの遵守実績が乏しかったりして、結局は障害対応に追われ、TCOがかさみます。評価の設計と、見積りの妥当性を見抜く目が、ベンダー選定の成否を決めます。
価格の配点を20点以下に抑える評価設計
運用保守のベンダー選定では、価格の配点を20点以下に抑えるのが定石です。
100点満点のうち価格に20点しか配分しないということは、残りの80点を、技術力や体制を中心に、SLA遵守の実績や提案内容といった質の要素で評価するということです。
運用保守は長期にわたって品質が問われる契約です。そのため、初期の価格よりも、数年間にわたって安定した品質を出せるかを重視すべきです。
価格偏重で選ぶと、安かろう悪かろうのベンダーに当たり、障害が多発して結局TCOが膨らみます。
評価では、価格以外の要素も多面的に見ます。AIOpsなど省力化への取り組みを評価に含めると、運用品質を幅広く評価できます。
既存ベンダーをあえてRFPに参加させ、競争を通じて条件を見直したうえで継続するケースも、30〜40%あります。
評価は、新しいベンダーを選ぶ場であると同時に、最適な条件を引き出すプロセスでもあります。
提案を採点するときは、体制と実績の二つの面から見ていきます。
- 運用体制：障害対応の体制（24時間対応の可否、エスカレーション経路）
- 実績と引き継ぎ：SLAの遵守実績、過去の類似サービスの運用実績、ドキュメント整備や引き継ぎへの姿勢
見積りの妥当性を判断する軸
見積りの妥当性を判断するには、運用保守のコスト構造を知っておくと役立ちます。
一次データでは、保守はソフトウェア全体コストの40〜80%（平均60%）を占め、保守作業の約30%が調査・分析に費やされるとされています。
この相場感を持っていれば、「不自然に安い見積り」や「根拠の薄い高額見積り」を見抜けます。極端に安い見積りは、必要な作業が抜けている可能性が高く、契約後に追加費用を請求される危険があります。
見積りを変える要因には、システムの理解容易性やドキュメント整備度が大きく関わります。同じ規模のシステムでも、ドキュメントが整っていれば保守は安く、整っていなければ調査に時間がかかって高くなります。
前提が違えば、金額の比較は意味をなしません。
責任分界表とSLA要件で前提をそろえたRFPがあってこそ、見積りの妥当な比較が可能になります。riplaはフルスクラッチ受託と国内運用保守の立場から、見積りの構造的な評価を支援しています。
見積りを並べて比べる前に、まず前提がどこまでそろっているかを確かめます。
- 作業範囲：各社の見積りが同じ作業範囲を前提にしているか
- 理解度：システムの理解度とドキュメントの前提がそろっているか
まとめ
サービス運用保守のRFP・要件定義では、責任共有モデルを前提にした要件整理、業務部門の曖昧な要求の運用要件への翻訳、RFPに盛り込む項目の網羅を押さえます。さらに、価格偏重を避ける評価軸を加えた4点を押さえることで、比較できる実効性のある提案を引き出せます。
責任分界は表で固め、SLA・RTO・RPOは測定可能な数値で定めます。そのうえで、想定外費用の扱いまで明記します。評価では、価格配点を20点以下に抑え、技術力と体制を重視します。この一連の設計が、運用保守の品質を上流で決定づけます。
要件定義は面倒で時間のかかる工程ですが、ここを丁寧にやり切るかどうかが、運用保守プロジェクト全体の成否を分けます。曖昧なまま委託すれば、障害時の責任のなすり合いや想定外費用に苦しむことになります。一方で、丁寧に要件化すれば、安心して長期にわたり任せられる関係を築けます。
riplaはフルスクラッチ受託と国内運用保守を組み合わせ、責任分界の明確化と曖昧な要求の翻訳を支えます。SLA設計から見積り評価までも、一貫して支援します。全体像の確認には、改めて完全ガイドをご活用ください。
▼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を創業。