マッチングサイトの刷新は、アセスメント、要件定義、RFPの順に進めます。仕様書の紛失や長年の改修で、コードがブラックボックス化したシステムも珍しくありません。
そうした状態で刷新すると、移行後に不具合が多発し、コストと期間が当初見込みの数倍に膨らむおそれがあります。経済産業省が指摘する「2025年の崖」では、レガシー放置により年間最大12兆円の経済損失が試算されており、マッチングプラットフォームも影響圏にあります。全体像はマッチングサイトのモダナイゼーションの完全ガイドもご覧ください。
▼全体ガイドの記事
・マッチングサイトのモダナイゼーションの完全ガイド
レガシーシステム刷新の種類・工程・費用・会社選定までの全体像については、無料ホワイトペーパー「レガシーシステム刷新の完全ガイドブック」で詳しく解説しています。
アセスメント：現行マッチングサイトのAS-IS可視化
アセスメントは、プロジェクトのリスクを事前に洗い出す重要な投資です。現行サイトのありのままの姿（AS-IS）を客観的に描き出し、担当者の頭の中の暗黙知を文書に起こします。
この工程を軽視すると、要件定義やRFPの策定で根拠のない仮定が増え、発注側とベンダーの認識がずれかねません。刷新後の設計判断に必要な情報も、ここで整理しておきます。
資産棚卸しと依存関係の把握
まず、現行システムの構成要素を網羅的に洗い出す資産棚卸しを行います。マッチングサイトは複数のサブシステムが密結合していることが多いため、依存関係の把握が欠かせません。
- 主な資産：会員管理DB、検索エンジン、推薦ロジック、決済モジュール、メッセージング基盤
- 依存関係：各モジュール間のデータフローや呼び出し関係
- ブラックボックス：仕様やコードの把握が難しい領域
依存関係を図に描いておくと、ひとつのモジュールを変えたときの影響範囲を特定できます。富士通の「ソフトウェア地図」のようなツールは、アプリ資産の複雑度や依存関係を自動で分析し、人手では見落としやすいコードレベルの依存も可視化できます（出典：富士通）。
開発者が全員退職し、ドキュメントもない状態では、移行後の挙動を読めず、トラブルにつながります。そのため、ブラックボックス化が深刻な領域では、リバースエンジニアリングやコードリーディングで暫定仕様書を作ります。
トラフィック特性・ピーク負荷・データ量の分析
マッチングサイトは、ユーザーの行動に応じてトラフィックが偏るという固有の特性を持ちます。そこで、過去のログから時間帯やイベントごとの負荷を把握します。数値が曖昧なままでは、性能要件（SLO/SLA）を適切に設定できません。
- 負荷の変動：朝夕のログイン、月末月初の契約更新、イベント時のアクセス増
- 収集する数値：検索・推薦クエリ数、DB接続数のピーク値、1ユーザーあたりの平均セッション時間
- データ量：会員数、マッチング履歴、メッセージ件数、添付ファイル容量
データ量は、過去数年の成長率をもとに移行時点の予測値も算出します。データ量が増えるほど移行時間が延び、サービス停止ウィンドウの設計が制約されます。また、アセスメントで数値を確定しておくと、要件定義でダウンタイムの許容値を現実的な根拠に基づいて設定できます。
リスクスコアリングとアセスメント報告書
棚卸しと分析が終わったら、発見事項をリスクとして評価します。各モジュールの技術的負債、移行の難しさ、ビジネスへの影響度を、3段階などで採点します。
- 現行構成図：アーキテクチャダイアグラム
- 依存関係マップ：モジュールのデータフローと呼び出し関係
- リスクマトリクス：刷新の優先領域を整理した評価結果
- データ量サマリ：現状のデータ量と移行計画に関わる情報
リスク評価は、要件定義の優先事項やRFPの要求事項を決める根拠になります。報告書は上記4点をまとめて作成するのが一般的です。
アセスメントと要件定義だけで200万円から500万円の費用が発生することが多いため、発注側が発注前に予算の目線を合わせておきます。
要件定義：KPI・性能・移行・非機能要件の体系化
アセスメントで現状把握が終わったら、要件定義に進みます。刷新後にめざす姿を描き、マッチング精度、同時接続性能、推薦レスポンスタイムなどの要件を明確にします。
要件が曖昧だと、スペックを満たしていても体感が遅い、またはマッチング精度が下がるといった問題が起こりえます。そのため、社内関係者とベンダーが合意できる数値とロジックで要件を書きます。
刷新後KPIと性能要件の数値化
マッチングサイトでは、次のような主要KPIを検討します。アセスメントで把握した現状値を基準に目標を決めておくと、受け入れテストでの判定も明確になります。
- マッチング成立率：月間マッチング数をアクティブユーザー数で割った値
- 検索レスポンス：例として95パーセンタイルで500ms以内
- 推薦精度：クリック率、お気に入り登録率、成約率など
- 同時接続数：ピーク時に想定する許容上限
- 可用性：例として99.9%以上
目標を「現状比○○%改善」と設定する方法もあります。性能要件には、平均値だけでなく、パーセンタイル値（P95・P99）とピーク時のスループット（RPS：リクエスト毎秒）も記載します。
平均レスポンスタイムだけを見ると、通常時は快適でも、ピーク時に停止する問題を見逃すおそれがあります。特定の時間帯やイベント時に負荷が急増するため、他のシステム以上にピーク耐性を要件に盛り込みます。
移行要件とダウンタイム設計
ユーザーが継続してサービスを使うため、一斉に移行する方式（ビッグバン型）は大きなリスクを伴います。そこで、ストラングラーパターンを中心とした段階移行が推奨されます。
段階移行では、どこまで切り替えたかが曖昧だと、問題が起きたときに元へ戻せなくなるおそれがあります。そのため、移行要件では切り替え範囲、判断条件、戻し方を明記します。
- 切り替え範囲：新規登録や検索など、段階移行する機能
- 判断基準：次の範囲へ展開するGo/No-Goの条件
- 復旧方法：問題発生時のロールバック手順
ダウンタイム要件は、アセスメントで把握したデータ量に連動させます。深夜メンテナンス枠を4時間以内とする場合は、業務・マーケティング部門と合意して記載します。
並行運用中の二重書き込みや差分同期の方式も明文化します。過去のメッセージやマッチング履歴が損なわれるとユーザー体験に影響するため、移行後の完全性確認手順を要件段階で定めます。
非機能要件：セキュリティ・拡張性・監査対応
個人情報、決済情報、プロフィール写真を扱うため、セキュリティ要件は厳密に書きます。個人情報保護法やGDPRへの対応が必要な場合は、準拠要件も含めます。
- データ保護：TLS1.3以上の通信暗号化、保存データの暗号化、個人情報のマスキング
- 監視と診断：ログ保持期間、不正アクセス検知（IDS/WAF）、脆弱性診断の頻度
- 拡張性：利用者増加に応じた水平スケーリングとGPU追加の考慮
- 監査：操作・アクセスログの取得、保存期間、外部出力の可否
マッチングロジックや推薦エンジンはCPU負荷が高くなります。そのため、将来的なAI活用を想定する場合は、GPUリソースを追加できる設計も考慮します。
ログの要件を整理しておくと、将来の法的対応やトラブルシューティングに備えられます。
RFP策定：盛り込むべき項目とベンダー評価の客観的基準
要件定義の内容は、ベンダーへの依頼文書であるRFP（Request for Proposal：提案依頼書）にまとめます。定量的な要件を書いておくと、各社の提案が同じ前提で比べやすくなります。
マッチングサイトのモダナイゼーションRFPに特有の記載項目と、評価時のチェックポイントを整理します。評価の基準を事前に決めておくと、公平な比較につながります。
RFPに盛り込むべき必須項目
マッチングサイトのモダナイゼーションRFPには、次の項目を体系的に記載します。
- 背景・機能範囲：現行課題と目標、刷新対象モジュールの範囲・優先度
- 構成・性能要件：資産棚卸しの構成図、同時接続数、検索P95、推薦精度、可用性（SLA）
- 移行・非機能要件：移行方式、停止時間上限、データ整合性、セキュリティ、拡張性、監査基準
- 日程・予算：フェーズとマイルストーンの期限、任意の想定総予算や月次コスト上限
- 成果物一覧：設計書、テスト結果、引き渡しドキュメントなど、納品物の種類と形式
現行構成図や性能要件が不十分だと、ベンダーは独自の前提で提案するため、提案内容にばらつきが出ます。そこで、アセスメントの成果をRFPに反映します。
提案書の章立てや記載様式を指定すると、回答の形式がそろい、評価時の比較が容易になります。
ベンダー評価の5つのチェックポイント
マッチングサイトのモダナイゼーションでは、次の5点を評価軸にします。複数社の回答を受け取る前に、評価の基準を決めておきます。
- 同業界・同規模の実績：マッチングや会員制プラットフォームの刷新経験
- 段階移行の設計力：ストラングラーパターンなどの提案力
- 停止時間の見積り：データ量に基づく算定と根拠の提示
- 保守・運用体制：24時間365日の障害・問い合わせ対応
- 品質・セキュリティ認証：ISO9001/ISO27001等の取得状況と情報管理体制
評価観点をRFPに書いておくと、ベンダーは提案書に必要な情報を盛り込めるようになります。各観点を5段階などで採点する評価シートも、事前に用意します。
点数化すると、選定判断が属人的になりにくく、決定の過程を後から説明できます。また、単価だけでなく、移行リスクを分担できる相手かどうかも評価します。
RFP策定でよくある落とし穴と対処法
RFPでは、要件を数値で書くことと、対象範囲をはっきりさせることが欠かせません。言い回しがあいまいだったり、範囲の境界が定まらなかったりすると、提案や見積りに差が出ます。
- 定性的な要件を数値化：「性能改善」「セキュリティ強化」などを測定可能な基準にする
- 範囲と機密情報を明確化：対象・対象外を定義し、機密情報の開示条件を決める
たとえば、検索クエリのP95を500ms以内とし、同時接続1万ユーザー時に可用性99.9%以上を維持すると記載します。数値があれば、提案を同じ物差しで比べられます。
「現行機能の移行」とだけ書くと、推薦エンジンの刷新を含むかどうかが各社で分かれ、見積りに差が出ます。そのため、対象範囲（スコープイン）と対象外（スコープアウト）の定義表をRFPに添付します。また、現行構成図などの機微な情報は、機密保持契約（NDA）を締結してから共有します。
まとめ
まず、アセスメントでは、資産を洗い出し、依存関係を図で示し、ブラックボックスを解消して、トラフィック特性を数値で把握します。現状分析が、刷新の土台になります。
次に、要件定義では、マッチング精度、同時接続性能、推薦レスポンスタイムを数値で定めます。ストラングラーパターンによる段階移行と非機能要件も体系化します。
RFPには、現行構成図と性能要件を反映します。そのうえで、実績、移行設計、ダウンタイム見積り、保守体制、認証を評価軸にすると、提案を公平に比べられます。
失敗の大きな原因は、アセスメント不足と要件定義の曖昧さです。だからこそ、3フェーズを順に進めて認識のずれを防ぎ、予算・期間・品質を合わせることが大切です。現状分析を起点に、データに基づく要件と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を創業。