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