マッチングサイトの運用保守を外部に委託するうえで、その成否をもっとも大きく左右するのが要件定義であり、それをまとめたRFP（提案依頼書）の質です。とくにマッチングサイトの運用保守は、一般的なサーバー監視やバックアップに加えて、サクラ・不正会員の監視、会員からの通報対応、マッチングロジックの改善、二面市場の需給運用といった固有の業務を含むため、これらをいかに正確に運用要件として整理し、RFPや運用保守の要件定義書に落とし込めるかが、契約後のトラブルを防げるか、責任のなすり合いに陥るかの分かれ目になります。委託範囲が曖昧なまま契約すると、セキュリティ事故が起きたときに「それはこちらの責任ではない」という責任分界の押し付け合いが発生しかねません。
本記事は、マッチングサイト運用保守のRFP・要件定義書・提案依頼書を、運営企業の視点から具体的に解説する「要件定義特化」の記事です。クラウド・SaaSの責任共有モデルを前提にした運用要件の整理、サクラ・不正監視や通報対応といった曖昧な要求を運用要件に翻訳する方法、SLAの設定、準委任と請負の契約形態の選択、価格偏重を避ける評価軸、そして安全な引き継ぎプロセスまで、運用保守の実務に即して掘り下げます。読み終えるころには、運用保守ベンダーに渡すRFPの骨子が描けるはずです。なお、全体像をまだ把握していない方は、まずマッチングサイト運用保守の完全ガイドから読むことをおすすめします。
責任共有モデルと業務範囲の明確化から始める
マッチングサイト運用保守の要件定義は、「どんな監視ツールが欲しいか」といった手段の話から始めてはいけません。出発点は、運用と保守の業務範囲を明確に定義し、とくにクラウド・SaaSを使う場合の責任分界点をはっきりさせることです。マッチングサイトはクラウド上で運用されることが多く、インフラ・ミドルウェア・アプリケーション・データといった層ごとに、誰が責任を持つかが変わります。これを曖昧にすると、障害やセキュリティ事故の際に責任の押し付け合いが起きます。
クラウド責任共有モデルで分界点を定義する
クラウドの責任共有モデルとは、クラウド事業者と利用者（運営者・運用保守ベンダー）の間で、セキュリティや運用の責任を層ごとに分担する考え方です。物理インフラやネットワークはクラウド事業者の責任、その上のOS・ミドルウェア・アプリケーション・データの設定や管理は利用者側の責任、というように分かれます。マッチングサイトの運用保守をベンダーに委託する場合、この利用者側の責任のうち、どの層をベンダーに任せ、どの層を自社で持つかを、要件定義の段階で明確に定義する必要があります。
この責任分界点の定義を怠ると、最悪の事態を招きます。会員の個人情報が漏洩するようなセキュリティ事故が起きたとき、「アプリの脆弱性は開発時の問題」「設定ミスは運用ベンダーの責任」「いや自社の指示が曖昧だった」と責任のなすり合いになり、最悪は訴訟に発展します。マッチングサイトは会員の個人情報や機微なやり取りを扱うため、セキュリティ事故の責任分界は特に慎重に定義すべきです。誰が、どの層の、どんなセキュリティ対策に責任を持つかを契約前に文書化することが、後の紛争を防ぐ最大の防衛策です。
「含まれない業務」を明記して免責を整理する
業務範囲を定義するときは、「含まれる業務」だけでなく「含まれない業務」を明記することが極めて重要です。運用保守の契約トラブルの多くは、「これもやってくれると思っていた」という認識のズレから生じます。たとえば、OSS（オープンソースソフトウェア）のバージョンアップ対応、大規模なデータ復旧、外部サービス障害への対応、新機能の開発などは、標準の運用保守に含まれるのか別料金なのかを、要件定義の段階で明確にしておく必要があります。
あわせて、免責事項も整理します。たとえば、クラウド事業者側の大規模障害や、自社が指示した変更に起因する不具合、第三者の不正アクセスのうち想定を超えるものなど、ベンダーが責任を負わない範囲を明記します。これは責任逃れのためではなく、双方の責任範囲を明確にして無用な紛争を防ぐためです。OSS保守やデータ復旧といった想定外費用が後から発生するのを避けるためにも、「含まれない業務」と「免責」を要件定義書とRFPに明記することが、運用保守の健全な委託関係の土台になります。
マッチング固有の運用を要件に翻訳する方法
責任分界と業務範囲を整理したら、いよいよマッチング固有の運用を具体的な運用要件に落とし込みます。ここがマッチングサイト運用保守の要件定義でもっとも難しく、かつ最重要の工程です。サクラ・不正監視、通報対応、マッチングロジック改善、需給運用といった固有業務は、「健全に保ってほしい」「ちゃんと対応してほしい」という曖昧な要求になりがちで、これを具体化しないとベンダーは見積もりも対応もできません。
曖昧な要求を頻度・基準・時間で具体化する
マッチング固有の運用要件を具体化するには、「何を、どの頻度で、どの基準で、どれだけの時間内に対応するか」を言語化します。たとえばサクラ・不正監視なら、「新規登録は登録後何時間以内に審査するか」「どんなパターンを不正と判定する基準にするか」「不正会員の利用停止は誰が、どの権限で行うか」を定義します。通報対応なら、「通報の一次受付までの目標時間」「緊急度の判定基準」「最終対応（警告・停止・退会）までの目標時間」を決めます。これにより、曖昧な「健全に保つ」が、運用可能な要件に変わります。
業務部門の曖昧な要求を運用要件に翻訳するのは、簡単ではありません。「悪い会員をなくしてほしい」という現場の願いを、「同一IPからの一定数以上の登録を検知し目視審査に回す」といった実装・運用可能な要件に落とし込むには、マッチングサイトの運用を理解した知見が要ります。この翻訳作業を運用保守ベンダーと協働で進めることも有効ですが、自社のサービスで何を「健全」とするかの基準は、運営者自身が主体的に定義すべきです。固有運用の具体化が、現場で本当に機能する運用保守の土台になります。これらの運用がどんな機能・役割で実現されるかは、関連記事もあわせてご覧ください。
SLAとRTO/RPOの要件化
運用要件を具体化したら、それをSLA（サービス品質保証）として数値化します。SLAは、稼働率や障害対応時間、そしてマッチング固有の通報対応時間などを数値で約束する仕組みです。大阪市のガイドラインでは、稼働率99.8%以上、応答3秒以内の達成率93%、障害通知30分以内100%、重大障害は年2回以内、復旧6時間以内・4時間以内の遵守率95%、問い合わせ解決95%（24時間以内）といった水準が示されています（出典：大阪市）。これらを参考に、自社のサービスに合ったSLA水準を要件として設定します。
SLAには、努力目標型（達成を目指すが未達でもペナルティなし）と目標保証型（未達時にペナルティ）があります。最初から厳しい目標保証型を求めると見積もりが跳ね上がるため、まずは努力目標型で運用を安定させ、段階的に保証型へ引き上げる進め方が現実的です。また、クラウド・SaaSを使う場合は、障害からの復旧目標であるRTO（目標復旧時間）と、どの時点まで戻せるかを示すRPO（目標復旧時点）も要件化します。SLAとRTO/RPOを要件に明記することで、運用保守の品質を契約レベルで担保できます。
契約形態（準委任/請負）の選択と法務リスク
運用要件とSLAが固まったら、それをどんな契約形態で結ぶかを決めます。運用保守の契約は、大きく準委任契約と請負契約に分かれ、どちらを選ぶかによって責任の所在や法務リスクが変わります。マッチングサイトの運用保守は、定常的な監視・対応業務と、改修という成果物を伴う業務が混在するため、契約形態の選択を要件定義の段階で検討しておくことが重要です。
準委任と請負の違いと使い分け
準委任契約は、業務の遂行そのものを委託する契約で、成果物の完成責任を負わない代わりに、善管注意義務をもって業務にあたることが求められます。監視・障害対応・通報対応・サクラ監視といった、継続的に「対応し続ける」運用業務は、準委任契約が適しています。一方、請負契約は成果物の完成を約束する契約で、特定の機能改修やロジックの作り直しといった、明確な成果物を伴う業務に向いています。完成責任を負うぶん、瑕疵があれば修補の義務が生じます。
マッチングサイトの運用保守では、定常的な運用は準委任、まとまった改修は請負、というように業務の性質に応じて使い分けるのが現実的です。重要なのは、どちらの契約でも、対象範囲・含まれない業務・免責を明記することです。契約形態だけでなく、月額定額にするか従量（T&M：実働時間に応じた精算）にするかという費用方式、解約時の精算ルール（稼働月数に応じた割り戻しなど）、ハードウェア交換後の故障部品の所有権といった細部も、契約書で取り決めておく必要があります。契約形態と費用方式の選択が、法務リスクと費用の予見性を左右します。
セキュリティ事故時の責任と免責の取り決め
マッチングサイトでとくに慎重に取り決めるべきが、セキュリティ事故時の責任です。会員の個人情報漏洩やアカウント乗っ取りといった事故が起きたとき、誰がどこまで責任を負うのかを契約で明確にしておかないと、責任のなすり合いや訴訟に発展します。前述の責任共有モデルに基づき、「ベンダーが責任を持つセキュリティ対策の範囲」「自社が責任を持つ範囲」「想定を超える攻撃に対する免責」を、契約書に具体的に記述します。
あわせて、JIS Q 20000（ITサービスマネジメントの国際規格）といった標準を参照し、運用保守の品質基準を契約に組み込むことも有効です。標準に準拠した運用を求めることで、属人的でない一定品質のサービスを担保できます。法務リスクを抑える要件定義のポイントは、「曖昧にしない」ことに尽きます。責任分界、免責、契約形態、費用方式、解約条件をすべて明文化し、運用フェーズで起きうるトラブルを契約段階で先回りして整理することが、マッチングサイトの運用保守を安全に委託する鍵です。
RFPの評価軸と安全な引き継ぎプロセス
要件定義がまとまったら、それをRFP（提案依頼書）にして複数のベンダーに提案を依頼します。運用保守のRFPでは、ベンダーをどう評価するかの軸と、現行ベンダーからの引き継ぎプロセスが、特に重要なテーマになります。運用保守は長期にわたる継続的な関係であり、目先の安さで選ぶと後悔するため、評価軸の設計が成否を分けます。
価格配点を20点以下に抑える評価軸の設計
運用保守ベンダーの評価軸を設計するときの鉄則は、価格に偏重しないことです。一次データによれば、価格の配点は20点以下に抑えるのが望ましいとされています。運用保守は、安さだけで選ぶと品質が伴わず、結局はSLA未達や障害多発で高くつくからです。価格以外に、マッチング固有運用の理解度、SLAの達成体制、障害対応の実績、セキュリティ対応力、ドキュメント整備の姿勢、引き継ぎ計画の妥当性といった項目に配点を割り振り、総合的に評価します。
ベンダー選定は、契約満了の6か月前（全体で4〜6か月）から着手するのが望ましいとされています。十分な時間を取ることで、RFI（情報提供依頼）でベンダーの情報を集め、RFPで提案を求め、じっくり評価できます。なお、既存ベンダーをRFPに参加させて条件を見直し、結果として継続するケースも30〜40%あるとされ、必ずしも乗り換えが正解とは限りません。価格に偏らない評価軸で、品質と体制を冷静に見極めることが、運用保守ベンダー選定の要諦です。
8週間の段階引き継ぎを要件に組み込む
運用保守ベンダーを乗り換える場合、引き継ぎプロセスをRFPと契約に組み込むことが不可欠です。一次データによれば、引き継ぎは約8週間（2か月）かけて段階的に行うのが望ましく、体制の目安は委託先のPMが0.25人月、リードエンジニアが1.0人月、そして現行担当者が週2日程度サポートする形とされています。新ベンダーが既存システムのドキュメントとソースコードを読み解き、監視・障害対応・通報対応・サクラ監視のオペレーションを段階的に移管する計画を、要件として明示します。
引き継ぎで最大のリスクになるのが、既存ベンダーの非協力や、キーマンの突然の退職です。現行ベンダーが引き継ぎに協力してくれなかったり、システムを一人で抱えていた担当者が辞めてしまったりすると、運用ノウハウが断絶し、移行後に障害が多発します。これを防ぐには、現行契約に引き継ぎ協力義務やドキュメント提供義務を盛り込んでおくこと、そして日頃からドキュメントを整備してベンダーロックインを避けておくことが重要です。riplaはフルスクラッチ受託と国内運用保守の立場から、要件定義から引き継ぎ計画の策定、移行後の安定運用までを発注企業と協働で支援しています。安全な引き継ぎの設計は、運用保守の要件定義の総仕上げです。
まとめ
マッチングサイト運用保守の要件定義・RFP・提案依頼書は、まずクラウド責任共有モデルを前提に責任分界点を定義し、業務範囲と「含まれない業務」「免責」を明記することから始めます。そのうえで、サクラ・不正監視や通報対応といったマッチング固有運用の曖昧な要求を、頻度・基準・対応時間で具体化してSLA化し、契約形態（準委任/請負）と費用方式を使い分ける。これらをRFPに明記し、価格配点を20点以下に抑えて品質・体制・引き継ぎ計画を総合評価すれば、責任のなすり合いや想定外費用という運用保守特有のリスクを防げます。
ベンダー選定は契約満了6か月前から着手し、乗り換える場合は約8週間の段階引き継ぎを要件に組み込むことで、運用ノウハウの断絶を防げます。運用保守の質は、要件定義の精度がそのまま決めます。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を創業。