「店舗を回す」をシステムにすると何が必要なのか
予約があるだけでは、店舗は回りません。
予約 → 来店 → 受付 → チェックイン → レーン利用 → 利用終了 → チェックアウト → 決済、という流れの中で、故障したレーン、予約変更、教室の欠席、レーン変更といった出来事も起きます。
第三弾では画面だけでなく、「予約済み」「チェックイン済み」「利用中」「チェックアウト済み」といった状態をどう扱うかを設計する必要がありました。
どの情報を既存システムから引き継ぎ、どこからを第三弾で管理するのか。第三弾は単純なCRUDの追加ではなく、予約システムを実際の店舗運営につなげる設計になりました。
教室管理で「第二弾と第三弾の境界」が見えてきた
第二弾には、利用者が教室へ申し込む仕組みがあります。第三弾では、その教室を店舗側が運営・管理できる必要があります。
全5回の教室では、何回目か、誰が参加するか、出席・欠席をどう扱うかといった情報が必要になります。ここで見えてきたのは、第二弾を作り直すのではないということでした。
第二弾で作った予約・教室の仕組みを利用しながら、第三弾から運営に必要な情報と操作を加える。既存の仕組みを壊さず、店舗側から支える。この考え方が後のデータ設計につながっていきます。
AIに「作っていい」と言う前に
第三弾の途中から、Claudeの利用上の制限が早く来るようになりました。そこで一つのAIに固定せず、役割を分ける必要が出てきました。
当初の整理では、Claudeは設計とコード生成、Copilotは実装中の補完・修正、Geminiは設計レビュー、ChatGPTは意見統合・要件整理・レビューを担う想定でした。
ここで重要になったのは、「第三弾を進めて」と頼むことと、「第三弾のどこまでを実装してよいか」を定めることは別だということでした。AIが作れる範囲と、今回採用すべき範囲は同じではありません。
次の章では、Claudeが制限にかかりCopilotへバトンタッチした場面を書きます。
スポーツボウリング場構想・第三弾開発記録は、まだ続きます。🎳