マッチングサービスのビジネス要件で確認するべきところ
- 土門 大貴
- 記事制作日2023年11月22日
- 更新日2023年11月22日
- 0いいね!
前回の記事では、マッチングサービスの需要や魅力についてご紹介しましたが、では実際に経営計画を建てたり、開発を依頼する際、まず何から決めていけば良いのでしょうか。
今回は、マッチングサービスの計画を建てる際、決めておくべき点についてご紹介します。
どんなタイプ?
まずは一番重要な点として、『何と何をマッチングさせるのか』について決めましょう。
『そんな事はもう決まっている』と思われるかもしれませんが、これは意外と複雑な問題です。
例えば漠然と『企業と企業をマッチングさせるサービス』では、範囲が広すぎますし、サービスとして成り立たないでしょう。作ったとしても「これはなんのサイトなのだろう」とユーザーが迷ってしまいます。
ではもう少し狭くして『建設業と下請け業者をつなぐサービス』ならばどうでしょうか。これなら成り立ちそうですが、サービスのわかり易さや、展開のしやすさを考えれば、もっと絞りたいところです。
では『人材が不足している建設会社に案件・地域・工期を登録してもらい、そこに下請け業者や職人さんが応募するサービス』ならどうでしょうか。
これならば、需要・対象・必要な機能がはっきりしていますね。
誰にサービスを提供するのか、どのような形で登録してもらうのか、そのためにはどのような機能が必要かについて、全てが明確になっているため、計画や戦略を綿密に建てることができます。
計画や戦略を建てる上では『既存のサービスとかぶる箇所はないか』といった点や、逆に『取り入れることのできる要素はあるか』といった点を考慮してみましょう。
マッチングサービス業界では、先駆けて参入した企業が圧倒的に有利ではあります。なので、なるだけサービス対象が被らないようにしたり、もっと細かいニーズを拾えるようにすることが重要となります。
一方で、先駆けてうまくいっているマッチングサービスは、参考にするべきノウハウの結晶です。
営業対象にどのようなアプローチを取っているのか、どのような入力フォームで登録させやすくしているのか等、色々な箇所を観察してみましょう。
既存のマッチングサービス
BtoB:比較ビズ、発注ナビ、ClowdWorks、Lancers、Web幹事 等
CtoC:Tinder、Pairs、Menta、airbnb、ココナラ、メルカリ 等
マッチング前の開示情報・コミュニケーションの許可
マッチングサービスの概要が決まったならば、次は細かい仕様を詰めていきましょう。
マッチングサービスにおいては『マッチング相手にどこまで情報を開示するか』という点も重要な論点です。
もし先にマッチング相手の情報を開示しすぎてしまった場合、『直接連絡を取れば手数料が発生しない』と見て、メールや電話で連絡を取り合う利用者が出てくるでしょう。
一方で情報を制限しすぎた場合は、果たして自分が求める要件に合う相手なのか、ユーザーが見極められないようになってしまいます。
ちょうどいい基準を探すのは、案外難しいのです。
更に関連する点として、『コミュニケーションをどこまで許可するか』についても考えなければなりません。
もし誰でもメッセージを送り放題にした場合、営業メッセージやスパムが蔓延してしまい、ユーザーに不快感を抱かせたり、マッチングツールとして成り立たなくなってしまう可能性があります。
そこまで至らなくとも、ユーザーがWINWINとなるマッチング相手を見つけにくくなったり、カスタマーの仕事が増えたりと、あまり良い結果には至らないでしょう。
しかし逆にマッチングするまでメッセージ禁止にしてしまうと、どうなるでしょうか。
最初に提示された条件でしか取引ができなくなってしまいますので、これはこれでユーザー間のマッチングを阻害したり、サービスの質を落としてしまうかもしれません。
もちろん、マッチングする対象や仕様によっては、上記のような仕様にしたところで問題ないケースもあります。
例えば『掲載時に掲載料をもらう』形のサービスであれば、あとは自由な形でコミュニケーションを取ってもらって構わないかもしれません。
逆に男女間でのマッチングサービスであれば、マッチングするまでメッセージを送れないのは普通の仕様です。
これらの最適解は、それぞれの業種や仕様によって異なります。
この部分で利用者数や、サービスの質が左右されることもありえるため、ぜひ熟考した上で仕様を決めて下さい。
いいねの種類
また、多くのマッチングサービスでは『いいね』機能も重要な要素となっています。
ただし『いいね』がもつ意味合いは、各サービスによって異なります。
出会い系のマッチングアプリでは、まず相互に『いいね』を送りあった中から、マッチング候補が提示され、コミュニケーションを取り合うのが主流です。
一方で、フリマ系アプリや、スキルシェア型のマッチングサービスの場合は、『ブックマーク』のような形で『いいね』を使うこともあります。
実際にマッチングが成立するわけではないので、一見意味のない機能と思うかもしれませんが、この『いいね』を検索アルゴリズムの指標にすることもありますし、出品側がサービスの改善や掲載方法の参考にしたりすることもあります。
いずれにしても、利用者がうまくサービス上で機能を使いこなせるよう、運営側が整備してあげる必要があるでしょう。
いいねの仕様について
一回送りきりのいいね
複数回いいねを送れるか
複数人からいいねが送れるか
ユーザー登録の承認フローが絶対必要?
他にも、『サービスの質』を左右する箇所があります。
それは『ユーザー登録』についてです。
マッチングサービスにおいては『マッチング相手の質』も、評価の対象となります。
もし多数のマッチング相手を揃えていたとしても、その登録者が法律や社会的なマナーを守らない企業や個人の場合、逆にユーザーへ損失を与えてしまうことになるのです。
例えば案件を依頼する形のマッチングサービスで、受注側が納期を守らなかった場合は、直接的な損害が発生するでしょう。
それだけでなく、機密情報を外部に漏らしたり、制作物の中に著作権を侵害する作品が含まれていた場合は、企業の経営を左右するようなトラブルに発展する可能性すらあります。
なので、一部のマッチングサービスでは、本人確認書類等の提出を義務付けているところもあります。
これらの仕組みは一見大変なように思われるかもしれませんが、外部サービスに委託すれば、比較的現実的な範囲で実装が可能です
ただし、『ユーザー登録のハードル』は、そのまま『サービス利用のハードル』にも直結します。
なのでもしオペレーションが許すのであれば、一旦誰でも登録できるようにした上で、『お互いが相手ユーザーの認証状況を確認できる』『一定金額以上は認証済ユーザーのみ利用ができる』といった機能をつけて、サービスの信頼を落とさないようにすることもできます。
マッチングする物(単位)は何?
また、実際に運用を考える際、ネックになりがちなのが『マッチングの定義』についてです。
例えば、最近人気の『スキルシェアサービス』(個人のスキルを売り買いするマッチングサービス)を作るとしましょう。
このようなサービスはいくつもありますが、実際のマッチング形態は千差万別です。
スキルシェアサービスの色々な形態
- 売り手が自由に条件を提示して出品し、買い手が購入する(例:ココナラ・MENTA)
- 売り手が1時間あたりの価格を提示し、買い手が購入する(例:ビザスク)
- 買い手が案件の形で募集を掛け、そこに売り手が応募する(例:ランサーズ・クラウドワークス)
- 買い手が人材募集の形で要項を公開し、売り手が応募する(例:Offers・レバテック)
- 決まったフォーマットに従い、売り手が登録し、買い手がそこから選ぶ(例:OurPhoto・DMM英会話)
これらの形態それぞれにメリット・デメリットがあります。なのでどれが最善という訳ではありません。
問題は、その形態に沿った、適切なサービスを提供しなければならないという点にあります。
例えば先頭にある『売り手が自由に条件を提示して出品』するスキルシェアサービスを作ったとしましょう。
もちろん自由度が高いのは良いことなのですが、逆に『売り手』が何をどう定義して出品していいのか迷うかもしれません。
であるならば、『売り手』にどういった点を明記する必要があるのか、わかりやすいフォームを作ったり、出品ガイドラインを作ってあげる必要があるでしょう。
更に、『魅力的な出品』が並ぶ様になった場合、1つの出品にオファーが集中してしまう、といったこともありえます。
もし売り手が個人だった場合は、簡単に許容範囲をオーバーしてしまうでしょう。
それならば『同時購入数の上限』をつけたり、表示のアルゴリズムをカスタマイズして『受注をうまく分散させる』といった手段が必要になります。
他にも『何をもって納品とするのか』『手数料は幾らにして、どちらから取る扱いとするのか』『トラブル時にはどのように対応するのか』等、決めなければならない点は数多くあります。
これら1つ1つの決定がサービスの質を左右するため、慎重な判断を行って下さい。
マッチング対象についてインターネットに開示する?
更に、検索エンジンに対してどこまで情報を開示するか、という点も重要です。
それぞれ、公開した場合と秘匿した場合についてご紹介します。
マッチング対象についての情報を、ネット上に開示した場合
大きなメリットとしては『検索エンジンからの流入を狙えるようになる』ことがあります。
マッチングサービスは集客こそが一番のネックになりますが、マッチング募集の情報をネットに公開すれば、検索エンジンからの流入も狙えるため、広告費を大幅に削減することができるでしょう。
しかも、”マッチング募集”という『実のあるコンテンツ』を『定期的に』『多岐にわたって』更新し続けることができるため、必然的に関連キーワードでの検索順位も上がり、サイトの価値も強くなっていきます。
しかしながら、このメリットはそのまま反転してデメリットになることもあります。
例えば男女間のマッチングサービスの場合は、『ネット上に情報が開示される』『ネットに情報が残る』だけで、ほとんどの人はサービスを使わなくなるでしょう。
利用者はマッチングしたいのであって、ネット上にプライベートを晒したい訳ではないからです。
ビジネスマッチングであっても、下請けに支払っている金額や、受注した仕事の金額を積極的に公開したい訳ではないはずです。
なので、このあたりは集客とプライバシーのバランスをうまく考えて行う必要があります。
マッチング対象についての情報を、ネット上に公開しない場合
一方で公開しない場合、先程述べた『検索エンジンからの流入』は見込めなくなります。
その変わり、サイトにユーザー登録することによって、マッチング募集の情報を入手できる、という価値を提供することができます。
この点を更に発展させれば、”サブスクリプション型のマッチングサービス”を作ることもできます。
魅力的なマッチング情報を、月額費用を支払った会員のみ参照できる、というサービスです。
これは『魅力的なマッチング情報を掲載し続ける』というハードルこそありますが、売上がマッチング件数に左右されず、継続的な課金収益が狙えるため、安定した運営を行いたい方にとっては魅力的な運営スタイルです。
決済方法について
そして最も重要で大変な部分がお金の話です。
マッチングサービスの形態が色々あることについては、先程ご紹介しましたが、手数料の課金方法についても、数々のバリエーションがあります。
マッチングサービスの手数料形態
- 売り手が登録時に支払う(例:一部の求人サイト)
- 問い合わせがあった際、定額を支払う(例:メディアレーダー)
- 利用中、継続して費用が発生する(例:交際アプリ)
- マッチング時に、双方から手数料が引かれる(例:ランサーズ)
- マッチング時に、買い手側が手数料を支払う(例:ラッコM&A)
これも形態と同じく、メリット・デメリットがそれぞれにあります。
各形態との相性等を考慮し、適切な価格設定を行いましょう。
また、支払い方法や入出金フローも決めなければなりません。
基本的に、クレジット決済やコンビニ決済等を実装する場合、決済代行会社のサービスを利用する形となります。
決済代行会社との契約は手続きに時間がかかりますし、マッチングサービスの場合は、2者ではなく3者が絡む決済となりますので、審査も複雑なものとなるでしょう。
なるだけ早めに決済代行会社とコンタクトを取るようおすすめします。
※決済代行会社については下記記事も御覧ください。
そして金銭のやり取りを仲介するタイプのマッチングサービスでは、キャッシュフローについての取り決めを明確にしておく必要があります。
どのタイミングで取引が成立したと見なすのか、そしていつ決済が確定し、振込が行われるのか、実現可能な決まりを作った上で明記するようにしてください。
(個人事業主や零細企業が利用するマッチングサービスの場合、出金の遅れが事業者の資金繰りに致命的な影響を与えることもあります)
なお、上記のようなマッチングサービスの場合、月々の決済手数料や振込手数料も、それなりの規模に膨らみます。
また、WEBでなくアプリで利用ができるようにした場合、GoogleやAppleに支払う手数料も考えなければなりません。
そのあたりもしっかり計算に入れた上で、計画を立ててください。
『調整込み』での計画を
ここまで、『マッチングサービスを開設するにあたり、決めなければ行けない点』についてご紹介してきましたが、
あまりに数が多いため、『うまく決定できるかどうか』不安に思われたかもしれません。
しかしながらご安心ください。
ほとんどの点は運営しながら調整することができます。
多くのビジネスにおいて言えることですが、今現在成功しているサービスも、運営していく中で色々仕様を変えています。
なので、『最初に正解を選び取る』ことよりも『きちんと修正できる』方が、サービスとしては重要なのです。
ただし、いくつかの仕様については、設計のやり直しが必要になったり、多くの工数がかかってしまう箇所も存在します。
そういった箇所については、これまでの事例等を交えてご相談に乗ることが可能です。
ぜひまずはお問い合わせいただき、どのようなマッチングサービスが作りたいのか、お話いただければ幸いです。
お問合せ&各種リンク
お問合せ:GoogleForm
ホームページ:https://libproc.com
運営会社:TodoONada株式会社
Twitter:https://twitter.com/Todoonada_corp
Instagram:https://www.instagram.com/todoonada_corp/
Youtube:https://www.youtube.com/@todoonada_corp/
Tiktok:https://www.tiktok.com/@todoonada_corp
presented by
- この記事にいいね!する
この記事を書いた人
- 36いいね!
稼働ステータス
◎現在対応可能
- 土門 大貴
職種
エンジニア
システムエンジニア(SE)
希望時給単価
10,000円~30,000円
▼実績例 ・公共インフラ事業者様向け管理システム開発(Windows、Python、PostgreSQL) ・官公庁様向け地図情報アプリのインフラ開発(Windows、PostgreSQL) ・自治体様向けポイント管理サービスのAPI開発(Linux、PostgreSQL、JS、Python) ・大手製造業様向けクラウド環境開発支援(AWS全般、Terraform) ・公共事業様向け顔認証決算システム基盤開発(Windows、PostgreSQL、JS、Python) ・リース業様向け代理店向けWebAPI開発(AWS全般、GoLang、JS) ・通販サイトインフラ構築支援、要件定義~開発(AWS, ECCube) ・結婚相談所様向けオウンドメディア制作(WordPress、JS、ウェブディレクトションな)
スキル
Python
AWS
React
・・・(登録スキル数:6)
スキル
Python
AWS
React
・・・(登録スキル数:6)