ECサイトの運用保守を外部に委託するとき、その成否をもっとも大きく左右するのがRFP（提案依頼書）と要件定義です。とくにECサイトの運用保守は、決済・在庫・セール波動・セキュリティといった固有のリスクを抱えるため、これをいかに正確に要件として整理し、RFPや要件定義書に落とし込めるかが、安定して売れ続けるサイトになるか、障害と追加費用に振り回されるかの分かれ目になります。価格の安さだけで委託先を選び、肝心のSLA（サービス品質保証）や責任範囲が曖昧なまま契約した結果、いざ障害が起きたときに「それは契約外です」と突き放される失敗は、決して珍しくありません。
本記事は、ECサイト運用保守のRFP・要件定義書・提案依頼書を、発注企業の視点から具体的に解説する「要件定義特化」の記事です。クラウドの責任共有モデルを前提にしたRFPの作り方、業務部門の曖昧な要求を要件に翻訳する方法、SLA指標の定義、評価軸（価格配点を抑える）、引き継ぎプロセスの要件化まで、運用保守の実務に即して掘り下げます。読み終えるころには、ベンダーに渡すRFPの骨子が描けるはずです。なお、全体像をまだ把握していない方は、まずECサイト運用保守の完全ガイドから読むことをおすすめします。
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（目標復旧時点）を要件化します。RTOは障害発生から復旧までの許容時間、RPOはどの時点までのデータを復旧できるか（=許容できるデータ損失量）を定めるものです。ECサイトでは注文データや顧客データの損失が事業に直結するため、「RPO=1時間以内、RTO=4時間以内」といった水準を、自社のデータの重要度から逆算して定義します。これがバックアップの頻度や復旧手順の要件につながります。
さらに、ECサイト固有のリスクを要件に織り込むことが欠かせません。決済が止まったときの対応フロー、在庫連携がずれたときの検知と是正、大型セール時の負荷対応の体制、こうしたEC特有のシナリオを要件として明記します。一般的なシステム保守のRFPには出てこない、「セール前の負荷テストを実施するか」「決済障害を専用に監視するか」といった項目こそ、ECサイト運用保守の要件定義の差別化ポイントです。自社のサイトが売上を失う具体的な場面を洗い出し、それを防ぐ要件を盛り込むことが、実効性のあるRFPの第一歩になります。
責任共有モデルと曖昧要求の翻訳
SLAを定義したら、次に取り組むのが責任範囲の明確化と、業務部門の曖昧な要求の翻訳です。ここがEC運用保守の要件定義でもっとも見落とされやすく、かつトラブルの温床になる工程です。「安定して動かしてほしい」「セキュリティを守ってほしい」といった漠然とした要求のまま委託すると、いざ問題が起きたときに責任の所在が曖昧になり、なすり合いに発展します。
クラウド責任共有モデルを前提にしたRFP
現在のECサイトの多くは、クラウドやSaaSの上で動いています。この環境では、セキュリティや可用性の責任が、クラウド事業者・運用保守ベンダー・自社の三者で分担される「責任共有モデル」が前提になります。インフラ層はクラウド事業者、アプリケーションやミドルウェアの保守は運用保守ベンダー、データの設定や利用者管理は自社、といった線引きです。RFPでは、この責任分界を前提に、「ベンダーに何を求めるか」を明確に定義する必要があります。
具体的には、脆弱性対応の範囲（どのレイヤーまでベンダーが面倒を見るか）、セキュリティインシデント発生時の対応責任、バックアップの主体、障害切り分け時の各社の役割などを、RFPに明記します。責任共有モデルを理解せずにRFPを書くと、「クラウド事業者の責任範囲のことまでベンダーに求めてしまう」「逆に自社で対応すべきことをベンダー任せにする」といった食い違いが生まれます。とくにセキュリティ事故は責任のなすり合いになりやすいため、責任分界点をRFPの段階で文書化しておくことが、後の致命的なトラブルを防ぎます。
業務部門の曖昧な要求を要件に翻訳する
要件定義のもう一つの難所が、業務部門から上がってくる曖昧な要求を、具体的な要件に翻訳する作業です。マーケティング部門や運営部門は「サイトが速くなってほしい」「セールで落ちないようにしてほしい」「商品をすぐ更新できるようにしてほしい」といった、感覚的な要望を出してきます。これらをそのままRFPに書いても、ベンダーは何をすればよいか分かりません。「速くなってほしい」は「応答3秒以内の達成率93%」に、「落ちないでほしい」は「セール時の想定アクセス数と稼働率目標」に、というように、測定可能な要件へ翻訳します。
この翻訳作業には、業務部門と情報システム部門（あるいは委託先候補）の対話が欠かせません。業務部門が「何に困っているか」「どの場面で売上を失っているか」を引き出し、それを技術的な要件に変換していきます。曖昧な要求のまま放置すると、リリース後に「思っていたのと違う」というギャップが生まれ、追加費用や再委託につながります。RFP作成自体を外部のITコンサルに委託するという選択肢もあり、自社に要件定義の知見が乏しい場合は、この翻訳工程を専門家に支援してもらうのも現実的な進め方です。曖昧な要求を測れる要件に変えることが、運用保守の品質を決める土台になります。EC運用保守がどんな機能で構成されるかは『ECサイト運用保守の必要機能・標準機能の一覧について』もあわせてご覧ください。
引き継ぎプロセスと契約形態の要件化
既存のサイトを別のベンダーに引き継ぐ場合、要件定義で必ず織り込むべきなのが引き継ぎプロセスです。運用保守の乗り換えでもっとも失敗が起きやすいのが、この引き継ぎ局面です。既存ベンダーが協力的でない、ドキュメントが整備されていない、キーマンが退職して仕様が分からない、といった事態が、引き継ぎを難航させます。これを見越して要件化しておくことが、移行の成否を分けます。
段階的な引き継ぎ（約8週間）を要件化する
運用保守の引き継ぎは、一気に切り替えるのではなく、段階的に進めるのが定石です。一般に、引き継ぎには約8週間（2か月）をかけ、委託先のPM0.25人月＋リードエンジニア1.0人月、現行担当が週2日関与する、といった体制が一つの目安になります。RFPでは、この引き継ぎ期間と体制を要件として明記し、現行仕様の調査、ドキュメント整備、並行稼働、完全移行という段階を設計します。引き継ぎを軽視して「すぐに切り替えられる」と安請け合いするベンダーには注意が必要です。
ベンダー選定は、契約満了の6か月前には着手するのが望ましく、選定プロセス全体で4〜6か月を見込みます。引き継ぎ期間を確保するには、この逆算が欠かせません。また、既存ベンダーをあえてRFPに参加させ、条件を見直して契約を継続する選択も30〜40%の割合で見られます。乗り換えありきではなく、既存ベンダーとの条件交渉も含めて検討するのが現実的です。いずれにせよ、引き継ぎプロセスを要件として明文化し、十分な期間を確保することが、運用が止まる事態を防ぎます。引き継ぎ失敗のリアルな事例は『ECサイト運用保守開発・導入の失敗・課題・注意点・リスクについて』もあわせてご覧ください。
準委任/請負と費用方式を要件化する
運用保守の契約形態には、準委任契約と請負契約があり、それぞれ責任の重さが異なります。準委任は「善管注意義務をもって業務を遂行する」もので、結果（成果物の完成）までは保証しません。請負は成果物の完成責任を負います。運用保守は継続的な業務であるため準委任が中心になりますが、特定の改修や移行作業は請負にする、といった使い分けを要件で整理します。契約書には、対象範囲・含まれない業務・免責事項を明記することが、後のトラブルを避ける鍵です。
費用方式も要件で定めます。月額定額と従量（T&M：実作業時間に応じた課金）のどちらにするか、SLA未達時のペナルティをどう設定するか、解約時の精算（稼働月数割りなど）はどうするか、を取り決めます。また、OSSの保守やデータ復旧といった想定外費用が発生し得る領域についても、誰が負担するかを事前に定義しておくと安心です。費用と契約形態を曖昧にしたまま委託すると、「これは契約外で追加費用」というやり取りが頻発します。RFPの段階で費用方式・ペナルティ・解約条件まで要件化することが、健全な委託関係の土台になります。
まとめ
ECサイト運用保守のRFP・要件定義書・提案依頼書は、機能の列挙からではなく、SLA（稼働率99.8%以上、障害通知30分以内、復旧6時間以内など）を中核に据えることから始めるのが鉄則です。そのうえで、クラウドの責任共有モデルを前提に責任範囲を明確化し、業務部門の曖昧な要求を測定可能な要件に翻訳し、RTO/RPOやEC固有のリスクを織り込む。さらに、約8週間の段階的な引き継ぎプロセスと、準委任/請負・費用方式・ペナルティ・解約条件を要件化します。評価では価格配点を20点以下に抑え、品質と体制で選ぶことが、安さだけで失敗するリスクを避ける鍵です。
運用保守は形のないサービスだからこそ、要件定義の質がそのまま委託の成否に直結します。SLAという数値で品質を定義し、責任分界を文書化し、引き継ぎまで設計した要件こそが、安定して売れ続けるECサイトを支えます。riplaはフルスクラッチ受託と国内運用保守を組み合わせ、SLAを中核に据えた要件整理から、責任共有モデルの整理、引き継ぎ計画、評価軸の設計までを発注企業と協働で支援します。全体像の確認には、あらためて完全ガイドをご活用ください。
株式会社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を創業。