「予約管理で1日のうち何時間使ってると思いますか」
オーナーがそう言ったとき、私はスマートフォンのLINEトーク画面を想像した。「この日は空いていますか」「その時間は埋まっています」「では○日の▲時はどうでしょう」というやりとりが、画面の外まで延びていく光景を。
ある地方都市で片づけの専門家として活動するオーナーから相談を受けたのは2026年の春だ。片づけを通じて暮らしを整えるコーチングは、対面で丁寧に届けるサービスだ。しかしその「前」の予約管理が、時間を奪い続けていた。
「LINEで完結させたい」という要望の重さ
最初の要件定義はシンプルだった。「予約の受付をLINEだけで完結させたい」。
しかしこの一言に、重要な判断が含まれていた。既存のLINE公式アカウントがある。お客さんはLINEを使っている。新しいアプリを入れてもらうのはハードルが高い。予約サイトを別途開設して「そちらから予約してください」と案内するのも摩擦が生まれる。
「LINEで完結」という言葉は、「お客さんに何も変えてもらわない」という意味でもあった。
3つの設計原則
どんなシステムも、最初に決めることが多いほど後から迷う。予約システムは最初に3つだけ決めた。
お客さんはLINEだけで完結する。新しいアプリ・アカウント・ウェブサービスは案内しない。
管理はスプレッドシートで完結する。オーナーが自分でデータを確認・修正できる。私がいなくても動く。
月額コストをゼロに近づける。予約管理の専用SaaSは月数千〜数万円する。そのコストを払い続けることの価値を、個人コーチのサービスに見出すのは難しい。
この3点を決めると、技術の選び方は自ずと決まった。
サービスの種類が設計を複雑にした
オーナーが提供するサービスは1種類ではない。「暮らしの作戦会議」（無料・60分）から、フルの片づけレッスン（5時間）まで幅がある。サービスによって所要時間が違うため、カレンダーに入れる終了時刻も変わる。
最初は4サービスで設計した。後から「未来デザインセッション」と「人生を整える対話セッション」が加わった。
このとき、サービスをコードに直書きしていたら修正箇所が散らばる。最初からマッピングテーブルで管理していたため、サービスの追加は1行のオブジェクト追記で終わった。
const services = {
'1': { name: '暮らしの作戦会議（無料相談）', duration: 60 },
'2': { name: '片づけレッスン', duration: 300 },
'3': { name: '片づけ講座', duration: 90 },
'4': { name: '片づけ体験セミナー', duration: 120 },
'5': { name: '未来デザインセッション', duration: 60 },
'6': { name: '人生を整える対話セッション', duration: 60 },
};「将来変わるかもしれない」という箇所を設計段階で識別しておくことは、後から自分を助ける仕事だ。
予約枠を在庫として管理する
予約管理の仕組みを設計するとき、「これは在庫管理と同じだ」という見立てが役に立った。
飲食店がランチの席数を在庫として管理するように、コーチングの予約枠も在庫だ。枠があれば予約できる。枠がなければ断る。二重予約（=在庫のマイナス）は起こしてはいけない。
スプレッドシートの1行が1つの枠を表す。日時・サービス種別・予約済みフラグ・予約者情報が列に並ぶ。予約が確定すると、GASがその行の「予約済みフラグ」をONにする。
二重予約を防ぐための排他制御も入れた。GASのLockServiceを使って、複数のリクエストが同時に同じ枠を処理しないようにする。これについては別の記事で詳しく書く。
予約が入った瞬間、LINEに通知が届く
このシステムの「気持ちいい」部分を一つ挙げるとすれば、予約確定の瞬間だ。
お客さんが予約フォームを送信すると、GASがLINE Messaging APIを通じて即座に通知を送る。オーナーのLINEに「○月○日 ○時から 片づけレッスン、▲▲様が予約しました」という通知が届く。
これはオーナーの「予約が入った」という体験を、スプレッドシートを開くよりもずっと早く届ける。便利さとはレスポンスの速さでもある。
*次回は「LIFFでLINE User IDを自動取得する——なぜフォームに入力欄を作らなかったか」*
*シンプルシステム株式会社 代表 伊藤勝彦*