前回までのあらすじ
「半年・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 ローンチ当日
次回は、いよいよ公開の日です。
新しいシステムに切り替える、その瞬間に何が起きたか。
そして、私が完全に見落としていたある大問題についても書きます。ここは今でも思い出すと冷や汗が出ます。
シリーズ一覧（全12話）
- 連載まとめ・目次
- #1 きっかけ編｜「作れます」の一言から始まった
- #2 準備編｜Cloudflareが何かも分かっていなかった
- #3 予約カレンダーと顧客導線｜なぜ日付から入らせるのか
- #4 料金設計という難所｜AIは「やめたほうがいい」とは言わない
- #5 決済とStripe｜「借りてくるもの」だという思い込み
- #6 Googleカレンダー双方向同期｜台帳は1つでいい
- #7 メールと通知の設計｜10年間、諦めていたこと
- #8 思わぬ落とし穴｜2回、巻き戻しました（この記事）
- #9 ローンチ当日｜「あっ、ヤバい」
- #10 ローンチ後に起きたこと｜作った本人には見つけられない
- #11 予約システムが、画面の外に出た日（SwitchBot連携）
- #12 最終回｜私でも、優秀なプログラマーを配下に置ける
運営ルールの記事