「海外の人が信用できるか」から設計したマッチングサービス ― 訪日旅行者×英語ガイドの予約プラットフォーム開発記

予約・決済・レビューのあるマッチングサービスは、機能を並べるだけなら数週間で形になります。難しいのは、初めて来た人が「ここでお金を払って大丈夫か」と判断できる作りにすることです。

Tabito（旅人）は、日本に来た外国人旅行者と、英語で案内できる地元ガイドをつなぐ予約サービスです。Posiiが企画から実装まで自社で作っています。この記事では、何をどう作ったかと、マッチングサービスを発注する前に決めておくべきことを、実際のチケットとコードをもとにまとめます。

何を作ったか

旅行者側には「定番の観光地しか回れない」「言葉の壁がある」という悩みがあり、ガイド側には「集客・予約・決済・外国人対応を個人でやるのが大変」という悩みがあります。その両方を1つのサイトで受ける、いわゆるマーケットプレイス型のサービスです。

• 探す：都市・興味・言語・価格・評価・所要時間で絞り込み、並べ替え
• 予約する：ガイドが承認するリクエスト制と、空きがあればその場で確定する即時予約（Instant Book）の2方式
• やりとりする：連絡先を相手に見せないサイト内メッセージと通知
• 評価する：完了した予約にだけ書けるレビュー
• 守る：ガイドの本人確認、通報、運営による凍結・非表示、キャンセル時の返金額の自動計算
• ガイドを集める：応募 → 簡単な面接 → 承認して掲載、の流れとガイド用の管理画面

立ち上げを速くした方法：すでに作ったものを移植する

ゼロから書き始めてはいません。社内で別サービス用に作っていた「ツアー予約」の部品を切り出し、独立したプロジェクトとして移植し、見た目とブランドを作り直しました。

やることを20件のチケットに分けて起票し、そのうち11件は移植した時点で実装済みとして翌日に閉じています。残りの9件が、Tabitoのために新しく考える必要があった部分です。

受託開発でも同じことが言えます。「全部オーダーメイド」は高くつきます。すでに動いている部品を土台にして、そのサービスでしか必要ない部分に予算を集めるほうが、早くて安く、品質も安定します。

信用は、画面ではなく仕組みで作る

「安心・安全」と書くのは簡単です。Tabitoでは、ずるができない仕組みをコードの側に入れました。

• レビューは、完了した予約1件につき1件だけ。ツアーが終わるまでは書けません。予約していない人のレビューや、自作自演の水増しが構造的にできません。
• 「Licensed（有資格）」バッジは自己申告では出ない。全国通訳案内士の資格があること、登録番号を入力していること、運営の本人確認が済んでいること、の3つがそろったときだけ表示します。2018年の法改正で「全国通訳案内士」が名称独占になったことを調べた上での設計です。
• ツアーに宿泊や航空券の手配を含められない。それらを含めると旅行業の登録が必要になりかねないため、入力の段階でエラーにしています。
• 返金額はキャンセルした時点で確定させる。後からガイドがキャンセルポリシーを変えても、すでに決まった返金額は変わりません。ガイド都合のキャンセルは常に全額返金です。

決済：「7日の壁」で設計を作り直した

当初は「予約リクエストの時点でカードの与信枠だけ確保し、ガイドが承認したら確定する」方式で考えていました。ところが、与信枠の確保は約7日で期限が切れます。1か月先のツアーの予約では、この方式が使えません。

そこで、リクエスト時にはカード情報だけを安全に保存しておき、ガイドが承認した時点で課金する方式に作り直しました。空きがある日程は即時予約でその場で課金します。売上からは手数料を差し引いてガイドへ分配する形で、決済サービスのStripeが用意しているマーケットプレイス向けの仕組み（Stripe Connect）を使っています。

決済サービスの審査も設計に影響します。承認制だけだと、審査の担当者が決済画面までたどり着けません。そのため、即時予約を先に作りました。「審査を通るための画面」も要件のうちです。

架空のデータを、実績に見せない

公開前のサイトには、動作確認のためのサンプルのツアーやレビューが入っています。一度、そのサンプルの数字（平均評価など）がトップページで実績のように見えてしまっていたことに、自分たちで気づきました。

いまは設定を1か所切り替えるだけで、全ページに「プレビュー」の帯が出て、数字には「SAMPLE」と表示され、検索エンジンにも登録されないようにしています。検索結果に星の評価を出すためのデータも、サンプルの間は出しません。

テスト：人がやる操作を、ブラウザごと自動で再現する

決済まわりは単体テストで確認しています（手数料の分配、返金額が後から変わらないこと、即時予約とリクエスト制の切り替わり、他人の決済画面には入れないこと、など）。

画面の流れは、実際のブラウザを自動で操作するテスト（E2Eテスト）で確認しました。新規登録 → ガイド応募 → エリア選択 → 面接待ち → 承認 → 本人確認済み → 公開プロフィール表示、の7項目がすべて通ることを確かめています。

いまの状態（正直に）

• サイトはプレビューとして公開中です。掲載されているツアー・ガイド・レビューはすべてサンプルで、実際の取引はまだありません。
• 決済は、仕組みは実装済みで、本番の決済キー待ちです。
• 画面は英語のみです。外貨での概算表示はありますが、請求は円です。
• 利用規約・プライバシーポリシー・特定商取引法の表記は用意していますが、法律の専門家のレビューはこれからです。

実績記事で「完成しました」と書くのは簡単ですが、発注を考えている方にとって役に立つのは、どこで何に時間がかかるかのほうだと考えて、途中の状態のまま書いています。

マッチング・予約サービスを発注する前に、決めておくこと

Tabitoで実際に設計を左右したのは、機能の多さではなく次の5つでした。発注前にこの5つが決まっていると、見積もりのぶれが小さくなります。

• お金の流れ：誰が誰にいくら払い、運営はいつ手数料を受け取るのか。予約から当日までの日数も含めて決める
• キャンセルと返金：何日前まで何％返すのか。ポリシーを後から変えたとき、既存の予約はどうなるのか
• 信用の担保：本人確認、資格の確認、レビューを誰が書けるか、通報されたら誰が何をするか
• 法律の確認：業法（旅行業、人材紹介、古物など）にかからない範囲をどこで線引きするか
• 公開前の見せ方：サンプルデータのまま公開するのか、実データがそろってから公開するのか

機能は後から足せます。お金と信用の設計は、後から変えるほど高くつきます。