マッチングサイトのリニューアルのアセスメント/要件定義/RFPについて

マッチングサイトのリニューアルを検討している企業の多くが、「何から手をつければよいか分からない」という課題を抱えています。リニューアルの成否を分けるのは、設計や開発の段階ではなく、その手前にあるアセスメント（現状分析）・要件定義・RFP（提案依頼書）の精度です。現状の課題を正しく言語化せずに進めると、要件が肥大化したまま発注することになり、想定外の追加費用や開発後の手戻りを招きます。本記事では、マッチングサイトのリニューアルを外部ベンダーへ発注する際に必要な、アセスメントから要件定義、RFP作成までの流れと、各フェーズで押さえるべき具体的な項目を実務目線で整理します。

本記事はアセスメント・要件定義・RFPの「作り方」に特化した内容です。マッチングサイトのリニューアル全体の流れや、進め方の前提知識をまだ押さえていない場合は、先に マッチングサイトのリニューアルの完全ガイド を読んでおくと、本記事で扱う要件定義の各項目がより立体的に理解できます。ここから先は、リニューアル担当者・PM・情報システム部門の方が、ベンダーへ渡すドキュメントを実際に作成する場面を想定して解説します。

▼全体ガイドの記事
・マッチングサイトのリニューアルの完全ガイド

アセスメント：既存マッチングサイトの現状分析と課題の言語化

アセスメントとは、リニューアルの要件定義を始める前に行う「現状の課題棚卸し」のプロセスです。既存のマッチングサイトがどのような問題を抱えているかを定量・定性の両面で把握し、「なぜリニューアルが必要なのか（Why）」を言語化することがゴールです。アセスメントをしっかり行うことで、要件定義の目的がぶれなくなり、ベンダーへの説明精度が大幅に上がります。アセスメントを省略すると、担当者の主観的な要望が要件に混入し、本当に解決すべき課題とは無関係な機能追加が発生しやすくなります。

アセスメントの出発点は、現状のKPI（重要業績評価指標）の実態把握です。マッチングサイトにおける主要なKPIとしては、新規会員登録数・月間アクティブユーザー数・マッチング成立率・成約率・平均セッション時間・モバイル離脱率などが挙げられます。これらを月次・週次で計測し、目標値との乖離がどこで生じているかを特定します。

たとえば検索機能の問題が顕在化しているケースでは、「検索後に絞り込み結果を見たユーザーの離脱率が高い」「検索条件が多すぎて操作を途中で諦めるユーザーが多い」といったデータが見えてきます。成約率が低い場合は、マッチング成立後のメッセージ機能や安心・安全の仕組み（KYC・本人確認）に問題があるケースが多いです。モバイル離脱が多い場合は、UIのレスポンシブ対応やページ表示速度が主因になっていることがほとんどです。

こうした課題を感覚ではなく数値として記録しておくことが、要件定義での優先順位付けと、RFPでの「現状課題の説明」に直結します。アナリティクスツール（GA4など）とCRMデータを組み合わせ、課題の深刻度をスコア化しておくと、ベンダーへの説明が具体的になります。

KPIの課題と並行して整理すべきなのが、技術的負債と外部連携の状況です。技術的負債とは、開発速度を優先した結果として蓄積された設計や実装上の問題のことで、リニューアルの際に大きな制約となります。具体的には、フレームワークやライブラリのバージョン陳腐化、テストコードの不足、モノリシックなアーキテクチャ、デプロイの自動化未整備などが典型例です。

外部連携の整理も重要です。既存システムが決済サービス・SNSログイン・メール配信・本人確認APIなどと連携している場合、それらをリニューアル後も引き継ぐのか、別サービスへ切り替えるのかを事前に整理しておきます。連携先の仕様変更や廃止予定がないかも確認が必要です。外部連携の棚卸しを怠ると、要件定義の段階で連携仕様が固まらず、開発中に大幅な手戻りが発生します。

アセスメントの最終成果物として、「KGI（重要目標達成指標）の設定」を行います。リニューアル後に何を達成すれば成功と言えるのかを、経営目標と連動した形で数値で定義します。たとえば「リニューアル後12か月で成約率を現状比30%向上」「モバイル離脱率を15ポイント改善」といった具体的な数値目標がKGIに当たります。KGIが定まっていないと、要件定義でも「あれもこれも必要」という要件肥大化が起きやすくなります。

要件定義：機能要件・非機能要件とMust/Wantの仕分け

要件定義は、アセスメントで把握した課題を「システムで解決すべき要件」として整理するプロセスです。要件定義書では機能要件と非機能要件を明確に分け、それぞれを「Must（必須）」と「Want（あれば望ましい）」に仕分けします。この仕分けを怠ると、要件が際限なく肥大化し、スコープが広がりすぎて予算・納期の両方が破綻するリスクがあります。要件定義・ディレクション費用は総予算の10〜30%が相場ですが、ここを削ると開発中の手戻りでかえって高くつくケースが多いため、適切な工数を確保することが重要です。

マッチングサイトの機能要件は、一般的なWebサービスとは異なるマッチング固有の要件が多く含まれます。代表的なものとして、検索・絞り込み機能、推薦アルゴリズム（レコメンド）、メッセージ・チャット機能、課金・決済機能、KYC（本人確認）・年齢確認、評価・レビュー機能、通報・ブロック機能、管理画面（会員管理・案件管理）などが挙げられます。これらをKGIと紐づけながら、どの機能がリニューアルの目的に直結するのかを整理します。

Must/Wantの仕分けは、「この機能がなければKGIを達成できないか」という問いで判断するのが基本です。たとえば成約率改善が最優先のKGIであれば、マッチング成立後のメッセージ機能とKYCはMustになり、AIを使った高度なレコメンドエンジンの刷新はWantに分類できるケースが多いです。Wantに分類した機能は、フェーズ2以降の追加開発候補として別リストに保管し、今回の発注範囲から外します。

モバイル対応は、現代のマッチングサイトでは機能要件というより前提条件に近いですが、スマートフォンでのUX改善を要件として明示しておかないと、ベンダーがPC優先の設計を提案してくることがあります。「モバイルファースト設計を原則とし、iOS/Androidの主要ブラウザで動作確認を必須とする」といった記述を要件定義書に盛り込んでおきます。

非機能要件では、システムが「どの品質水準で動くか」を定義します。マッチングサイトでとくに重要なのは、セキュリティ・可用性・パフォーマンス・Webガバナンスの4領域です。セキュリティ要件では、会員の個人情報保護（氏名・住所・決済情報）に関するアクセス制御・暗号化・ログ保全の仕様を明記します。KYCで収集する本人確認書類の取り扱いや、外部API経由で送受信するデータの管理方針も必須記載事項です。

可用性については、サービス停止が許容できる最大時間（RTO：目標復旧時間）と、データ消失の許容範囲（RPO：目標復旧ポイント）を数値で定義します。マッチングサイトは24時間稼働が前提であることが多く、月次稼働率99.9%（停止時間月43分以内）といったSLA基準を要件として明記することで、ベンダーのインフラ設計が適切かどうかを提案段階で評価できます。

Webガバナンス要件として、コンテンツポリシーの運用・不正利用の検知・通報対応フローをシステム要件として整理しておくことも重要です。マッチングサイトでは成りすましや詐欺被害が社会問題になるケースがあり、「どのような通報ルートがあり、どのような対応フローで処理されるか」をシステム設計の要件として組み込む必要があります。これらを曖昧にすると、トラブル発生時に責任分界が不明確になります。

RFP（提案依頼書）の必須項目と記載のポイント

RFP（提案依頼書）は、複数のベンダーから比較可能な提案を引き出すための土台となる文書です。RFPが曖昧だと、各社の提案が見積前提から食い違い、横並びでの比較ができなくなります。マッチングサイトのリニューアルにおけるRFPには、最低限以下の項目を含める必要があります。内容が具体的であるほど、ベンダーは現実的なアーキテクチャと見積を提示しやすくなります。

マッチングサイトリニューアルのRFPに記載すべき必須項目は以下のとおりです。
・背景・目的：なぜリニューアルが必要か、どのKGIを達成したいか
・現状課題：アセスメントで洗い出した課題を定量データとともに記載
・対象範囲：今回のリニューアルで対応するスコープと、対象外の範囲の明記
・機能要件一覧：MustとWantに分類した機能のリスト（画面一覧・ユーザーストーリー形式が望ましい）
・非機能要件：セキュリティ・可用性・パフォーマンス・モバイル対応基準
・データ移行仕様：会員情報・取引履歴・マッチング履歴のデータ移行の範囲と方法
・予算・納期：希望する予算レンジと全体スケジュール
・評価基準・選定プロセス：提案を評価する観点と重み付け、選定フローの説明
・保守運用要件：リリース後の保守体制、バグ対応のSLA、機能追加時の対応方針

なかでも見落とされやすいのが「データ移行仕様」です。既存の会員情報・取引履歴・マッチング履歴を新システムへどのように移行するかは、開発工数と費用に大きく影響します。データ形式、件数、クレンジングの必要性、移行テスト方法などを事前に整理し、RFPに明記しておかないと、ベンダーが最小限の前提で見積を出し、後から大規模なデータ整備が追加費用として発生します。

RFPには提案フォーマットを指定することも有効です。費用内訳の粒度（初期開発費・インフラ費・保守費・オプション費を分けて記載させる）、回答してほしい質問項目をテンプレート化して渡すと、各社の提案を同じ軸で並べられます。比較可能性を確保することが、RFPを発行する最大の目的のひとつです。

ベンダー評価の観点は、提案を受け取る前にRFPへ明記しておくことが重要です。評価を後出しにすると、選定が属人的になり「なぜこのベンダーなのか」を社内で説明できなくなります。マッチングサイトのリニューアルにおける評価観点としては、マッチングサービスの開発実績・技術力・提案書の具体性・体制・セキュリティ対応・価格・保守サポートの7軸が代表的です。

各観点に重み付けを設定することで、定量的な採点が可能になります。たとえば「マッチングサービスの開発実績：25点、技術力・アーキテクチャ提案：25点、価格・費用対効果：20点、保守サポート体制：15点、セキュリティ対応：15点」のような配点を設けると、複数のステークホルダーが参加する選定会議でも客観的な議論ができます。重み付けは自社のプロジェクト特性に応じて調整してください。

選定プロセスとしては、RFP送付→提案書受領→プレゼン・質疑→評価・採点→優先交渉権付与という流れが一般的です。プレゼン時には、マッチングサイト特有の課題（成りすまし対策・KYC実装・課金フローの設計経験など）について具体的な対応実績を確認します。過去に類似案件でどのようなトラブルが発生し、どう対処したかを聞き出すことで、ベンダーの実力と誠実さの両方を見極めることができます。

アセスメント→要件→RFPを通した進め方の勘所

アセスメント・要件定義・RFPの3フェーズは、それぞれが独立したドキュメントではなく、一貫した論理でつながっている必要があります。アセスメントで「成約率が低い」という課題を特定したなら、要件定義でそれに対応する機能（メッセージ機能の改善、KYCの強化など）をMustとして定義し、RFPではその課題と要件をベンダーへ正確に伝える。この一貫性が崩れると、ベンダーは「なぜその機能が必要なのか」を理解しないまま提案を出すことになり、的外れな提案が増えます。

マッチングサイトのリニューアルで頻発するのが、「要件がどんどん膨らんで予算が2倍になった」という事態です。これを防ぐためのスコープ管理のポイントは、要件定義の段階でMust/Wantを徹底して仕分けし、Wantは「フェーズ2以降の追加候補リスト」として別管理することです。プロジェクト開始後に「やっぱりこれも必要だ」という声が出たときに、候補リストを参照して追加可否をコスト見積とともに判断する流れを作ることで、スコープの無秩序な拡大を抑制できます。