前回までのあらすじ
「半年・500万円」と言われて諦めていた予約システムを、お盆休みにClaudeと作り始めた話を書いています。
前回は公開当日の話でした。既存の予約データを引き継いでいないことに気づき、爆速で復旧した一日です。
今回は、公開した後の話です。
そして今回わかったのは、私一人では絶対に見つけられなかったことがある、ということでした。
公開当日、スタッフにも来てもらいました
切り替えを行った8月30日、私はスタッフにも出勤してもらっていました。
理由は、何かトラブルがあったときにすぐ対応できるようにするためです。前回書いたとおり、この日は「動かしながら直す」前提で臨んでいました。
そこで公開と同時に、スタッフに本番環境で実際に予約を入れてもらうことにしました。
横で、その様子を見ていました。
見ていて、気づいてしまいました
システムを作ったのは私です。
ここで何が起こるか、次のアクションは何か、支払いはどう進むか。
何度も何度もテストを繰り返してきたので、全部わかっています。
だから私は、迷いません。
ところが、スタッフの予約の挙動が、思いのほかスムーズではなかったのです。
手が止まる。少し考える。違う場所を押そうとする。
ここで、はっきり分かりました。
作った本人は、不具合を見つけられません。
私は次に何が起こるか知っています。だからどこも迷わない。迷わない人間が何度テストしても、迷う場所は見つからないのです。
100回のテストでは出てこなかったものが、他人が触った最初の数分で出てきました。
戻るボタンで、入力が全部消えました
その中で、決定的な場面がありました。
あるスタッフが、複数の予約を同時に入れようとしていました。そこで日時を間違えて入力してしまいます。
そして、戻るボタンを押しました。
すると、入力した情報が全部クリアになってしまったのです。
これは、ユーザーとしてはがっかりしますよね。
もう一度、最初から入力し直しです。予約を諦めてしまう方がいても、おかしくありません。
しかもこれは、バグではありません
ここが厄介なところです。
これはエラーでもバグでもなく、システムとしては正常な動作です。
だからテストでは絶対に検出されません。私が何度テストしても、そもそも入力を間違えないので、戻るボタンを押す場面がありませんでした。
対策は2つ打ちました
早速、Claudeと相談しました。
ひとつは、入力情報が消えないようにすること。 cookieやブラウザの保存機能を使って、途中の情報を保持するようにしました。
もうひとつは、予約導線のマニュアルを作ること。 こちらはお客様向けの案内です。
片方だけでは足りないと考えました。仕組みで防げる部分は仕組みで防ぐ。それでも迷う方がいるなら、案内で補う。
管理者ページにも、改善点が山ほどありました
スタッフに触ってもらって分かったことは、お客様の予約画面だけではありませんでした。
管理者ページにも、改善が必要な箇所がたくさんありました。
考えてみれば当然です。私は自分で作ったので使い慣れています。しかし日常業務で毎日触るのは、スタッフのほうです。
たとえば、こんな改善をしました。
これから新しくオープンする施設の情報について、公開する時期を選べるようにする。
新規オープンの施設は、準備が整う前から情報だけ出したい場合もあれば、直前まで伏せておきたい場合もあります。いつ情報を出すかをコントロールしたいというのは、運営者として当たり前の要求です。
ただ、システム側に用意されていなければ、それはできません。
こうした細かい改善が、いくつも出てきました。
英語版は、全ページ対応しました
公開直後に気づいた抜けが、もうひとつあります。
英語版です。
レンタルスペースALBEは、一定数の外国の方にご利用いただいています。英語版は必須でした。
システムの作り込みに集中しすぎて、こうした周辺情報を整えることが完全に抜けていました。
対応は、すべてのページを対象にしました。
予約の導線だけを英語にしても、意味がありません。途中で日本語に切り替わってしまえば、そこで止まります。特にキャンセル規定のような重要な部分が日本語のままでは、後々のトラブルにもなりかねません。
翻訳を「忘れない」仕組みにしました
そして、ここでひとつ工夫をしました。
日本語のページを更新すると、何も言わなくても英語のページもその内容に沿って翻訳され、更新される。
そういう仕組みにしました。
理由は単純です。必ず忘れるからです。
日本語を直したときに英語も直す。頭では分かっていても、忙しい日には抜けます。そして気づいたときには、日本語と英語で書いてあることが違っている。
「気をつける」では解決しません。忘れても大丈夫な形にするしかないと考えました。
スタッフの疑問に、私がいなくても答えられるように
公開後に整えたもので、最も重要だったのがこれかもしれません。
スタッフ向けの、AIチャットです。
なぜ作ったのか
理由は、はっきりしています。
優秀なシステムを作っても、スタッフの疑問に答えられなければ意味がありません。
そして今回、システムを作ったのは私一人です。仕様を知っているのも、私一人です。
このままだと、どうなるか。
制作を司った私がいないと、誰も答えられない環境になってしまいます。
これでは、永遠に手離れができません。スタッフが困るたびに私が呼ばれる。動いているように見えて、実際には私自身がボトルネックになっている状態です。
だから、システムを作るのと同時に、スタッフの悩みを解決する仕組みも作りました。
どういう仕組みか
やったことは、こうです。
今回作った予約システムの概要をすべて出力した内容を、プロジェクトのチャットに設置しました。
スタッフが質問をすると、そのシステム概要を参照して返事をしてくれる、AIチャットのようなものです。
そして重要なのがここです。
システムが更新されると、そのシステム概要も更新される仕組みにしました。
つまり、リアルタイムで正確な情報がスタッフに伝わります。
マニュアルは、作った瞬間から古くなっていきます。改修のたびに書き直さなければならず、そのうち追いつかなくなり、誰も見なくなる。運用の現場では必ず起きることです。
更新作業そのものをなくしてしまえば、その問題は起きません。 英語版の翻訳と、まったく同じ考え方です。
GitHubが、ここで効きました
さらに、このAIマニュアルにはGitHubが連携しています。
第2話で、GitHubを「万が一トラブルがあっても戻れる、生産管理のようなツール」と理解した、と書きました。第8話では、実際にそこから2回戻したことも書きました。
そこには、これまでの制作プロセスがすべて蓄積されています。
その結果、ほとんどの質問に答えられる条件が整っていました。
なぜこの機能があるのか。どういう経緯でこの仕様になったのか。開発の過程そのものが記録されているので、答えられる範囲が非常に広い。
保険のつもりで置いていたものが、結果的に一番詳しい仕様書になっていました。
公開後にやったのは、機能追加ではありませんでした
こうして振り返ると、公開してからやったことには共通点があります。
どれも、新しい機能を足す話ではありません。
- 入力した情報が消えないようにする
- マニュアルが古くならないようにする
- 英語版が日本語とずれないようにする
- スタッフが私に聞かなくても済むようにする
全部、運用が壊れないための整備です。
そして、そのほとんどが「人は忘れる」「人は間違える」という前提に立っています。
戻るボタンは押されるものです。翻訳は忘れるものです。マニュアルは更新されなくなるものです。
気をつけて防ぐのではなく、そうなっても大丈夫な形にする。
公開してからの日々で学んだのは、この考え方でした。
そして、まだ続いています
正直に書くと、この改良はまだ終わっていません。
今も新しい取り組みを進めています。
次回は、その話を書きます。予約システムが、画面の中だけの話ではなくなる、という話です。
設計資料を、無償でお渡しします
自社で予約システムを独自開発したいとお考えの事業者さまへ。
今回私たちが作成した予約システムの基本機能を構築するための設計資料を、無償でお渡しします。
どんな資料か
Claude Codeに読み込ませることで、基本機能が再現できる粒度で書いたものです。
読んで理解するための資料ではなく、開発の起点として使える資料です。
カスタマイズは、ご自身で
この資料で再現できるのは、あくまで基本機能です。
キャンセル規定も、料金体系も、回数券の扱いも、運営によって違います。 そういった部分は、ご自身でカスタマイズしてください。
そして、その作業こそが、このシリーズで書いてきたことそのものです。ポイントは技術ではなく、やりたいことを体系的に説明できるかどうかだと思っています。
ご注意
動作を保証できるものではありません。
設計資料であって、製品ではありません。環境も、使うサービスも、事業者さまごとに異なります。そのままで動くことをお約束するものではない、という点はご理解ください。
また、お渡しできるのはレンタルスペース事業または同種の事業を生業にされている方のみとさせていただきます。
お申し込み方法
お問い合わせフォームからご連絡ください。
ご用件の項目に「予約システムの設計資料を申し込む」をご用意しています。
差し支えのない範囲で、運営されている施設やご事情をお聞かせいただければ幸いです。
実際に触れるデモを公開しています
この連載で作った予約システムを、搭載している機能の一覧とあわせてご案内しています。ご予約は入りませんので、カレンダーの動き、料金の出方、申し込みの流れを自由にお試しください。同業の方、これから予約システムを作ろうとしている方に向けたものです。
シリーズ一覧（全12話）
- 連載まとめ・目次
- #1 きっかけ編｜「作れます」の一言から始まった
- #2 準備編｜Cloudflareが何かも分かっていなかった
- #3 予約カレンダーと顧客導線｜なぜ日付から入らせるのか
- #4 料金設計という難所｜AIは「やめたほうがいい」とは言わない
- #5 決済とStripe｜「借りてくるもの」だという思い込み
- #6 Googleカレンダー双方向同期｜台帳は1つでいい
- #7 メールと通知の設計｜10年間、諦めていたこと
- #8 思わぬ落とし穴｜2回、巻き戻しました
- #9 ローンチ当日｜「あっ、ヤバい」
- #10 ローンチ後に起きたこと｜作った本人には見つけられない（この記事）
- #11 予約システムが、画面の外に出た日（SwitchBot連携）
- #12 最終回｜私でも、優秀なプログラマーを配下に置ける
運営ルールの記事