FIELD NOTE 04
『できます』より、途中の状態を説明できるかを見る。
マッチングサイトの見積もりは、機能名だけだと差が見えません。会員登録あり、チャットあり、管理画面あり。それでも、本人確認前は何ができるのか、掲載を直したら再審査なのか、取引終了後は履歴を残すのかで実装は大きく変わります。開発会社を比べるときは、完成画面より『途中の状態』を質問する方が、実運用を考えているか分かりやすいです。
SECTION 01
開発会社を比べる前に、まず『同じものを見積もっているか』を確認する
マッチングサイトの見積もりは、会社ごとに前提が違うことがあります。A社は会員登録・検索・問い合わせまで、B社は本人確認・メッセージ・管理画面まで。金額だけ並べると安く見えても、そもそも含まれる範囲が違えば比較になりません。
最初にそろえたいのは、誰と誰をつなぐか、何を掲載するか、どこで最初の接点が生まれるか、運営が何を確認するかの4点です。この前提を同じにしてから、各社の提案を見ると違いが見えます。
公開されている比較記事でも、実績、費用、開発方法、カスタマイズ性、保守運用などが主な比較軸として挙げられています。実際の発注では、そこに『状態・権限・例外処理』まで加えると判断しやすくなります。
SECTION 02
1. 『マッチングサイトの実績がありますか?』だけで終わらせない
実績は重要です。ただし、完成したトップページの画像だけでは分かりません。確認したいのは、ログイン後、掲載審査中、問い合わせ後、取引終了後などの画面です。
マッチングサイトは、利用者が途中の状態にいる時間が長いサービスです。本人確認待ち、掲載確認待ち、返信待ち、支払い待ち。こうした状態をどう扱ったかを聞くと、その会社が実運用まで経験しているか見えやすくなります。
- ログイン後の画面や管理画面まで見せられるか
- 審査・承認・差し戻しをどう作ったか説明できるか
- 取引終了後やキャンセル時の扱いを説明できるか
SECTION 03
2. 会員種別と権限を、画面ではなくデータまで説明できるか
売り手と買い手、法人と個人、一般会員と管理者。立場が増えると、見える情報とできる操作が変わります。画面上でボタンを隠すだけではなく、データ取得そのものを制限する必要があるケースもあります。
比較時には『買い手が売り手用のAPIへ直接アクセスしたらどうなるか』『法人Aの担当者が法人Bのデータを取得できない仕組みはどこにあるか』まで聞いてみてください。回答が画面の話だけなら、追加確認が必要です。
SECTION 04
3. 『チャット機能あり』ではなく、開始条件と終了条件を聞く
チャット画面を作ること自体は仕様の一部です。重要なのは、いつ会話を始められるか。本人確認前でも送れるのか、問い合わせを受けたら自動で開くのか、掲載が終了したら送れなくするのか。
無料不動産では、問い合わせを受け付けることと、実際にメッセージを送れる状態を分けています。こうした中間状態を扱える設計かどうかは、本番運営で大きな差になります。
SECTION 05
4. 管理画面を『後で作ります』にしない
公開初日から毎日使うのは、利用者向けトップページより管理画面かもしれません。掲載審査、本人確認、問い合わせ確認、利用停止、差し戻し。運営作業をDBへ直接入って行う前提では長続きしません。
豪華な分析ダッシュボードは後でも構いません。ただし、日常運営に必要な承認・停止・状態変更は初期版から入っているか確認します。
SECTION 06
5. 見積書の『一式』を、状態と操作へ分解してもらう
『会員機能一式』『管理画面一式』『マッチング機能一式』は、そのままでは比較できません。一覧表示だけなのか、編集・承認・履歴・通知まで含むのかで工数が変わります。
見積もりを比べるときは、画面名だけでなく『誰が、どの状態で、何をできるか』へ分解してもらうと、追加費用になりそうな場所が見えてきます。
| 見積もり項目 | 確認したい質問 | 後で増えやすいもの |
|---|---|---|
| 会員機能 | 会員種別・権限はいくつか | 法人所属、招待、退会後処理 |
| 掲載機能 | 下書き・審査・再審査はあるか | 差し戻し、公開停止、編集履歴 |
| 問い合わせ | 開始条件・重複防止はあるか | 本人確認待ち、通知、終了処理 |
| 管理画面 | 承認・停止・履歴確認までできるか | 監査ログ、担当者権限、CSV |
SECTION 07
6. 最初から全部作る提案だけでなく、削る提案ができるか
機能を足す提案は簡単です。新規事業で価値があるのは、『今は作らなくてよいもの』を説明できることです。レビュー、レコメンド、高度な通知、分析画面。使われるか分からない段階なら後回しにできるものがあります。
ただし、将来の権限や取引状態を無視して削ると、あとで作り直しになります。削る機能と、先に骨格だけ用意する部分を分けて提案できる会社か確認します。
SECTION 08
7. 公開後の変更方法と費用を、契約前に聞く
公開すると必ず変更点が出ます。入力項目を増やしたい、検索条件を変えたい、審査の順番を変えたい。マッチングサイトは運営から仕様が見つかるサービスなので、変更できない契約は相性がよくありません。
月額保守に何が含まれるか、軽微修正と追加開発の境界、緊急不具合の対応時間を確認します。公開時の金額だけでなく、1年間の運用費で比べる方が現実的です。
SECTION 09
8. データを取り出せるか。会社を変えたいときに止まらないか
利用者、掲載、問い合わせ、取引履歴は事業の資産です。将来別の開発会社へ移る、別システムへ統合する可能性もあります。
契約前に、データの所有者、エクスポート方法、ソースコードや環境の扱い、ドメインの管理者を確認します。ベンダーを変えられない状態にしないことも、長期運営では重要です。
SECTION 10
9. セキュリティは『SSLあり』より、誰の情報を守るかで聞く
マッチングサービスでは、プロフィール、メッセージ、本人確認書類、取引情報などを扱う場合があります。SSLだけでは十分な説明になりません。
どの情報を公開し、どの情報を会員だけに見せ、どの情報を運営だけに見せるのか。ファイルの保存場所、アクセス制御、削除方法、操作履歴まで、扱う情報に合わせた説明があるか確認します。
SECTION 11
10. 最後に『このサービスで最初に検証することは何ですか?』と聞く
良い提案かどうかを見る質問として使いやすいのがこれです。掲載が集まるか、問い合わせが発生するか、有料取引が成立するか。最初に確かめたいことによって必要な機能は変わります。
この質問に対して、機能一覧ではなく事業の仮説から答えてくれる会社なら、開発だけでなく公開後まで考えている可能性が高いです。
SECTION 12
比較表を作るなら、価格ではなく『答えの具体性』も点数にする
最終比較では、費用、納期、実績、保守に加えて、ここまでの質問への答えを一枚にまとめます。『できます』だけなのか、『この状態ではこう動きます』まで答えられるのか。後者の方が、実装時の認識差は減ります。
当社でも自社マッチングサービスを運営しているため、見積もり時には画面数だけでなく、公開条件、確認条件、問い合わせ開始、終了後の扱いを先に整理します。制作会社を選ぶときも、同じ観点で比較してみてください。
QUESTIONS
よくある質問
Q. マッチングサイト開発会社は何社くらい比較すればいいですか?
数より、同じ前提で比較できることが重要です。2〜3社でも、対象機能、運営範囲、保守条件を同じ粒度でそろえると判断しやすくなります。
Q. 一番安い開発会社を選んでも大丈夫ですか?
必要範囲が同じなら価格は重要です。ただし本人確認、管理画面、例外処理、公開後の修正などが別料金になっていないかを確認し、1年間の総額で比較することをおすすめします。
Q. 制作実績は何を見ればいいですか?
トップページだけでなく、ログイン後、審査中、問い合わせ後、管理画面、取引終了後など、実際の運営で使う画面や状態を確認すると設計力を判断しやすくなります。
Q. 仕様が決まっていない状態でも相談できますか?
可能です。誰と誰をつなぐか、何を掲載するか、最初の接点、運営が確認する項目を整理できれば、初期版の範囲を決められます。
参考資料
相場や仕様に関する数値は公開情報を参照しています。個別案件の見積額を示すものではありません。
START HERE
企画から公開までの全体像は「マッチングサイトの作り方」へ
費用や機能を個別に比較する前に、誰と誰をつなぐか、MVPをどこまで作るか、公開後に何を見るかを一つの流れで整理できます。
マッチングサイトの作り方を読む