予約管理システムは、サーカスの現場でどう変わるのか

KAGURA PROJECT | 身体知と組織哲学

2026年7月8日 05:28

ある公演から、団体予約をGoogleフォームとスプレッドシートで受けることにした。

それまでは、電話やメールで予約を受けていた。

　団体名を聞く。
　希望日を聞く。
　人数を聞く。
　連絡先を確認する。
　変更があれば、また書き換える。
　キャンセルがあれば、また探す。

一件ずつ見れば、難しい作業ではない。

けれど、電話で聞いて、こちらが書き取る形には取りこぼしがある。

僕は耳が悪い。
相手の団体名、人数、希望日時、電話番号を、聞きながら正確に拾うことには負荷がある。

お客様に直接書いてもらえるなら、その方が正確なことがある。

聞き取るのではなく、書いてもらう。
その場で処理するのではなく、一度プールに溜める。
溜まった予約を、あとから確認し、状態を分け、必要なものだけ人間が見る。

そういう受け方にしたかった。

試しに、Googleフォームとスプレッドシートで受ける形を提案した。

すると、漏れは減った。
受けたログも残る。
一覧でも見やすくなった。

ただ、それで終わりではなかった。

フォームに入った情報は、まだ現場で使える予約ではなかった。

予約管理システムという仕組みは、すでにいろいろな場所にある。

Googleフォームとスプレッドシートで予約管理を作る事例もある。
Google Apps ScriptとGoogleカレンダーをつなぐ事例もある。
フォーム送信後の流れを、記録、受付、通知、担当、状態、次アクションに分ける考え方もある。

今回見たかったのは、その仕組みをサーカスの団体予約に置いたときの変形だった。

既にある仕組みを、サーカスの団体予約に置く。
どこがそのまま使えて、どこで形が変わるのか。

そこを見たかった。
以下は、予約管理システムの考え方を学び、課題を解決するための再実装するなかで得た学びだ。

フォーム回答は入口でしかない

団体予約を受けるために、Googleフォームを作る。

団体名、希望日、希望時間、人数、連絡先。
必要な項目を並べれば、予約情報は集まる。

けれど、フォームに入った情報は、まだ現場で使える予約ではない。

　希望日時の表記ゆれがある。
　人数の未入力がある。
　担当者情報の不足がある。
　同じ団体からの重複送信がある。
　あとから人数変更が来る。
　日付変更が来る。
　キャンセルも来る。

この状態をそのまま現場に渡すと、人間が毎回読み解くことになる。

その状態では、予約を管理しているというより、回答一覧を読解している。

フォームは入口であって、現場ではない。

予約は、公演回の上に乗る

サーカスの団体予約は、単独では成立しない。

必ず、公演回の上に乗る。

　その日に公演があるのか。
　その時間に公演があるのか。
　休演日ではないか。
　団体受付不可の枠ではないか。
　上限人数を超えていないか。

この受け皿になるのが、公演回マスターである。

公演回マスターには、公演日、開演時刻、公演区分、受付状態、団体受付可否、団体上限人数などを置く。

予約管理システムをサーカスに持ち込むと、まずここで形が変わる。

予約は、空いている時間へ自由に入るわけではない。
公演回という、すでに決まっている枠の上に乗る。

ただ、公演回に乗れば終わりではない。

サーカスの会場は、常設劇場とは違う。

　仮設テントである。
　客席の区画があり、団体席の取り方があり、当日の入り方がある。
　バスでまとまって到着する団体もある。
　人数が数名変わることもある。
　受付で止まると、入口の流れが詰まる。

座席数だけを見れば入る。
けれど、入場のタイミング、受付の処理、誘導の流れまで含めると、同じ人数でも現場の重さは変わる。

だから、サーカスの団体予約では、
予約人数が上限内かどうかだけでは足りない。

その団体を、その回の前後の流れの中で迎え入れられるかを見る必要がある。

予約管理マスターへ置き直す

フォームから入った情報は、予約管理マスターへ置き直す。

フォーム回答には、入力された内容がある。
予約管理マスターには、現場で扱う状態を持たせる。

　予約ID。
　公演ID。
　団体名。
　人数合計。
　請求対象人数。
　予約状態。
　要確認理由。
　確認メモ。
　変更履歴。
　カレンダー同期状態。
　受付状態。
　来場人数。
　実績反映状態。

ここで、人数は二つに分かれる。

人数合計は、実際にその回へ乗る人数である。
受け入れ可能か、座席や上限に収まるかを見るための人数である。

請求対象人数は、料金計算に使う人数である。
無料招待、介助者、当日変更、確認中の人数がある場合、そこにいる人数と請求する人数は一致しないことがある。

同じ「人数」でも、受け入れを見る人数と、請求を見る人数は役割が違う。

だから、人数合計と請求対象人数を分けて持つ。

予約状態は、予約がどこまで進んでいるかを見るために使う。

　未確認。
　確認済み。
　変更中。
　キャンセル。
　当日受付対象。
　来場済み。
　実績反映済み。

同じ団体名があっても、状態が違えば扱いは変わる。

受付状態は、当日にその団体を迎え入れたかを見る。
来場人数は、実際に来た人数を残す。
実績反映状態は、その数字をあとから集計してよいかを見る。

予約管理マスターは、予約を受けた時点で終わる表ではない。
当日受付と実績管理までつなぐための表である。

　未入力は、未入力として残す。
　要確認は、要確認として分ける。
　重複は、重複として見えるようにする。
　変更は、上書きで消さずに履歴へ逃がす。

照合で止めるもの、カレンダーで見えるもの

予約管理マスターと公演回マスターを照合すると、ルールで止められるズレが出る。

　予約があるのに、公演回がない。
　休演枠に予約が乗っている。
　団体受付不可の回に予約が入っている。
　人数合計が、団体上限人数を超えている。

これは、マスター同士の照合で検出する。

一方で、カレンダーは別の役割を持つ。

カレンダーは、正誤を判定するためだけのものではない。
時間の上に、現場の負荷を置くためのものでもある。

上限人数を超えていなくても、
同じ日に団体予約が複数重なると、受付や誘導は重くなる。

同じ人数でも、
午前に来るのか、午後に来るのか。
前後に別の団体があるのか。
変更前の予定が残っていないか。

それは、表の中では見えにくい。

照合は、条件に合っているかを見る。
カレンダーは、その条件を満たした予約が、時間の上で現場に乗るかを見る。

照合は、ルールでズレを出す。
カレンダーは、時間の上に負荷と重なりを出す。

予約は、実績になるまで終わらない

予約は、フォームに入力された時点では終わらない。

入力された予約は、まだ希望である。
確認されて、予約管理マスターに置かれる。
公演回と照合される。
変更があれば履歴に残る。
カレンダーに出される。
当日、受付状態が更新される。
実際に来た人数が、来場人数として残る。
最後に、実績反映状態が更新される。

そこまで通って、ようやく実績になる。

　予約が入ったのか。
　確認済みなのか。
　変更中なのか。
　当日受付の対象なのか。
　来場済みなのか。
　実績として集計してよいのか。

それを、人の記憶ではなく、予約管理マスターの状態として残す。

だから、必要だったのは予約フォームだけではなかった。

予約が、入力から実績まで落ちずに通るための層だった。

詰まりには種類があった

実装中に、いくつかの詰まりが出た。

予約をカレンダーに出したかったのに、公演回を先にカレンダーへ出してしまった。
予約管理マスターに必要な列が見つからなかった。
時刻が、画面で見えている表示と違う形で処理された。

短時間にカレンダーイベントを作りすぎて、Google側の制限に当たった。
コードの貼り替え位置がずれて、構文エラーが出た。

これは、同じ種類の詰まりではなかった。

ひとつは、情報の設計上のズレだった。

予約とは何か。
公演回とは何か。
シートの列名を、どこまで運用上の契約として扱うのか。
表示されている値と、内部で処理される値をどう分けるのか。

ここには、コード以前の定義の問題がある。

もうひとつは、実装や環境の物理的な詰まりだった。

短時間にカレンダーイベントを作りすぎれば、Google側の制限に当たる。
コードの貼り替え位置がずれれば、構文エラーが出る。

自動化しようとしたことで、
情報の設計上のズレと、道具の制約が分かれて見えた。

作りたかったのは、通路だった

やろうとしていたのは、フォームを作ることだけではなかった。

　フォームから入った回答を、スプレッドシートへ移す。
　予約管理マスターで状態を持つ。
　変更履歴を残す。
　公演回マスターと照合する。
　カレンダーへ出す。
　当日、迎え入れる。
　終わったあと、実績として残す。

ここまでが必要だった。

入力欄を作っても、現場で扱える床ができたことにはならない。

床は、現場で情報を受け止める場所である。
通路は、入口に入った情報を、その床まで落とさず運ぶための手順である。

ただ、通路は情報をきれいに運ぶためだけにあるわけではない。

　当日の人数変更。
　到着時間のズレ。
　受付での確認。
　実際に来なかった人。
　予定より増えた人。

そういうズレを、現場がその場で受け止められるようにするためでもある。

通路があることで、予約は固定された数字ではなく、
当日の現場で更新できる状態になる。

フォームから入った予約を、当日の迎え入れと実績管理まで通す。

やりたかったのは、その通路を作ることだった。