予約システム開発を新規事業で始める前に決めること
予約サービスを新規事業として立ち上げるとき、予約システムの開発では「予約の対象」「関わる人の役割」「予約のルール」の3つを最初に決めておくと、後からの手戻りを減らせます。この記事では、この3つに外部サービスとの連携、データの持ち方を加えた5項目を順に整理します。あわせて、決めきれない部分を動くプロトタイプで確かめる考え方も紹介します。
予約サービスは「予約画面」だけでは事業にならない
予約サービスの新規事業というと、日時を選んで申し込む画面を思い浮かべがちです。ところが、実際に事業として動かすには、画面の裏側にある「ルール」のほうが重要になります。
たとえば、次のような問いに答えが出ていないと、画面を作り始められません。
- 何を予約してもらうのか(時間、人、場所、物など)
- 予約は誰が確定させるのか(利用者か、提供者か)
- 直前の変更やキャンセルは、どこまで認めるのか
- 同じ枠に2人が同時に申し込んだら、どうするのか
これらは技術の話に見えて、実は事業の設計そのものです。予約システムは、その事業のルールをコードにしたものだといえます。
だからこそ、新規事業では「システムを作る前に、ルールをどこまで決めるか」が問われます。ただし、すべてを机上で決め切る必要はありません。決めておくべきことと、動かしながら確かめることを分けるのが現実的です。この記事では前者を「最初に決めること」として5つに整理します。
予約サービスには、飲食店や美容室のように提供者が自分の枠を売るもの、複数の提供者と利用者をつなぐもの、設備やスペースを貸し出すものなど、さまざまな形があります。形によって論点は変わるため、どの形に近いのかを意識しながら読み進めてください。複数の提供者と利用者をつなぐ形は、マッチングの要素も含みます。その場合はマッチングサービス開発の進め方|最初に決める5つのこともあわせて参考になります。
最初に決めること①:何を「予約」の対象にするか
最初に決めたいのは、予約の対象です。ここが曖昧なまま進むと、データの作りや画面の流れが後から大きく変わります。
時間の枠か、人か、場所か、物か
予約の対象は、大きく次のように分けられます。
- 時間の枠:セミナーやレッスンのように、開催日時と定員が決まっているもの
- 人(担当者):美容師、講師、コンサルタントなど、特定の人の時間を押さえるもの
- 場所・設備:会議室、撮影スタジオ、駐車場など、使える場所を押さえるもの
- 物:レンタル品や機材など、数量のあるものを貸し出すもの
多くのサービスは、これらを組み合わせて成り立っています。たとえば「担当者の時間」と「施術する部屋」の両方が空いていて初めて予約できる、という形です。この場合、システムは2つの空き状況を同時に見て判断する必要があります。
対象が1種類か複数の組み合わせかで、開発の難しさは大きく変わります。最初のサービスでは、できるだけ対象を1種類に絞ると、検証しやすくなります。
1つの予約が何を占めるか
次に決めたいのが、1つの予約が「どれだけ」を占めるかです。具体的には次の点です。
- 所要時間は固定か、メニューによって変わるか
- 予約と予約の間に、準備や片付けの時間(バッファ)が必要か
- 定員が複数ある場合、1回の予約で何人分まで申し込めるか
- 営業時間、定休日、臨時休業をどう扱うか
所要時間が固定であれば、枠の計算はシンプルです。メニューごとに所要時間が違う場合、「次の予約が入れられるか」の判断が複雑になります。
特に見落としやすいのがバッファです。現場では当たり前に取っている準備時間が、システム上の枠には入っておらず、運用が回らなくなることがあります。立ち上げ前に、現場の動きを1日分、時間順に書き出しておくと、抜けに気づきやすくなります。
最初に決めること②:誰が何をするか
予約サービスには、少なくとも2種類の人が関わります。予約する人(利用者)と、予約を受ける人(提供者)です。さらに、サービス全体を運営する人(運営者)がいる形もあります。
役割ごとにできることを書き出す
役割ごとに、できることを一覧にします。たとえば次のような形です。
| 役割 | 主にやること |
|---|---|
| 利用者 | 空き状況を見る、予約する、変更・キャンセルする |
| 提供者 | 自分の空き枠を登録する、予約を確認する、承認や断りをする |
| 運営者 | 利用者・提供者の管理、問い合わせ対応、予約の手動修正 |
この表を作ると、「誰の画面を作るのか」が見えてきます。新規事業の最初の段階では、すべての役割の画面を整える必要はありません。たとえば運営者が提供者の代わりに枠を登録するなら、提供者向けの画面は後回しにできます。
どの画面を最初に作り、どの作業を運営側の手作業で補うかは、費用や期間に直結する判断です。管理側の画面をどこまで作るかについては、新規事業の管理画面開発|最初に作る範囲の見極め方で詳しく整理しています。
会員登録を求めるタイミング
もうひとつ決めたいのが、会員登録のタイミングです。予約の前に登録を求めると、手続きの手間で離脱する人が出る可能性があります。一方、登録なしで予約できるようにすると、後から利用者を特定しにくくなります。
この判断は、事業の狙いによって変わります。リピート利用を重視するなら、予約完了後に会員登録を促す形もあります。名前と連絡先だけで予約できる形にして、まず予約の数を確かめる選び方もあります。どちらが正しいというより、何を確かめたいのかで決める項目です。
最初に決めること③:予約のルール
予約サービスの使い勝手と運用の負担は、ルールの決め方でほぼ決まります。ここは事業側の判断が中心になるため、開発に入る前に整理しておきたい部分です。
即時確定か、承認制か
予約の申し込みを受けたとき、すぐに確定させるのか、提供者が承認してから確定させるのかを決めます。
- 即時確定:利用者はすぐに結果がわかる。提供者は予定を管理しやすい準備が必要
- 承認制:提供者が内容を見て判断できる。利用者は確定までの待ち時間が生じる
承認制にする場合は、さらに「いつまでに返事をするか」「返事がなければどうなるか」も決めておきます。期限切れで自動的に断りにするのか、運営者に通知するのかによって、必要な機能が変わります。
変更・キャンセル・無断欠席の扱い
次に、予約後の動きを決めます。決めておきたい項目は次のとおりです。
- 利用者がキャンセルできるのは、いつまでか
- 期限を過ぎたキャンセルは、受け付けないのか、受け付けて記録だけ残すのか
- 日時の変更は、キャンセルと新規予約として扱うのか、変更として扱うのか
- 連絡なしの欠席(いわゆるノーショー)があった場合、どう記録し、どう対応するか
キャンセル料を設ける場合は、サービスの種類や契約の内容によって関係する法令が異なります。料金の取り方や表示の方法は、事業を始める前に専門家へ確認しておくと安心です。
「変更」をどう扱うかは、見落とされがちな論点です。変更を独立した機能にすると、システムとしては複雑になります。最初はキャンセルと再予約で対応し、利用の様子を見てから変更機能を作る、という選び方もあります。
二重予約をどう防ぐか
予約システムで最も避けたいのが、同じ枠に2件の予約が入ってしまう「二重予約」です。ほぼ同時に2人が同じ枠を選んだとき、片方を確実に断る仕組みが必要になります。
これは、データを保存するときに「その枠がまだ空いているか」を確認し、空いている場合だけ確定する、といった設計で防ぎます。技術的な話ですが、事業側で決めておきたいのは次の点です。
- 申し込み途中の枠を、一定時間だけ仮押さえするか
- 仮押さえする場合、何分で解除するか
- 二重予約が起きてしまった場合、誰がどう連絡するか
仮押さえの時間は、短いと入力中に枠が消えてしまい、長いと他の人が予約できない時間が増えます。また、予約サービスの外(電話や店頭)でも予約を受ける場合は、その予約をシステムにどう反映させるかも決めておく必要があります。システムの外で受けた予約が反映されないと、二重予約の原因になります。
最初に決めること④:外部サービスとのつなぎ方、データの持ち方
予約システムは、単体で動くことは少なく、決済、通知、カレンダーなどと組み合わせて使われます。どこまでを自分たちで作り、どこから既存のサービスを使うかを早めに決めると、開発の範囲が見えやすくなります。
決済・通知・カレンダー連携
代表的な連携先は次の3つです。
- 決済:予約時に支払うのか、当日に支払うのか。事前決済にするなら、決済代行などの外部サービスを使うかどうか
- 通知:予約完了、前日のお知らせ、キャンセルの連絡を、メールで送るのか、他の手段も使うのか
- カレンダー:提供者や利用者が使っているカレンダーと、予約情報を同期するのか
決済は、扱う情報の重みも開発の難しさも大きい部分です。自分たちで作るか外部サービスを使うかの考え方は、新規事業の決済システム開発|外部サービスと自作の分け方で整理しています。
通知は、軽く見られがちですが、予約サービスでは重要です。予約の確認や前日のお知らせが届かないと、欠席が増える原因になります。どのタイミングで何を送るかは、運用の仕組みとして早めに決めておきたい項目です。
カレンダーとの同期は便利ですが、作り込むと工数が増えます。最初は予約情報を一覧で見られれば足りるのか、同期が事業の価値そのものなのかを見極めましょう。
持つデータと個人情報
予約サービスは、氏名、連絡先、利用履歴など、個人に関する情報を扱います。サービスによっては、健康状態や家族構成など、より慎重な扱いが必要な情報を聞くこともあります。
最初に決めておきたいのは次の点です。
- 予約のために、本当に必要な情報は何か(聞きすぎない)
- 予約の履歴を、どのくらいの期間、どう残すか
- 利用者から削除を求められたとき、どう対応するか
- 誰が、どの情報まで見られるか(権限の分け方)
必要な情報を絞るほど、管理の負担もリスクも小さくなります。個人情報の扱いは、法令の確認も含めて設計の前に整理しておくべき項目です。詳しくは新規事業の個人情報とシステム設計|設計前に確認する点も参考にしてください。
また、予約データは事業の判断材料になります。どの時間帯が埋まりやすいか、どのメニューが選ばれるか、どのくらいの人が再予約するかといった数字は、後から追加で取ろうとしても、過去の分は取れません。最初のデータの持ち方は、あとで分析できる形にしておくことが大切です。データの持ち方については、新規事業のデータ設計|最初に決めたい5つの持ち方で整理しています。
最初に作る範囲と、動くもので確かめる方法
ここまでの項目をすべて作り込もうとすると、立ち上げまでの時間も費用も大きくなります。新規事業では、需要があるかどうかを確かめる前に、大きな投資をするのは避けたいところです。
最初に作る範囲を絞る
最初の版で確かめたいのは、「予約サービスとして使ってもらえるか」です。そのために必要な機能と、後回しにできる機能を分けます。
最初に必要になりやすい機能は、次のようなものです。
- 空き状況の表示と、予約の申し込み
- 予約の確認(利用者・提供者の双方)
- キャンセルの受け付け
- 予約完了の通知
- 運営者が予約を確認・修正できる最低限の画面
一方、次のような機能は、利用の様子を見てから判断しても遅くありません。
- 複雑な料金設定やクーポン
- 予約の変更機能
- カレンダーとの自動同期
- 利用者向けのマイページの充実
- 細かな分析画面
機能の絞り方は、MVP開発の機能の絞り方|最初に作るものと後回しの基準で基準を紹介しています。MVP(Minimum Viable Product)とは、最低限の機能で市場の反応を確かめるための最初の製品のことです。
なお、既存の予約ツールで足りる範囲であれば、まずそれで需要を確かめるのも合理的な選択です。独自のシステムを作る価値があるのは、予約のルールや体験そのものが事業の差になる場合です。ノーコードとAI駆動開発の違いは、AI駆動開発とノーコードの違い|新規事業に合うのはどちらで比較しています。
何が分かれば次に進むのかを決める
最初の版を出す前に、「何が分かれば次に進むのか」を決めておきます。予約サービスであれば、たとえば次のような指標が考えられます。
- 予約の画面を見た人のうち、予約を完了した人の割合
- 一度予約した人が、もう一度予約した割合
- キャンセルや無断欠席の発生状況
- 提供者側が、運用を負担に感じていないか
数字の目安は事業によって異なるため、ここで一般的な基準を示すことはできません。大切なのは、始める前に「この数字なら続ける、この数字なら見直す」を関係者で合意しておくことです。判断基準の作り方は、MVP検証の指標を先に決める方法|判断基準の作り方で解説しています。
動くものを見ながら、ルールを調整する
予約のルールは、言葉で決めたつもりでも、実際に触ると「この流れは使いにくい」「この場合の扱いが決まっていない」と気づくことが多い部分です。たとえば、キャンセル期限を過ぎた予約を画面でどう見せるか、承認待ちの予約が利用者にどう表示されるかなどは、実物を見て初めて具体的に議論できます。
そのため、仕様書で詳細まで固めるより、動く試作を先に作り、触りながら調整するほうが、認識のズレを減らせます。この考え方は、システム開発の認識のズレを防ぐ、実物を見ながらのすり合わせや新規事業のアイデア検証方法|動くシステムで確かめる手順でも触れています。
また、試作ができたら、実際の利用者や提供者に触ってもらうことも大切です。質問の仕方や観察の観点は、プロトタイプのユーザーテスト|新規事業での確かめ方と質問が参考になります。
既存の事業を持つ会社が予約サービスを始める場合は、既存のシステムとつなぐのか、切り離して作るのかも判断が必要です。早く確かめたいときは、切り離して作るほうが進めやすい場合があります。詳しくは新規事業は既存システムと切り離して作る理由と進め方をご覧ください。
まとめ
予約サービスを新規事業で立ち上げるとき、システムで最初に決めておきたいのは、次の5つです。
- 予約の対象:時間、人、場所、物のどれを予約するのか。1回の予約が何を占めるのか
- 役割:利用者、提供者、運営者が、それぞれ何をするのか
- 予約のルール:即時確定か承認制か、キャンセルや変更の扱い、二重予約の防ぎ方
- 外部サービスとの連携:決済、通知、カレンダーをどこまで作り、どこから外部を使うのか
- データと個人情報:何を、どのくらい、誰が見られる形で持つのか
あわせて、最初の版で作る範囲を絞り、「何が分かれば次に進むのか」を先に決めておくことが大切です。すべてを机上で決め切ろうとせず、決めきれない部分は動くもので確かめながら調整するほうが、手戻りを小さくできます。
私たちJustFitは、株式会社LEGAREAが運営する完全オーダーメイドの受託開発サービスで、「先に作って、後から決める」という考え方のもと、構想をもとに約1ヶ月で動くプロトタイプを開発します。予約サービスのように、システムそのものが事業の形になる新規事業を得意としており、仕様が固まる前の段階でもご相談いただけます。詳しくはJustFitのサービス紹介をご覧ください。