【ITニュース解説】The admin side of scheduling: booking states, a day-grouped calendar and honest no-show rates

VeloxonHubのようなオンラインスケジューリング製品は、ユーザーが予約を行うページに注目が集まりがちだ。しかし、システムエンジニアを目指す皆さんにとって知っておくべきは、予約が完了した後、その裏側でどのような処理が行われ、どのような管理がされているか、という点である。システム開発においては、単に機能を実装するだけでなく、その機能を効率的かつ正確に運用するための「管理側」の設計が非常に重要になる。この記事では、VeloxonHubの管理画面の裏側にある設計思想と具体的な実装について解説する。

まず、予約情報の管理方法について考える。VeloxonHubでは、1対1の通話（Appointments）と複数人向けのイベント（Events）という、性質の異なる二つの予約形態が存在する。これら種類の異なる予約を、実は「registrations_bookings」という一つのデータベースの表（テーブル）で一元的に管理している。データの一元管理は、システムのシンプルさを保ち、情報の整合性を高める上で非常に有効な手段である。この一つの表の中に、予約の状態（status）と支払い状況（payment_status）という二つの異なる情報を、それぞれ独立した項目として持たせているのが特徴だ。例えば、予約の状態が「承認待ち（pending）」や「確定済み（confirmed）」であっても、支払い状況は「無料（free）」であったり「未払い（unpaid）」であったりする。また、予約がキャンセルされたとしても、その予約が「存在しなかったこと」にはならない。このように、予約そのものの状況と支払いに関する状況を分けて管理することで、より詳細で柔軟な状態管理が可能になる。管理画面では、これらの二つの項目がそれぞれ表示され、予約の状態に応じて実行できる操作（アクション）が動的に決定される。例えば、「承認待ち」の予約には「承認する」というボタンが表示され、「確定済み」の予約には「チェックインする」というボタンが表示される。これらの操作は、管理者による手動での文字入力ではなく、常に決められた手順でシステムに命令（例えばウェブAPIを通じたPOSTリクエスト）を送り、自動的にデータベースの予約状態が更新される仕組みになっている。これにより、入力ミスを防ぎ、データの一貫性を保つことができる。

次に、管理画面でのカレンダー表示について説明しよう。管理者が「いつ、どんな予約が入っているか」を把握するためのカレンダーは、ただ予約を一覧表示するのではなく、いくつかの工夫が凝らされている。VeloxonHubの管理用カレンダーは、個々の予約（bookings）ではなく、「発生するイベント（occurrences）」を読み込んで表示する。これは、例えば「毎週水曜日の午前中に開催される会議」のような定期的なイベントや、「一度に複数人が予約可能なセミナー」のようなイベントの「枠」そのものに着目していることを意味する。各イベントの表示には、担当ホストの名前や、予約済み人数、そしてそのイベントの定員といった情報が分かりやすく示されている。例えば、「Maya Rahman · 42 booked / 100」といった表示で、誰が担当し、どれくらいの予約が入っているか一目でわかるようになっているのだ。また、クライアント側（利用者が予約する側）のカレンダーでは、表示される日付が利用者のタイムゾーンに合わせて「10月23日金曜日」のように自動的に変換され、日ごとにイベントがグループ化されて表示される。管理画面では、「今日から30日先まで」といった期間で表示されることが多く、これは特にイベントを運営する担当者にとって、「今日と明日、何が起こるか」といった直近の情報が月ごとの詳細なカレンダーよりも重要であるという実用的な視点に基づいている。

ホスト（イベントの主催者や担当者）が自身の空き時間をどのように管理するかも重要な点だ。VeloxonHubでは、ホストは具体的な「予約スロット」（例えば「10月23日14:00〜15:00」のような時間枠）を直接設定するのではなく、「可用性ルール」（AvailabilityRule）という形で自身の空き時間を定義する。このルールは、ホストのID、曜日（日曜日を0とする数字）、開始時刻、終了時刻、タイムゾーンといった情報から構成される。例えば、「毎週火曜日の午前9時から午後12時までと、午後2時から午後5時まで」といった複数の時間帯を、それぞれ別のルールとして設定できるため、「午前と午後で休憩を挟む」といった複雑な空き時間も柔軟に対応できる。これらのルールは、ホスト全体に適用される場合もあれば、特定の製品（イベントの種類など）にのみ適用される場合もある。そして、予約ページに表示される予約可能なスロットは、これらのルールに基づいてシステムが自動的に生成する仕組みになっている。これにより、ホストは一度ルールを設定すれば、個々のスロットを毎回手動で調整する手間が省け、システム側も常に最新の空き時間を正確に提供できるメリットがある。

さらに、ホストには専用のダッシュボードが提供されており、その表示内容は厳密な権限管理に基づいて決定される。システム内で「スケジューリングホスト」として登録されたチームメンバーは、バックエンド（サーバー側）で「main.host_dashboard」という特定の権限が付与される。この権限情報はフロントエンド（ユーザーインターフェース側）で利用され、ログインしたユーザーがホストであるかどうかを判断する。もしホストが他の管理権限を持たない場合、ログイン後に直接ホスト専用のダッシュボードに案内され、他の管理機能は表示されないようにナビゲーションが制御される。このダッシュボードでは、ホスト自身のセッション（開催したイベント）、平均評価、レビュー、承認待ちの予約、そして無断キャンセルといった、自身の業務に関連する情報のみが表示される。重要なのは、これらの表示内容が、UI側でフィルタリングされるのではなく、サーバー側で「このユーザーはホストなので、この情報だけを提供する」というように、そのユーザーの役割に基づいて厳密に決定される点だ。これはセキュリティの観点からも非常に重要であり、不正なデータアクセスや情報漏洩のリスクを低減する。ホスト自身が空き時間ルールを編集する機能も、このセルフサービスモードのダッシュボード内で提供され、自身のルールを直接更新できる仕組みになっている。

最後に、分析機能、特に無断キャンセル率の算出方法について見てみよう。VeloxonHubの分析機能では、イベント、予約、ホストという三つの視点から、データベースのデータを集計して様々な指標を算出している。ここで特に注目すべきは、無断キャンセル率（no_show_rate）の計算方法だ。この計算式では、無断キャンセル数を、単に全予約数で割るのではなく、「実際に参加できたはずの人数」（つまり、「参加済み（attended）」と「無断キャンセル（no_show）」の合計）で割っている。なぜこのような工夫が必要なのだろうか。それは、例えば開催日の数日前にキャンセルされた予約や、まだ開催日が来ていない未来の予約を分母に含めてしまうと、無断キャンセル率が不当に高く見えてしまうからだ。実際のビジネスにおいて、キャンセルは無断キャンセルとは性質が異なるものであり、まだ開催されていない予約は無断キャンセルになる可能性すらない。このように分母を意図的に厳選することで、製品やサービスの運用状況をより正確に把握し、適切な改善策を立てるためのデータが得られる。さらに、イベント収益は支払い済みから返金済みを差し引いた純収益、予約収益は支払い済みの予約に基づいて計算され、ホストごとのビューではセッション数、参加者数、利用率（キャンセルされなかった予約の比率）なども表示され、どのホストが多くのイベントを担当しているか、貢献度が高いかといった情報も把握できる。

これらの設計から学ぶべき教訓はいくつかある。予約の状態と支払い状況は独立した項目として管理すること。管理者が手動でステータスを変更するのではなく、システムによるアクションを通じて更新させることでデータの整合性を保つこと。ホストには固定されたスロットではなく、柔軟なルールを与え、それに基づいてシステムがスロットを生成すること。そして、ホストのダッシュボードなどの表示内容は、ユーザーインターフェース側でのフィルタリングに頼らず、サーバー側でユーザーの権限に基づいて厳密に制御すること。さらに、分析指標、特に無断キャンセル率のような重要な数値の分母は、その指標が本当に何を測りたいのかを考慮して意図的に選び、明確に定義することが、正確なデータに基づいた意思決定に繋がる。これらの原則は、システムエンジニアを目指す皆さんにとって、将来どのようなシステムを設計・開発する上でも役立つ重要な考え方となるだろう。