マッチングサービスのMVPを作るには？最初に必要な機能だけを整理する

マッチングサービスの最初の壁は「集客」

マッチングサービスで最も難しいのは、機能を作ることよりも、両側の利用者を同時に集めることです。依頼する側がいなければ受ける側は登録せず、受ける側がいなければ依頼する側も集まりません。そのためMVPでは、「両側の機能を完璧に揃える」ことより、「どちらか一方を先に集め、取引が成立するかを確かめる」ことに集中するのが現実的です。

例：工務店と職人をつなぐサービス

考え方をつかむための例です（特定の企業の事例ではありません）。地域の工務店が、内装や設備工事の職人を探す手間を減らしたい、というアイデアがあるとします。検証したいのは「工務店は、このサービスを通じて職人に仕事を頼むか」です。

最初に思いつく機能を並べると、職人のプロフィールと実績写真、工務店の会員登録、条件での検索、日程の空き状況、見積もりのやり取り、メッセージ、オンライン決済、評価……と、すぐに10を超えます。これを、検証したいことを軸に整理すると次のようになります。

この形なら、作る画面は職人の紹介、依頼フォーム、管理画面の3つが中心です。運営の手作業は増えますが、最初の利用者が少ないうちは回せる量であり、工務店がどんな条件で職人を探しているのかを直接知る機会にもなります。

どちら側から始めるかの判断基準

先に集める側は、機能よりも運営の個別の働きかけで集めることが多くなります。システムで作り込むのは、もう片側が自分で使う部分から、と考えると範囲を絞りやすくなります。

運営の手作業が限界になったら、次を作る

手作業で回している間に、利用者がどんな流れで取引に至るのか、どこでつまずくのかを記録しておくと、自動化するときにどんな仕組みにすべきかが具体的になります。機能を絞る考え方の全体像はMVPとは？機能の絞り込み方で解説しています。

手作業で補っても、体験は途切れさせない

運営が手作業で補う部分があっても、利用者から見て途中で行き止まりになってはいけません。上の例でいえば、工務店が依頼フォームを送ったあと、いつまでに、誰から、どんな連絡が来るのかが分からなければ、手作業の仲介であっても不安を与えます。受付完了のメールに運営から連絡するまでの目安を書いておく、職人が見つからなかった場合もその結果をきちんと伝える、といった運用の約束事を、画面の外の部分も含めて決めておきましょう。

検証段階でも決めておくべきこと

取引の内容によっては、法令上の確認が必要になる場合もあります。事業の形が固まった段階で、専門家に相談しながら整備してください。会員の登録や情報の見せ方については会員制Webサービス・会員サイトを作る前に決めるべきことも参考になります。

検証で見る数字

• 先に集める側が、どのくらいの手間で集まるか
• 依頼から成立まで、どのくらいの割合で進むか
• 成立しなかった依頼は、どこで止まったか
• 一度使った利用者が、また使うか
• 運営の手作業は、どのくらいの件数まで回せるか

最後の数字は、次にどの機能を作るかを決めるうえで重要な材料になります。予算の考え方はスタートアップのMVP開発費用はどう考える？、検証後の判断はMVPを作ったあとはどうする？をご覧ください。

相談の前に整理しておきたいこと

• 誰と誰をつなぐのか、それぞれが得るもの
• どちらの利用者を先に集めるか、その見込みと方法
• 取引の流れ（依頼、調整、提供、支払い、評価）と、運営が関わる部分
• お金の流れと、運営の収益の考え方
• 検証で確かめたいことと、見る数字

片側から始める設計を、一緒に検討します

上の例のように、検証したいことを軸にすれば、マッチングサービスでも最初に作る画面は大きく絞れます。Tailboneでは、新規事業のMVPを小さく作り、検証の結果を見ながら育てていく進め方を大切にしています。誰と誰をつなぐのか、どちらを先に集められそうかを伺い、作る部分と運営の手作業で補う部分の線引きを一緒に考えます。外注で進める場合の注意点はMVP開発を外注するときの進め方もあわせてご覧ください。