マッチングサイトに必要な機能とは？MVPから大規模運営まで整理

マッチングサイトの機能一覧を作ると、会員登録、プロフィール、検索、チャット、決済、管理画面……ときれいに並びます。ここまでは簡単です。難しいのは、その機能を『いつ使えるか』。

たとえば問い合わせボタン。ログインしていれば誰でも押せるのか、本人確認済みだけなのか、自分の掲載には押せないようにするのか、取引終了済みならどうするのか。ボタンひとつでもルールは複数あります。

だから必要機能は、画面名ではなく利用者の流れに沿って決めます。登録した人が、探して、相手に接触し、確認を通り、やり取りし、取引を終える。その一本道を書いてから機能を当てはめる方が、抜けが減ります。

掲載型のマッチングサービスなら、最初に必要になりやすいのは次の7つです。全部を高機能にする必要はありません。ただ、登録から問い合わせまで一度通せること。運営側がその状態を確認できること。この2点は残します。

MVPでありがちな失敗は、重要な安全機能まで削ってしまうことです。代わりに考えたいのが、自動化を後回しにできる処理。利用者が少ないうちは、審査結果の通知や成約確認を運営が手で行える場合があります。

一方、会員ごとの権限や公開・非公開の分離は、あとから継ぎ足すほど危険になります。最初は人が処理してもよいものと、データ構造として最初から必要なもの。この2つを分けると、MVPの削り方が変わります。

サイト内メッセージを作ると、ついUIへ目が行きます。でも本番で問題になるのは、送れる・送れないの境界です。

無料不動産では、問い合わせ直後から無条件に会話を開くのではなく、必要な確認が終わってからやり取り可能にする設計を採りました。取引終了後も即削除ではなく、一定期間は既存のやり取りを残す。こうすると、終了した案件への新規問い合わせを止めながら、当事者には必要な履歴を残せます。

既読、添付、通報も大切ですが、その前に開始条件と終了条件。ここを決めると、チャットの仕様が一気に具体的になります。

登録直後に身分証を求めれば、確認済み会員だけにできます。ただ、まだサービスを理解していない人へ書類提出を求めるため、離脱も増えやすい。安全性だけでなく、確認するタイミングがUXになります。

出品前、購入申請前、問い合わせ前、メッセージ開始前。リスクが高くなる直前に確認を挟む設計もあります。無料不動産では、売り手と買い手で必要なタイミングを分けています。誰に同じルールを当てるかではなく、どの行為にリスクがあるかから決める方が自然です。

料金モデルが変われば、決済の設計も変わります。月額会員なのか、掲載時に課金するのか、成約時に手数料を取るのか。誰から、いつ、何を根拠に請求するかが先です。

成約課金なら、『成約した』状態を誰が確定するかが必要です。月額なら支払い失敗時に権限をいつ止めるか。決済事業者の画面だけでは解決しません。サイト側の会員・取引状態と連動させます。

掲載情報に『公開／非公開』しかないと、運営が始まってから困ります。下書き、審査待ち、公開、停止、取引完了。問い合わせなら、確認待ち、やり取り可能、終了。状態を分けると、各画面の振る舞いを説明できます。

逆に状態が曖昧だと、『公開ページから消えたら既存チャットへどう戻る？』『審査中の編集は許可する？』といった問題が、画面を作った後に出てきます。私たちも実働テストでこうした導線の不足を見つけ、UIへ戻して修正しました。紙の仕様書だけでは見つからない部分です。

公開初期は利用者が少ないため、『DBを直接見れば管理できる』と思いがちです。数件なら確かにできます。ところが、審査待ちを探し、誰が承認し、差し戻し理由を記録し、問い合わせ状況を追うようになると、手作業が一気に増えます。

豪華なダッシュボードはいりません。最初から必要なのは、誰が・何を・どの状態で使っているかを一覧で見られること。停止・承認・差し戻しなど、日常運営の操作ができること。この程度でも、公開後の負担はかなり変わります。

規模が大きくなると、管理者自身にも権限が必要になります。審査担当と請求担当で見える情報を変える。誰がどの操作をしたか記録する。期限になった案件を自動で閉じる。通知を自動化する。

これらは必要になった時点で追加できることが多い機能です。ただし、あとから追加する予定が見えているなら、操作履歴や状態IDを持てるように初期設計へ余白を残します。

本人確認、通報、ブロック、レート制限、掲載審査、監査ログ。不正対策はいくらでも増やせます。予算が有限なら、サービスで最も困る事故から考えます。

高額取引なら本人確認や取引履歴。メッセージ型なら通報・利用停止。投稿型なら掲載審査。守るべき対象を決めると、安全機能の優先順位も決めやすくなります。

『売り手が登録する→掲載する→運営が確認する→公開される→買い手が検索する→問い合わせる→必要な確認をする→会話する→取引を終える』。まず、このくらいで構いません。

この一本の流れがあると、機能の理由が見えます。本人確認はどこに入るのか。公開前に審査するのか。終了後に何を残すのか。機能名を横に並べるより、はるかに仕様へつながりやすい方法です。

マッチングサイトに絶対必要な機能セットはありません。同じチャットでも開始条件が違い、同じ本人確認でもタイミングが違います。

私たちは、最初に会員種別、権限、状態、運営作業を整理し、そこから画面へ落とします。きれいな機能一覧を先に作るより少し遠回りに見えますが、公開後に『このケースはどうする？』が減る。結果的には、その方が速いと考えています。