ECサイト運用保守のRFP（提案依頼書）と要件定義書は、機能の一覧から書き始めず、SLAを中核に据えて組み立てるのが基本です。決済や在庫、セール時の負荷といったECならではのリスクも、SLAを起点に要件へ織り込みます。全体像は、ECサイト運用保守の完全ガイドで先に確認できます。
Webサービス開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「Webサービス開発の完全ガイドブック」で詳しく解説しています。
SLAを中核に据えた要件定義の進め方
ECサイト運用保守の要件定義は、作業の一覧を作る前に、品質目標を決めるところから始まります。自社のサイトがどの程度の品質で動き続ける必要があるかを、SLA（サービス品質保証）の指標で定義します。
ECサイトは売上を生む店舗です。そのため、許容できるダウンタイムや復旧時間は、事業へのインパクトから逆算して決めておきます。品質目標が曖昧なままだと、ベンダーごとに提供される品質がばらばらになり、各社を比べることも評価することもできなくなります。
稼働率・通知・復旧時間のSLA指標の定義
SLAを要件化するときに重要なのは、「努力目標型」か「目標保証型」かを区別することです。大阪市の運用保守ガイドラインでは、稼働率99.8%以上、障害通知30分以内100%、復旧6時間以内と4時間以内の遵守率95%が挙げられています。また、電話応答は20秒以内です。
ほかにも、問い合わせ解決95%（24時間以内）や応答3秒以内の達成率93%といった水準があります。これらをひな型にしつつ、自社のECサイトの事業インパクトに合わせて目標値を決めます。たとえば、年商規模を見て数分のダウンも許容できないサイトなら、稼働率の目標はより高く設定します。
努力目標型は、達成を目指す努力義務にとどまり、未達でもペナルティはありません。一方で、目標保証型は、SLAを下回った場合に料金減額などのペナルティを伴います。どちらを採用するかで、ベンダーの本気度と費用が変わります。
クリティカルな指標は目標保証型にし、要件にもその旨を明記します。そうしないと、SLAが形だけの約束になりかねません。SLAの定義では、JIS Q 20000などのITサービスマネジメントの規格も参考になります。
SLA指標は、目標値の水準と、未達だったときの扱いを組にして要件に書きます。
- 指標の数値：稼働率、障害通知時間、障害復旧時間のそれぞれに、目標の数字を入れる
- 保証の区分：各指標を努力目標型と目標保証型のどちらにするか、未達時にペナルティを設けるか
RTO/RPOとEC固有のリスクの要件化
ECサイトの運用保守では、SLAに加えて、障害からの戻し方も数値で決めておく必要があります。RTOは障害発生から復旧までの許容時間を、RPOはどの時点までのデータを復旧できるか、つまり許容できるデータ損失量を指します。
ECサイトでは、注文データや顧客データの損失がそのまま事業に響きます。そのため、「RPO=1時間以内。また、RTO=4時間以内」といった水準を、自社のデータの重要度から逆算して定めます。この水準が、バックアップの頻度や復旧手順の要件につながります。
ECサイト固有のリスクも、要件に織り込む必要があります。一般的なシステム保守のRFPには出てこない問いこそ、ECサイト運用保守の要件定義で差が出る部分です。たとえば、「セール前の負荷テストを実施するか」「決済障害を専用に監視するか」がそれにあたります。
そこで、自社のサイトが売上を失う具体的な場面を洗い出し、それを防ぐ要件を盛り込みます。この作業が、実効性のあるRFPの第一歩になります。
復旧の水準とEC固有のシナリオは、別々の観点から要件に書きます。
- 復旧の水準：RTOとRPOを、データ損失が事業に与える影響から定める
- EC固有のシナリオ：決済停止時の対応フロー、在庫連携のずれの検知と是正、セール時の負荷対応の体制
責任共有モデルと曖昧要求の翻訳
SLAを定義したら、次は責任範囲を明確にし、業務部門の曖昧な要求を具体的な要件に翻訳します。この工程は、EC運用保守の要件定義でもっとも見落とされやすく、トラブルの温床にもなりやすい部分です。
「安定して動かしてほしい」「セキュリティを守ってほしい」といった漠然とした要求のまま委託すると、問題が起きたときに責任の所在が曖昧になります。その結果、責任のなすり合いに発展しがちです。
クラウド責任共有モデルを前提にしたRFP
現在のECサイトの多くは、クラウドやSaaSの上で動いています。この環境では、セキュリティや可用性の責任を、クラウド事業者・運用保守ベンダー・自社の三者で分担する「責任共有モデル」が前提になります。
たとえば、インフラ層はクラウド事業者が、アプリケーションやミドルウェアの保守は運用保守ベンダーが、データの設定や利用者管理は自社が担う、といった線引きです。RFPには、この責任分界を前提に「ベンダーに何を求めるか」を書き込む必要があります。
責任共有モデルを理解しないままRFPを書くと、「クラウド事業者の責任範囲のことまでベンダーに求めてしまう」「自社で対応すべきことをベンダー任せにする」といった食い違いが生まれます。とくにセキュリティ事故は責任のなすり合いになりやすいため、責任分界点をRFPの段階で文書化しておくことが、後の致命的なトラブルを防ぎます。
RFPでは、クラウド事業者・運用保守ベンダー・自社の担当の境目を、項目ごとに書きます。
- 担当範囲：脆弱性対応の範囲（どのレイヤーまでベンダーが面倒を見るか）、セキュリティインシデント発生時の対応責任、バックアップの主体
- 障害切り分け：切り分け時に、各社がどこを受け持つかの役割
業務部門の曖昧な要求の要件への翻訳
要件定義のもう一つの難所は、業務部門から上がってくる曖昧な要求を、具体的な要件に翻訳する作業です。
マーケティング部門や運営部門からは、「サイトが速くなってほしい」「セールで落ちないようにしてほしい」「商品をすぐ更新できるようにしてほしい」といった感覚的な要望が出てきます。ただ、これらをそのままRFPに書いても、ベンダーは何をすればよいか分かりません。たとえば、「速くなってほしい」は「応答3秒以内の達成率93%」に、「落ちないでほしい」は「セール時の想定アクセス数と稼働率目標」に言い換えます。
この翻訳作業には、業務部門と情報システム部門（あるいは委託先候補）の対話が欠かせません。曖昧な要求をそのまま放置すると、リリース後に「思っていたのと違う」というギャップが生まれ、追加費用や再委託につながります。
また、RFP作成自体を外部のITコンサルに委託する選択肢もあります。自社に要件定義の知見が乏しい場合は、この翻訳工程を専門家に手伝ってもらうのも現実的な進め方です。
曖昧な要求を測定できる要件に変えておくことが、運用保守の品質を左右します。運用保守の機能構成については、『ECサイト運用保守の必要機能・標準機能の一覧について』もあわせてご覧ください。
翻訳は、まず業務部門の困りごとを聞き取るところから始めます。
- 聞き取り：業務部門が何に困っているか、どの場面で売上を失っているかを確かめる
- 指標への置き換え：応答時間や達成率など、測定できる指標に言い換える
引き継ぎプロセスと契約形態の要件化
既存のサイトを別のベンダーに引き継ぐ場合は、要件定義で引き継ぎプロセスを必ず織り込みます。運用保守の乗り換えで、もっとも失敗が起きやすいのがこの引き継ぎの場面です。
既存ベンダーが協力的でない、ドキュメントが整備されていない、キーマンが退職して仕様が分からない、といった事態が引き継ぎを難航させます。こうした事態を見越して要件化しておくことが、移行の成否を分けます。
段階的な引き継ぎ（約8週間）の要件化
運用保守の引き継ぎは、一気に切り替えず段階的に進めるのが定石です。一般には約8週間（2か月）をかけ、委託先はPM0.25人月とリードエンジニア1.0人月、現行担当は週2日の関与、という体制が一つの目安になります。
引き継ぎを軽視して「すぐに切り替えられる」と安請け合いするベンダーには、注意が必要です。引き継ぎプロセスを要件として明文化し、十分な期間を確保することが、運用が止まる事態を防ぎます。
ベンダー選定は、契約満了の6か月前には着手するのが望ましく、選定プロセス全体で4〜6か月を見込みます。引き継ぎ期間を確保するには、この逆算が欠かせません。
また、既存ベンダーをあえてRFPに参加させ、条件を見直して契約を続ける選択も、30〜40%の割合で見られます。乗り換えを前提にせず、既存ベンダーとの条件交渉も含めて検討するのが現実的です。
引き継ぎで失敗した事例は、『ECサイト運用保守開発・導入の失敗・課題・注意点・リスクについて』もあわせてご覧ください。
引き継ぎ計画では、期間と体制、作業の順序を先に決めておきます。
- 期間と体制：委託先と現行担当それぞれが、どの程度関わるかを期間とあわせて決める
- 段階の順序：現行仕様の調査とドキュメント整備から、並行稼働を経て完全移行へ進める
準委任/請負と費用方式の要件化
運用保守の契約形態には、準委任契約と請負契約があり、それぞれ責任の重さが異なります。準委任は「善管注意義務をもって業務を遂行する」ものであり、結果（成果物の完成）までは保証しません。
請負は成果物の完成責任を負います。運用保守は継続的な業務のため準委任が中心になりますが、特定の改修や移行作業は請負にするといった使い分けを、要件で整理します。
契約書には、対象範囲と含まれない業務、免責事項を明記しておきます。後のトラブルを避けるうえで、この記載が鍵になります。
費用方式も要件で定めます。月額定額と従量（T&M：実作業時間に応じた課金）のどちらにするかに加えて、SLA未達時のペナルティや、解約時の精算（稼働月数割りなど）も決めておきます。
費用と契約形態を曖昧にしたまま委託すると、「これは契約外で追加費用」というやり取りが頻発します。そのため、RFPの段階で費用方式・ペナルティ・解約条件まで要件化しておくことが、健全な委託関係を築く前提になります。
契約と費用は、契約形態と想定外の費用の負担を分けて要件に書きます。
- 契約形態：準委任か請負か、改修や移行作業ごとの使い分け
- 想定外の費用：OSSの保守やデータ復旧など、発生し得る費用の負担者を事前に決める
まとめ
ECサイト運用保守のRFP・要件定義書・提案依頼書は、機能の列挙から始めず、SLA（稼働率99.8%以上、障害通知30分以内、復旧6時間以内など）を中核に据えて書くのが鉄則です。そのうえで、クラウドの責任共有モデルを前提に責任範囲を明確にし、曖昧な業務要求を測定可能な要件に翻訳します。
RTO/RPOやEC固有のリスクも要件に織り込みます。さらに、約8週間の段階的な引き継ぎプロセスを要件に組み込み、準委任か請負か、費用方式、解約条件まで書き込みます。評価では価格配点を20点以下に抑え、品質と体制で選ぶことが、安さだけで失敗するリスクを避ける鍵です。
運用保守は形のないサービスだからこそ、要件定義の質がそのまま委託の成否に直結します。SLAという数値で品質を定義し、責任分界を文書化し、引き継ぎまで設計した要件こそが、安定して売れ続けるECサイトを支えます。
riplaはフルスクラッチ受託と国内運用保守を組み合わせ、SLAを中核に据えた要件整理から、責任共有モデルの整理、引き継ぎ計画、評価軸の設計までを発注企業と協働で支援します。全体像の確認には、あらためて完全ガイドをご活用ください。
▼RFP作成前に読みたい無料ホワイトペーパー
・Webサービス開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。