マッチングビジネスのMVPをスプレッドシートで検証する手順
「困っている人」と「助けられる人」をつなぐマッチングのアイデアは浮かんだものの、いざ始めようとすると手が止まる。そんな経験はないでしょうか。開発にお金や時間をかけて、できた頃に誰にも使われなかったら、と考えると踏み出しにくいですよね。
その不安を解くカギが「MVP（最小検証版）」です。本格的に作り込む前に、アイデアが本当に成立するかを最小限の形で確かめてみることを言います。
この記事を読み終えると、次の3つが分かります。
- 検証用のスプレッドシート（表計算シート）に、何をどう記入すればいいか
- 自動システムを使わず、自分の手でマッチングを回す手順
- 成功か失敗かをどう判断し、その後どう動けばいいか
まずは「なぜ、いきなり作らずに小さく試すのか」から見ていきましょう。
いきなりシステムを作る前に「小さく試す」という考え方
数ヶ月かけて開発したあとに「やっぱり需要がなかった」と気づくケースは、実はとても多いものです。多くのスタートアップの廃業理由を分析したCB Insightsの調査でも、約4割が「市場にニーズがなかった」を挙げています。だからこそ、お金と時間をかける”前”に確かめる意味があります。
とくにマッチングは「依頼したい人」と「応えたい人」の両方が揃って成り立ちます。片方しか集まらないリスクが、普通の事業より大きいんですね。だからこそ、先に小さく確かめておく価値も、そのぶん高くなります。
なぜ高価なシステムではなく「スプレッドシート」で足りるのか
「検証するにもシステムがないと無理では？」と思うかもしれません。でも検証段階で確かめたいのは、機能の出来栄えではなく「本当に需要があるか」だけです。
実際、いまでは誰もが知る大手サービスも、最初は手作業から始まっています。Airbnbの創業者は自分のアパートにゲストを泊めて需要を確かめました。フードデリバリーのDoorDashも、最初は簡易なツールと手作業で注文をさばくところから始めたと言われています。
スプレッドシートと手作業なら、今日この場から無料で始められ、失敗しても痛手はほとんどありません。自動化やプラットフォーム化は、需要が確かめられてからで十分です。
検証シートのつくり方 ― 列構成とタブ設計、記入例
では、検証の中心となるスプレッドシートを作りましょう。「2種類の名簿」と「つないだ記録」、合わせて3つのタブ（シート内のページのこと）に分けるだけです。
3つのタブで管理する
1つ目が「需要側リスト」で、何かを求めている人の名簿です。2つ目が「供給側リスト」で、何かを提供できる人の名簿になります。3つ目が「マッチング記録」で、両者を引き合わせた結果を残すページです。あとから「何件まとまったか」を数えられるよう、1マッチにつき1行で残しておくとあとがラクになります。
各タブの列構成
ここでは「スキルを教わりたい人」と「教えられる人」をつなぐスキルシェアを題材にします。需要側リストの列構成はこのようになります。
| 列名 | 中身 | なぜ必要か |
|---|---|---|
| ID | D-001 など | マッチング記録から参照する通し番号 |
| 名前 | 山田さん | ニックネームでも可 |
| 連絡先 | LINE・メールなど | 後で連絡を取るため |
| 求めている条件 | 「Excelを教わりたい」 | マッチングの核になる情報 |
| 希望時期 | 「今月中」 | 供給側の空き枠と突き合わせる軸 |
| 温度感 | 高・中・低 | どれくらい本気かの目安 |
| ステータス | 未対応・提案中・マッチ済 | いまどの段階かの管理 |
| 次回フォロー日 | 6/8 など | 並べ替えると対応漏れを防げる |
供給側リストは、需要側とほぼ左右対称です。「求めている条件」が「提供できる内容」に、「希望時期」が「対応可能枠」に置き換わります。
| 列名 | 中身 |
|---|---|
| ID | S-001 など |
| 名前 | 佐藤さん |
| 連絡先 | メール・SNSなど |
| 提供できる内容 | 「Excel関数の基礎を教えられる」 |
| 対応可能枠 | 「週末2枠まで」 |
| 温度感 | すぐ動ける・条件次第 |
| ステータス | 稼働中・枠埋まり・休止 |
「温度感」や「ステータス」は、プルダウン（決めた選択肢から選ぶ仕組み）にしておくと、表記のばらつきを防げて集計もしやすくなりますよ。
記入例で流れをつかむ
3つのタブがどうつながるのか、1本の例で追ってみましょう。
- 需要側リスト：
D-001｜山田さん｜LINE｜Excelを教わりたい｜今月中｜温度感:高｜提案中｜次回フォロー:6/8 - 供給側リスト：
S-003｜佐藤さん｜メール｜Excel関数の基礎を教えられる｜週末2枠まで｜温度感:高｜稼働中 - マッチング記録：
M-001｜6/4｜D-001｜S-003｜成立｜オンライン90分｜FB:山田さん満足／佐藤さん「次回は範囲を事前共有したい」
注目してほしいのは、マッチング記録の「D-001」「S-003」というIDです。これで「誰と誰を、いつ、どんな条件でつないだか」が一目で追えます。最初から完璧に作り込まなくて大丈夫。列は後から足せば十分です。
人手で需要側と供給側をつなぐ「コンシェルジュ型」運用手順
シートができたら、いよいよ運用です。ここで使うのが「コンシェルジュ型」と呼ばれるやり方になります。自動マッチング機能を作る代わりに、自分が手作業で両者を引き合わせる方法のことです。基本の流れを、次の5ステップで見ていきましょう。
- 需要側と供給側を、まず少人数ずつ集める
- 集めた人をシートに登録する
- 両者の条件を見比べ、自分の頭で組み合わせを考える
- 双方に連絡し、実際に引き合わせる
- 結果と双方の反応を、マッチング記録に書き残す
アルゴリズムがやるはずの仕事を、最初は人が肩代わりする。これがコンシェルジュ型の考え方です。
まずは5件から10件くらいの小さな規模で回してみてください。数を追う必要はありません。Y Combinatorのポール・グレアム氏も「スケールしないことをやれ」と説いています。この段階の価値は、1件1件の組み合わせや相手の反応を、自分の目で確かめられる点にこそあります。
成功／失敗を見分ける指標と、進む・方向転換・撤退の判断
数件のマッチングを回すと、合否を見極めたくなります。ここで気をつけたいのが、「言葉」ではなく「行動」で判断することです。「いいね」「便利そう」という感想は、応援であって需要ではありません。見るべきは、お金を払おうとするか、再び依頼してくるか、といった”行動を伴う反応”です。引き合わせがマッチに至った割合（成立率）と再依頼の有無を、件数とセットで見ていきます。
そして一番大事なのが、合否の基準を「検証を始める前に」決めておくことです。「10件試して何件で前向きな反応が出たら進む」と、先に線を引いておく。これを怠ると、「ここまで頑張ったんだから」という心理（埋没費用バイアスと呼ばれます）に引きずられ、判断が鈍ってしまいます。
反応を見て、進む道は大きく3つに分かれます。
- 手応えあり → 本格的な構築へ進む
- 需要はあるが、想定と形が違う → ピボット（方向転換）する
- 反応が薄い → いったん撤退や仕切り直しを考える
ピボットとは、目指すビジョンは変えずに、やり方だけを変える前向きな軌道修正のことです。「依頼は来るけれど、想定した形とは違う」というときが、その出番ですね。
やりがちな落とし穴も2つあります。1つは、サンプルが少なすぎる状態で判断してしまうケースです。2件3件のいい反応で舞い上がるのは避けたいところ。もう1つは、知人や身内ばかりに聞いてしまうパターンです。親切心から「いいね」と言われるので、真に受けると判断を誤ります。聞くときは「このアイデアどう？」ではなく「前回その問題で困ったとき、実際どうした？」と、過去の行動を尋ねてみてください。
まとめ ― まずは検証シートを1枚つくることから
高価なシステムを作る前に、スプレッドシートで本当に需要があるかを確かめ、自分の手でマッチングを回し、行動を伴う反応を指標に合否を判断する。進む・方向転換・撤退のどれを選ぶかは、事前に決めた基準に沿って決めていく。これが、立ち上げ前に小さく試すための一連の流れです。
まずは今日、空のスプレッドシートを開いて、3つのタブと列を作り、最初の数件を登録してみてください。完璧な設計を考えるより、1件登録するほうがずっと多くの学びが得られます。私自身、頭の中であれこれ悩んでいたときより、1行目を埋めた瞬間に「次に何を聞けばいいか」が一気に見えた感覚があります。
検証で手応えが得られたら、片側を先に集めて両者を揃える工夫や、ノーコード（プログラミングなしでアプリを作る方法）での本格化といった次の道が見えてきます。その進め方に興味があれば、関連記事も覗いてみてください。