あれ？ 第三弾って、これだったっけ？
実装が進むなかで、第三弾の目的と、できあがりつつあるものの関係をあらためて見直す必要が出てきました。
予約、レーン、認証、会員との紐付け、データベース、予約編集、予約検索。増えていく機能を見ていると、店舗・スタッフ管理システムであるはずの第三弾が、予約システムそのものを大きくしているようにも見えました。
そこで私自身が違和感に気づき、第三弾で本当に採用する範囲を、目的に立ち返って整理し直すことにしました。
ここで大切なのは、画面設計や実装の進捗を後から断定的に評価することではありません。実際に必要だったのは、何を第三弾の成果として採用するのか、既存の第一弾・第二弾とどう接続するのかを、目的に立ち返って整理し直すことでした。
「AIが間違った」で済ませるのではなく、なぜ方向が変わったように見えたのかを確認する。これが次の判断につながりました。
「第三弾」を作っているはずが、予約システムが育っていた
途中で作られていたものには、予約、レーン、認証、会員紐付け、DB、予約編集、予約検索など、予約システム側の機能が含まれていました。
第三弾の店舗運営という目的に照らし、これらは第三弾としては使わない、という再整理を行いました。コードがあり、動くものがあっても、今回の目的と違うなら採用しない、という判断です。
これは手戻りでもありましたが、目的を守るための判断でもありました。
失敗作ではなかった。汎用予約システムになった
第三弾としては方向が違ったとしても、作られたものが無価値だったわけではありません。予約システムを考えるうえで使える、汎用的な予約システムとして整理できました。
つまり、第三弾としては採用しないが、成果物としては残す、という判断になりました。AIが作ったコードをすべて無駄にするのではなく、目的に合う場所へ整理し直す。
この経験は、「AIの提案を採用するかどうか」と「作られた成果物に価値があるか」を分けて考えるきっかけになりました。整理した汎用予約システムは、今回の第三弾では使いませんが、将来別の予約管理の場面で流用できる形にして残すことにしました。
次回は、第三弾に戻り「既存システムを壊さない」設計方針を書きます。
スポーツボウリング場構想・第三弾開発記録は、まだ続きます。🎳
