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