合意したのに、取引が終わらない。マッチングサービスを作る前に手作業で試すこと

たとえば「貸したい人も借りたい人も登録したのに、予約が決まらない」。日時の合う在庫や、双方が受け入れられる価格があるかを、まず調べます。

合意まで進んだ割合が50％でも、取引完了が25％なら、合意後に何が起きたかを調べる必要があります。次は、同一市内のプロジェクター1日貸出を14日間追う設定です（想定例）。受付した4組のうち2組が合意し、利用・返却・入金まで終わったのは1組。途中の取消も分母から外しません。

開発前は、貸す人と借りる人の条件を手作業で合わせ、履行まで追います。不成立の理由と運営の仕事が分かれば、検索機能を足すべきか、価格や受渡し方法を見直すべきかを選べます。

貸す人と借りる人は、何を求めているか

貸す側は「空いている機材を使ってもらいたい」、借りる側は「必要な日に、受け取れる場所で借りたい」と考えるかもしれません。ただし、これも最初は仮説です。稼働率を上げたい貸す側にとって、受渡しや返却確認の負担が増えれば、参加する理由がなくなる可能性があります。

Sharetribeのガイドは、売り手と買い手の双方について、課題、解決策、事業モデルの仮説を確認する方法を説明しています。次の質問表で、双方の直近の行動を聞いてみてください（出典：Sharetribe「Create a marketplace in 10 practical steps」Step 4）。

確認すること	募集者（貸す側）への質問	応募者（借りる側）への質問
現在の代替手段	最近貸したとき、相手をどう見つけましたか。空いた日はどうしていますか。	最近必要になったとき、どう探しましたか。見つからなければどうしましたか。
必須条件と参加負担	貸せる日、最低料金、受渡し・返却の条件は何ですか。対応できない作業は何ですか。	動かせない日時、予算上限、受取場所はどこですか。登録や連絡に何が必要だと使いませんか。
支払意思と再利用機会	紹介に対する手数料を負担できますか。何が提供されれば払えますか。	利用料や手配料はいくらなら払いますか。次に必要になるのはどんな場面ですか。

質問は、サービスの魅力を説明する前に、直近の行動から始めます。「便利なら使います」という回答と、条件を提示して実際に応募すること、実際に支払うことは別の証拠です。質問票には発言と運営者の解釈を分け、両側のどちらかしか確認できていない仮説も残します（出典：Sharetribe「How to validate your marketplace idea before building the platform」Interview your users）。

50％の合意から、25％の取引完了まで（想定例）

応募・合意・取引完了を別の状態にする

本例の主指標は「取引完了」です。利用・返却と、貸す側による入金確認がそろった時点を成立と数えます。契約の成立時点は別途、契約条件に従って扱います。面談のあるサービスなら、面談成立と取引完了を同じ件数にしない設計が必要です。

状態	本例で記録する確認条件
応募受付	対象の募集と希望条件を受領した。条件不一致の応募も残す。
紹介・調整中	共有範囲を確認して相手へ条件を提示した。提示だけでは合意にしない。
合意	双方が、同じ日時・金額・受渡し条件・取消条件を承諾した。
履行済	利用と返却を双方に確認した。未入金なら取引完了とは分ける。
取引完了	履行と入金の確認記録がそろった。
例外	合意前の不成立、合意後取消、不履行、期限時点の保留を区別する。

割合には、何を数えたかを添える

架空の観測期間をD1〜D14（Dは開始からの日数）、成立定義をv1とします。募集は3件、応募は4件、応募者は3人、照合は4組です。一人が二つの募集へ応募したため、応募件数と人数は一致しません。

借りたい人が同じ機材に集まると、日時と料金が合っていても、後から応募した人には貸せません。別の機材では、貸す側の5,000円と借りる側の上限3,000円が折り合わず、不成立になります。合意できたもう一組は、借りる側の予定変更で取消となります。

募集3件・応募4件の条件と記録番号を照合する

募集IDをR、応募IDをA、応募者IDをU、募集と応募を結ぶ照合IDをCとして記録します。本例は1募集を「1台×1利用日」の1枠とします。同じ人の別募集への応募は新しい応募IDを付け、同じ組の再連絡は履歴へ追記します。条件を変えて再検証するときも、元の結果を消さず、新しい版で関連付けます。

照合／募集／応募（応募者）	必須条件と提示条件	D14時点の結果
C01／R01／A01（U01）	D5、総額3,000円。応募側も同条件。	合意後に利用・返却・入金を確認。取引完了。
C02／R02／A02（U02）	D5、募集側5,000円。応募側の上限3,000円。	価格が一致せず、合意前に不成立。
C03／R03／A03（U03）	D6、総額4,000円。応募側も同条件。	合意後、応募者の予定変更で取消。
C04／R01／A04（U02）	D5、総額3,000円。条件は一致するがR01は合意済。	残枠がなく、合意前に不成立。

金額は1台1日あたりの税込支払総額という仮定で、手配料・配送費は含まず、いずれも店頭受取・当日返却です。この例では合意到達率が2組÷受付した照合4組＝50％、取引完了率が1組÷同4組＝25％です。合意後取消率は取消1組÷合意到達2組＝50％。募集単位の充足率は取引完了のあった募集1件÷対象募集3件＝33.3％になります。

事業として続ける基準は、これらの割合と採算の見込みを合わせて決めます。条件が合わない応募や取消を後から分母から外すと、別の指標になります。観測期限に結果が出ていない組は保留として示し、後日追跡します。応募ゼロの募集も募集台帳に残せば、「応募が来ない」と「来ても決まらない」を区別できます。

図1｜募集3件・応募4件を照合した記入例。D1〜D14、成立定義v1（想定例）。

上の記入例と同じID・数式を使う照合用記入シート（Excel）を取得できます。空欄版、記入例、集計表を収録しています。

フォームと表計算で、受渡しまで試す

対象カテゴリ、地域、参加経路、募集の受付期間、結果を追う期限、運営担当を先に決めます。人数や日数に万能の正解はありません。取引が起きる間隔に合わせ、片側しか参加しない場合や、判断に必要な組が集まらない場合の再募集・延長・終了条件を置きます。

手順は、募集者から掲載可能な条件を受け取り、応募者の希望を受け付け、運営者が必須条件を照合する流れです。原資料のStep 4にも、表計算を使う小規模な組み合わせ検証が示されています。フォームと表計算、連絡手段を組み合わせ、最初からアプリにしない計画を立てられます（出典：Sharetribe「Create a marketplace in 10 practical steps」Step 4）。

取引が完了する一組では、日時・総額・受取と返却の方法を双方へ提示します。3日目に両者が承諾し、機材の枠を確保。5日目に利用と返却、6日目に入金を確かめて取引完了とします。一方、別の一組は3日目の合意後、4日目に取消となります。運営者は、貸す人に再募集できるかを尋ねます。

各段階で、入力した人、確認した人、確認日時、証拠の参照先、次の担当と期限を残します。紹介文は本人が認めた範囲で共有し、既存サイトの募集や連絡先を無許可で転載しません。連絡先の保管場所、閲覧者、利用目的、削除時期を決め、記入シートの公開版には個人を特定できる情報を載せない運用にします。

実際に有料取引や職業紹介などを試す前には、扱う商材、当事者の権限、許認可・届出、料金や取消条件を別に調べてください。人材分野は、手動か自動かだけで制度上の扱いが決まるわけではありません。個別の区分は所管窓口に問い合わせ、本記事の貸出例をそのまま転用しないでください（出典：厚生労働省「募集情報等提供と職業紹介の区分について」）。

図2｜記録、確認者、確定条件、例外の戻り先をつないだ検証の流れ。IDは本記事の架空例に対応します。

完了しなかった組への対応も、運営の仕事

不成立をすべて「機能不足」とまとめると、次に作るものを誤ります。価格が合わない二人に検索機能を足しても、双方が受け入れられる金額は変わりません。一方、機材の空きがなかった応募では、供給の追加や、受付可能な枠の更新方法を試す対象です。

理由の区分	記録する事実	次に確かめる仮説
供給不足	該当日時の空きがない／応募が集中した。	供給する日や台数を増やせるか。
条件不一致	受取場所、日時、返却方法が合わない。	どの条件なら変更できるか。
信頼	破損時の扱いや相手の確認に不安が残った。	何を確認・説明すれば判断できるか。
価格	希望総額と支払上限が離れている。	対象や提供内容を変えても合うか。
連絡遅延	返信期限を超えた／次の担当が不明だった。	通知、締切、担当の指定で変わるか。

理由は主因と補足に分け、当事者が述べた内容と、運営者の推測を混ぜません。返信がないだけなら「価格が高い」と決めず、連絡未了として残します。取消や不履行には発生段階、申出者、対応内容も記録し、同じ価格・期間・参加経路で比べます。少数例の割合を市場全体へ一般化しないことが前提です。

完了した一組に直接かかった作業は35分。それでも、運営全体では完了一組あたり120分です。不成立や取消への対応にも時間がかかるためです。

内訳は、完了した組35分、価格不一致20分、合意後取消30分、残枠なし15分で、照合対応が計100分。共通の募集整備20分を加えると、総作業120分÷完了1組＝120分／完了組となります。返信を待った経過時間とは分けて測り、完了ゼロなら1件あたりの値は未算定とします。

この数字だけでは採算は判定できません。想定する運営収入、担当者の時間単価、決済やサポートの費用を別に確認します。申込頻度の低い商材では、短期間のリピート率だけを成功基準にせず、必要な場面で相手が見つかったか、次回の利用条件が具体的かも追います。

手作業で分かったことから、作る機能を選ぶ

最小版（MVP）は、仮説を確かめるための最小限の提供形態です。SharetribeのStep 5は、両側の中心的な問題を解くことと、初期段階では手作業を残せることを説明しています。本例では、繰り返し発生し、ルールが定まり、成立や安全な運営に必要な処理を機能化の候補にします（出典：Sharetribe「Create a marketplace in 10 practical steps」Step 5）。

判断	この例から検討できること
機能化	空き枠更新、重複予約の抑止、合意・取消の履歴、連絡期限の通知。実際の再発と負担を確認して優先付けする。
運用変更	必須条件を先に確認する、返信担当を決める、取消時に再募集可否を確かめる。
再検証	価格、対象日時、受渡し方法など、仮説を分けて試す。片側だけの回答なら両側の確認へ戻る。
見送り	条件を変えても両側の便益を説明できない、許容する運営負担を超える、安全・適法な実施条件が整わない。

たとえば予約連絡と状態記録だけを小さく作り、条件交渉や例外対応は当面人が担う段階が考えられます。ただし、決済を含めない検証で分かるのは予約までの使い勝手や合意であって、支払いや返金を含む取引全体の成立ではありません。「まだ試していない工程」を明記し、必須機能の判断と混同しないようにします。

開発に進む前には、続ける条件、再検証する条件、止める条件を事業ごとに記入します。人数・期間・費用の条件は、実際に取引が起きる間隔と、自分たちの予算から決めます。開発する機能は、双方の条件を合わせ、履行まで進めるうえで必要なものから選びます。

本番化・再検証・中止を判断する全体の進め方は、試作・PoC・MVPから本番へ進む条件と見送る条件で扱っています。

募集条件、成立定義、不成立理由を整理しても、既存ツールでは連携や履歴管理に課題が残る場合は、照合シートを相談材料にできます。記録したい状態と、人が判断を残す工程を添えてご相談ください。

マッチングサービスの開発を相談する

参考出典

• Sharetribe「Create a marketplace in 10 practical steps」
• Sharetribe「How to validate your marketplace idea before building the platform」
• 厚生労働省「募集情報等提供と職業紹介の区分について」