前回までのあらすじ
「半年・500万円」と言われて諦めていた予約システムを、お盆休みにClaudeと作り始めた話を書いています。
前回は、公開後の整備について書きました。作った本人には不具合が見つけられないこと、そして「人は忘れる・間違える」を前提に仕組みを作るという話です。
今回は、その続きです。
予約システムが、画面の中だけの話ではなくなりました。
解決できていなかった、鍵の問題
第7話で、メールでは解決できなかった課題について書きました。
解錠パスワードの問題です。
私たちのスペースは、部屋ごとに入室方法が異なります。これまでは解錠番号を定期的に更新し、その都度お客様に通知していました。
ただ、本当の課題は通知ではありませんでした。
当日、解錠パスワードの入れ方が分からない。 この物理的なトラブルが、時々起きるのです。そのたびに電話で説明することになります。
特に、年齢層が高いお客様にこの傾向がありました。機器の操作性が悪いというより、機械に対する心理的な抵抗が原因ではないかと推測しています。
だとすれば、通知の仕組みをどれだけ磨いても解決しません。
課題を解決するのではなく、課題そのものを消す。 そのために取り組んだのが、今回のSwitchBot連携です。
なぜSwitchBotだったのか
スマートロックは、他にもいくつも選択肢があります。
その中でSwitchBotを選んだ理由は、まず物理的なものでした。
鍵の形状が、さまざまなパターンに対応している。
これが最大の理由です。レンタルスペースは、もともと別の用途だった物件を使っていることが多く、扉も鍵も施設ごとにバラバラです。「うちの鍵には付けられませんでした」では話になりません。
どれだけシステム側が優秀でも、扉に付かなければゼロです。
そしてもうひとつ、鍵だけでなく、さまざまなデバイスに広げられるという点も大きな理由でした。
実際、私たちはすでにSwitchBotシリーズの他の製品も使っています。
アルベホール名古屋では、同じSwitchBotシリーズの防犯カメラが活躍しています。
東別院の施設では、入退室で不正が起きないよう、入り口に人感センサー付きのSwitchBotカメラを設置しています。
このように横展開できる強みがあったことが、SwitchBotを選んだ決め手になりました。
調べていくと、SwitchBotはさまざまなAPIを持っていることも分かりました。かなり柔軟な対応ができることが見えてきたので、採用を決めました。
解錠は、予約時間の5分前
では、どういう仕組みで動くのか。
解錠は、予約時間の5分前です。
お客様が到着される頃には、すでに鍵が開いています。
パスワードを送る必要がありません。入力していただく必要もありません。お客様は、ただ扉を開けて入るだけです。
これまで電話で説明していたトラブルは、そもそも発生しなくなります。
実は、こちらの悩みも解決しました
そしてもうひとつ、私たちがずっと悩まされてきた問題があります。
予約した時間よりずいぶん早く到着して、準備を始めてしまうお客様です。
空いているなら入ってもいいだろう、当然無料だろう。そう考えていらっしゃる方が、実際に少なくありません。
悪意があるわけではないので、こちらとしても指摘しづらい。その場にスタッフがいなければ気づけませんし、いたとしても言いにくい話です。
自動解錠にすると、この問題が説明せずに解決します。
5分前まで鍵が開かないので、早く来ても入れません。
ルールを伝えて守っていただくのではなく、そもそも成立しない形にした。誰も嫌な思いをせずに済みます。
そして、注意する私たちの側にもストレスがかかります。 言わなければ示しがつかない。でも言えば、その日の空気が悪くなる。どちらを選んでも後味が残ります。
それを回避できたことは、本当に大きいと思っています。
機械的に管理できるようになったことで、私たちも安心して毎日のオペレーションができるようになりました。
お客様のストレスも、私たちの手数も、同時に減りました。
難しかったのは、施錠のほうでした
一方で、頭を悩ませたのが施錠です。
理想を言えば、お客様が完全に退出してから閉めたい。
しかし、これを正確に判定するのは、なかなか難しい。まだ室内にいらっしゃるのに施錠してしまっては、話になりません。
そこで、施設の性格ごとに条件を分けることにしました。
営業時間のある施設
営業時間が決まっている施設については、営業終了時刻から一定時間後に施錠する形にしました。
たとえば最終22時までの施設であれば、22時30分に施錠します。
24時間利用できるスペース
問題は、24時間使えるスペースです。ここには「営業終了」という基準がありません。最終利用者が出た後という判定も成立しません。
そこで、まったく別の考え方にしました。
鍵を開けてから1時間後に、必ず施錠する。
利用時間とは連動させていません。解錠からの経過時間だけで切ります。
この方式だと、利用者は出入りのたびに鍵を開ける必要があるかもしれません。 少し手間をおかけすることになります。
それでも、確実に施錠されるほうを選びました。開けっ放しのリスクをゼロにできるからです。
前回書いた考え方と、同じです。人は閉め忘れるものです。 気をつけていただくのではなく、勝手に閉まる形にしました。
施錠時刻は、スペースごとに設定できます
なお、施錠の時刻はスペースごとに自由に設定できるようにしています。
施設によって営業時間も使われ方も違うので、ここは共通にできませんでした。
全スペースには入れません
ひとつ書いておくと、SwitchBotの機能をすべてのスペースに設置する予定はありません。
対象は、スタッフが常駐していない施設が中心です。
人がいる施設であれば、その場で対応できます。無理に自動化する必要はありません。
そして予約システム側も、スペースごとに対応を分けられる仕組みにしています。全部を同じにしない、という設計です。
一番怖かったのは「開かない」ことでした
この連携は、決済と同じくらい慎重に進めました。ミスが許されないオペレーションだからです。
想定されるトラブルは、いくつかあります。鍵が開かない。鍵が閉まらない。通信が切れる。
この中で、私が最も警戒したのは「開かない」ことでした。
理由は、緊急度がまったく違うからです。
閉まらないのは、後で何とでもできます。 気づいた時点で対応すればいい。もちろん放置はできませんが、時間的な猶予はあります。
しかし、開かないのは即座に困ります。
お客様は時間どおりに来られます。そしてその時間から、すでに料金が発生しています。入れなければ、その場で電話がかかってきて、誰かが駆けつけることになる。
無人運営のために入れた仕組みが、逆に人を呼ぶことになってしまいます。
だから、納得がいくまで何度もテストを繰り返し、調整してから設置しました。
決済のときと同じです。実害が直接出る領域では、慎重さの質を変える必要がありました。
予約システムが、外とつながりました
こうして振り返ると、今回の連携には別の意味もあったと思っています。
予約システムが、自分のサーバーの中で完結するものではなくなりました。
- Stripeとつながって、お金が動く
- Googleカレンダーとつながって、3つの経路の予約が1つの台帳に集まる
- 館内のデジタルサイネージとつながって、今日の予約が表示される
- そしてSwitchBotとつながって、扉が開く
第5話で「決済は借りてくるものだと思い込んでいた」と書きました。第6話では「Googleカレンダーの同期も難しいと思い込んでいた」と書きました。
鍵も、同じでした。
予約に合わせて自動で鍵が開くなんて、大がかりなシステムが必要なのだろうと思っていました。実際にやってみると、つなげられるものは、つながるのです。
予約情報は、すでに手元にあります。誰が、いつ、どの部屋を使うのか。その情報を、画面の外にも届けるだけの話でした。
次回：#12 最終回
次回で、このシリーズは最終回です。
2週間で何ができて、何ができなかったのか。ノンプログラマーがAIとシステムを作るということは、実際のところどういうことだったのか。
そして、これを読んでいるあなたが同じことをできるのかどうかについて、正直に書こうと思います。
シリーズ一覧（全12話）
- 連載まとめ・目次
- #1 きっかけ編｜「作れます」の一言から始まった
- #2 準備編｜Cloudflareが何かも分かっていなかった
- #3 予約カレンダーと顧客導線｜なぜ日付から入らせるのか
- #4 料金設計という難所｜AIは「やめたほうがいい」とは言わない
- #5 決済とStripe｜「借りてくるもの」だという思い込み
- #6 Googleカレンダー双方向同期｜台帳は1つでいい
- #7 メールと通知の設計｜10年間、諦めていたこと
- #8 思わぬ落とし穴｜2回、巻き戻しました
- #9 ローンチ当日｜「あっ、ヤバい」
- #10 ローンチ後に起きたこと｜作った本人には見つけられない
- #11 予約システムが、画面の外に出た日（SwitchBot連携）（この記事）
- #12 最終回｜私でも、優秀なプログラマーを配下に置ける
運営ルールの記事