前回までのあらすじ
「半年・500万円」と言われて諦めていた予約システムを、お盆休みにClaudeと作り始めた話を書いています。
前回は、50種類以上のメールを作った話でした。10年間「この場面でメールが飛ぶといいよね」と諦めてきたことを、全部実現した回です。
ここまで読んでいただくと、順調に進んだように見えるかもしれません。
今回は、うまくいかなかった話を書きます。
落とし穴1：テスト環境を作っていませんでした
まず、初歩的なところから告白します。
最初、私は本番環境だけで構築を進めていました。
つまり、作りながら直接そこで動かしていた。実際に公開されている場所と同じところで、試行錯誤していたわけです。
システムに詳しい方なら、ここで顔をしかめると思います。
私が気づいたのは、思ったような結果が得られなかったときでした。
画面が想定どおりに動かない。表示が崩れる。そういう場面に出くわして、ふと思ったのです。
「これがもし本番公開後だったら、大変なことになる」
お客様が予約しようとしている最中に、画面が壊れる。決済が途中で止まる。想像したら、背筋が寒くなりました。
そこで基準を作りました
以降は、はっきりルールを決めました。
必ずテスト環境で構築する。目視で確認し、動作も確認する。そのうえで本番にアップする。
当たり前のことだと言われればそのとおりです。経験のある方なら、最初からそうしているでしょう。
ただ私のようなノンプログラマーは、そもそも「テスト環境を分ける」という発想自体を持っていません。 作る場所は1つだと思い込んでいました。
ここは、素人だからこそ踏んだ落とし穴だったと思います。
落とし穴2：欲張りすぎて、矛盾が生まれました
もうひとつ、これは開発中に2回起きました。
作り込んだものを、前の状態に戻したのです。
第2話で、GitHubについて「万が一トラブルがあっても前の状態に戻せる、生産管理のようなツール」と書きました。そして「保険のようなものだろう」という理解で進めた、とも。
実際に、その保険を2回使うことになりました。
原因は、私たちの欲張りでした
はっきり書いておきますが、これはシステムの問題ではありません。
原因は、私たちが欲張りすぎて機能を追加していったことです。
細やかな対応ができるようにしたい。あれもできるようにしたい、これも拾えるようにしたい。そうやって要望を重ねていくと、どこかで矛盾が生じるポイントが出てきます。
そして厄介なのは、Claudeがその要望に応えようとしてくれることです。無理にでも実現しようとしてくれる。結果、全体としては辻褄が合わなくなる。
頼まれたことを何とかしようとしてくれるからこそ、こうなりました。
具体例：回数券が足りないとき
分かりやすい例を挙げます。回数券（チケット）の扱いです。
たとえば、20枚つづりの回数券があるとします。お客様はすでに18枚を消化していて、残りは2枚。
ここで、5時間の予約を入れたいと言われたらどうするか。
回数券が足りません。この場合、
- 新たに回数券を購入して、今回の予約に継ぎ足すのか
- それとも、足りない3時間分は別の予約として作ってもらうのか
考え始めると、どちらにも問題があります。
継ぎ足しを許すと、残数の管理ができなくなります。 有効期限の異なる複数の回数券をまたいで使うことになり、どの券から何枚引いたのかが追えなくなる。
かといって予約を分ければ、お客様から見れば連続した1回の利用なのに、予約が2件に分かれてしまいます。
こうした矛盾が、作り込むほどに表面化してきました。
決着：チケットは跨がせない
最終的に、こう決めました。
回数券は跨がせない。 これを一線としました。残数管理が物理的に破綻してしまうので、ここは割り切るしかないと理解しました。
そのうえで、足りない場合の選択肢を2つ用意しました。
- 足りない分をクレジットカード決済で埋める
- 新たに回数券を購入して、新規で予約を作る
お客様の事情に合わせて、どちらでも選べます。
技術的には、跨がせる実装もできたのかもしれません。ただ、作れるかどうかではなく、運用が成立するかどうかで線を引きました。
これは料金設計のときと同じ判断です。何でも作れることが良いわけではない、というのは、このシリーズで何度も出てくる話です。
そこから、進め方を変えました
2回戻したことで、私は進め方を変えました。
いきなり作ってもらうのをやめました。
代わりに、まずこう聞くようにしました。
「こういったことを実現したいんだけど、可能？」
作業を依頼する前に、質問を投げかける。それから着手する。
この手法は、とてもよく効きます
理由があります。
人間が理解しているシステムの全体像は、かなり狭い範囲でしかありません。
私は自分が作ったものですら、全部を把握できていません。どこを触るとどこに影響が出るのか、正確には分からない。
ところが、あえて聞くことで、Claudeが全体を見渡してから実装に臨んでくれるのです。
「それをやると、ここと矛盾しますが大丈夫ですか」「別のやり方のほうが整合します」といった反応が返ってくる。作り始める前に分かるわけです。
依頼してから直すのと、依頼する前に確認するのとでは、手戻りの量がまったく違いました。
これは、誰にでもすぐ真似できる方法だと思います。
落とし穴3：伝わっていなかったのは、私の説明でした
Claudeとのやり取りで、噛み合わないと感じた場面もありました。
ただ、振り返ってみると、噛み合わなかったのではありません。
こちらの説明不足が原因で、正しく情報が伝わっていなかっただけでした。
これは完全に、説明する側の問題です。
まさに5W1Hが大事だと痛感しました。 いつ、どこで、誰が、何を、なぜ、どうやって。このうちどれかが抜けていると、返ってくるものがずれます。
人に仕事を頼むときと、まったく同じです。
「なぜ」を伝えると、提案が返ってくる
そしてもうひとつ、大きな発見がありました。
なぜこの機能を追加したいのか、その背景を伝えると、Claudeから良い提案がもらえるのです。
「この画面にボタンを足してください」とだけ言えば、ボタンが足されます。
でも「お客様がここで迷って電話をかけてくることが多いので、それを減らしたい」と伝えると、ボタン以外の解決策が返ってくることがあります。
何を作るかだけでなく、なぜ作るかを渡す。 これだけで、返ってくるものの質が変わりました。
この回でわかったこと
3つの落とし穴を振り返ると、共通点があります。
どれも、技術力があれば避けられた問題ではありません。
テスト環境を分ける発想がなかったのは、経験の問題です。欲張って矛盾を生んだのは、判断の問題です。説明が足りなかったのは、伝え方の問題です。
コードが書けるかどうかとは、別のところにありました。
そして、そのどれもが、一度失敗してみないと気づけないことでもありました。
AIと一緒に作っていると、進むスピードは驚くほど速いです。だからこそ、立ち止まって確認する習慣を、自分で作る必要がありました。
戻れる仕組みがあってよかった、というのが正直なところです。第2話で「保険のようなものだろう」と書いたGitHubは、本当に保険でした。
次回：#9 ローンチ当日
次回は、いよいよ公開の日です。
新しいシステムに切り替える、その瞬間に何が起きたか。
そして、私が完全に見落としていたある大問題についても書きます。ここは今でも思い出すと冷や汗が出ます。
設計資料を、無償でお渡しします
自社で予約システムを独自開発したいとお考えの事業者さまへ。
今回私たちが作成した予約システムの基本機能を構築するための設計資料を、無償でお渡しします。
どんな資料か
Claude Codeに読み込ませることで、基本機能が再現できる粒度で書いたものです。
読んで理解するための資料ではなく、開発の起点として使える資料です。
カスタマイズは、ご自身で
この資料で再現できるのは、あくまで基本機能です。
キャンセル規定も、料金体系も、回数券の扱いも、運営によって違います。 そういった部分は、ご自身でカスタマイズしてください。
そして、その作業こそが、このシリーズで書いてきたことそのものです。ポイントは技術ではなく、やりたいことを体系的に説明できるかどうかだと思っています。
ご注意
動作を保証できるものではありません。
設計資料であって、製品ではありません。環境も、使うサービスも、事業者さまごとに異なります。そのままで動くことをお約束するものではない、という点はご理解ください。
また、お渡しできるのはレンタルスペース事業または同種の事業を生業にされている方のみとさせていただきます。
お申し込み方法
お問い合わせフォームからご連絡ください。
ご用件の項目に「予約システムの設計資料を申し込む」をご用意しています。
差し支えのない範囲で、運営されている施設やご事情をお聞かせいただければ幸いです。
実際に触れるデモを公開しています
この連載で作った予約システムを、搭載している機能の一覧とあわせてご案内しています。ご予約は入りませんので、カレンダーの動き、料金の出方、申し込みの流れを自由にお試しください。同業の方、これから予約システムを作ろうとしている方に向けたものです。
シリーズ一覧（全12話）
- 連載まとめ・目次
- #1 きっかけ編｜「作れます」の一言から始まった
- #2 準備編｜Cloudflareが何かも分かっていなかった
- #3 予約カレンダーと顧客導線｜なぜ日付から入らせるのか
- #4 料金設計という難所｜AIは「やめたほうがいい」とは言わない
- #5 決済とStripe｜「借りてくるもの」だという思い込み
- #6 Googleカレンダー双方向同期｜台帳は1つでいい
- #7 メールと通知の設計｜10年間、諦めていたこと
- #8 思わぬ落とし穴｜2回、巻き戻しました（この記事）
- #9 ローンチ当日｜「あっ、ヤバい」
- #10 ローンチ後に起きたこと｜作った本人には見つけられない
- #11 予約システムが、画面の外に出た日（SwitchBot連携）
- #12 最終回｜私でも、優秀なプログラマーを配下に置ける
運営ルールの記事