マッチングサイトの作り方｜開発前に決める10項目と段階設計

マッチングサイトを作ろうとすると、最初に欲しくなるのはトップページ、検索画面、会員登録、チャットです。目に見えるので話もしやすい。ただ、実際に無料不動産を作ってみると、そこで先に決めるべきだったのは画面ではありませんでした。

たとえば『問い合わせ』。買い手はログインしていれば押せるのか。本人確認が終わっていなければ、その場で止めるのか。問い合わせ自体は作っておいて、確認後に会話だけ開くのか。出品者側にも確認が必要なら、どちらが終わった時点でチャットをOPENにするのか。

この答えが決まらないままチャット画面を先に作ると、あとで条件分岐を足すことになります。そこで私たちは、画面を増やす前に『誰が・何の状態なら・次に何ができるか』を表にしました。マッチングサイトは、ここから始める方が結果的に早いです。

最初から詳細な仕様書を作る必要はありません。次の10項目を一行ずつ書くだけでも、開発の輪郭はかなり見えます。分からない項目は『未定』で構いません。未定だと分かること自体が大切です。

売り手と買い手がいる。ここまでは簡単です。でも両者が同じアカウントで立場を切り替えられるのか、売り手専用・買い手専用に分けるのかで、データの持ち方は変わります。法人と個人が混ざれば、さらに組織という単位も必要になるかもしれません。

無料不動産では、同じサービス内で出品側と問い合わせ側の役割を扱います。一方、本人確認のタイミングは同じではありません。役割が同じDBに入ることと、同じルールで動かすことは別です。

会員種別を決めるときは、名前だけではなく『この人は何を見られるか』『何を登録できるか』『誰と接触できるか』まで書きます。ここが権限設計の出発点です。

本人確認を最初に必須にすれば、確認済みの人だけがサービスへ入れます。ただし、まだ何ができるサイトか分からない段階で身分証を求めるため、登録のハードルは上がります。

そこで、出品前、購入申請前、問い合わせ前、メッセージ開始前といった節目に置く方法があります。無料不動産では、買い手はやり取りに進む前、売り手は出品時など、行為に合わせて確認を分けています。

『本人確認あり』だけでは仕様になりません。誰に、どの操作の前に、何を確認するか。この3つをセットで決めます。

問い合わせボタンを押した瞬間にチャットルームを開くサービスもあります。ただ、信頼確認が必要なサービスでは、問い合わせを受け付けることと、会話を許可することを分けた方が扱いやすい場合があります。

無料不動産では、問い合わせスレッドを先に作り、必要な確認が残っている間は『確認待ち』として扱います。条件が揃えばOPENになり、そこで初めてメッセージを送れる。取引が終われば新規の問い合わせは止めつつ、既存のやり取りには猶予期間を持たせます。

こうすると『問い合わせは届いたが、まだ会話はできない』という状態を正しく表現できます。チャット画面だけ作ってしまうと、この中間状態が置けません。

利用者向けの画面は目立つので、どうしても優先したくなります。ところが本番公開の日から毎日使うのは管理画面です。審査待ちを探す、承認する、差し戻す、ユーザーを停止する、問い合わせ状態を確認する。

利用者が10人ならDBを直接見ても何とかなるかもしれません。100人、1,000人になると続きません。最初から分析ダッシュボードまで作る必要はありませんが、日常運営に必要な操作だけは先に用意します。

目安は『公開後、運営担当者が毎日何をするか』。この質問に答えると、必要な管理画面が見えます。

初期段階では、審査や成約確認を人が行う方が合理的なことがあります。件数が少ないのに複雑な自動判定を作っても、そのルール自体が運営後に変わるかもしれないからです。

手作業を残すと、『このケースは想定していなかった』『ここは毎回同じ作業になる』が見えてきます。同じ処理が繰り返されるようになったら、そこで自動化する。利用者が増えるほど、この順番が効いてきます。

ただし、手作業でも履歴は残したいところです。誰が承認したのか、いつ状態が変わったのか。後から自動化するときにも、その記録が仕様書代わりになります。

新しいサービスなら、最初に何を確かめたいかを一つ決めます。たとえば『掲載者が集まり、検索した人から問い合わせが来るか』。これが答えなら、会員登録、掲載、検索、詳細、問い合わせ、最低限の管理で公開できます。

決済、レビュー、ランキング、高度な通知は後でもよいかもしれません。逆に、本人確認がないと信用されない事業なら、それは初期から必要です。MVPという言葉より、『この公開で何を確かめるか』と聞く方が分かりやすい。

何十個もの機能をExcelに並べる前に、主要な利用者が目的を達成するまでを一行で書きます。

『売り手が登録→掲載→審査→公開→買い手が検索→問い合わせ→確認→会話→取引終了』。これだけでも、必要な状態が見えます。売り手が途中で掲載を取り下げたら？ 買い手の確認が終わらなかったら？ 取引終了後の履歴は？ と、次の質問が自然に出てきます。

仕様を細かくするのは、その後で十分です。一本道を先に作ると、機能が増えても『何のための機能か』を見失いにくくなります。

マッチングサイトの設計で大切なのは、機能数を増やすことではありません。誰と誰をつなぎ、何を公開し、どこで信頼を確認し、どうやり取りし、どの時点で終了するか。この流れを矛盾なく通せることです。

実際にサービスを作ると、公開後に必ず新しいケースが見つかります。だから最初から完璧を狙うより、変更しにくい権限・状態・データの骨格を先に決め、画面や付加機能は段階的に増やす。私たちはこの順番を基本にしています。