第三弾拡張機能――店舗運営と会員成長をつなぐ拡張機能

はじめに

スポーツボウリング場構想では、第一弾から第五弾まで、少しずつシステムの範囲を広げてきた。

第一弾では個人予約、第二弾では初心者教室、第三弾ではスポーツボウリング場の運営側、第四弾では会員管理と成長支援、第五弾では投球データを活用した独自・高機能スコアリングシステムを作った。

そして今回は、第三弾の拡張機能に取り組んだ。

開発の順番だけを見ると、

第三弾 → 第四弾 → 第五弾 → 第三弾拡張機能

と、一度先へ進んでから第三弾へ戻っている。

ただ、実際には「第三弾に戻った」というより、第三弾と第四弾、さらに第五弾まで作ったからこそ見えてきたつながりを、既存のシステムに追加していく作業だった。

1．第三弾を作った時点で、すでに「あとで拡張する」ことは決まっていた

第三弾を開発していた時点で、第三弾をすべて完成させて終わり、という考えではなかった。

第三弾ではまず、スポーツボウリング場を運営するための基本的な仕組みを作る。

そのうえで、第四弾で会員側の成長支援を作り、さらにその後、第三弾と第四弾をつなぐ拡張を行う。

この流れは、第三弾の開発段階から考えていた。

そのため、第三弾の拡張候補として、店舗側と会員側を組み合わせた機能をいくつか保留していた。

最終的に候補として残ったのは、次の4つだった。

① 店舗側「メンテナンス管理」× 会員側「オイル抜きリマインド通知」

② 店舗側「コーチシフト管理」× 会員側「全5回講座進捗＆指導メモ」

③ 店舗側「レーンアサイン自動化」× 会員側「達成バッジ・称号」

④ 個人カルテ × グループ単位出欠管理

①〜③は、第三弾と第四弾を組み合わせることで見えてきた拡張候補。

④は、第三弾で採用した「初心者教室に複数名で申し込んだ参加者の出欠をグループ単位で管理する」という設計と、第四弾で必要になった個人単位の会員情報をつなぐための候補だった。

2．面白いのは「開発順」と「完成順」が違うこと

第三弾拡張機能は、最終的には①②③まで実装・テストを完了した。

ただし、実装した順番は①→②→③ではない。

実際の開発順は、

④ → ③ → ② → ①

だった。

ここでいう番号は「完成した順」ではなく、もともと設定していた拡張候補の番号である。

つまり、

● ④ 個人カルテ × グループ単位出欠管理

● ③ レーンアサイン自動化 × 達成バッジ・称号

● ② コーチシフト管理 × 全5回講座進捗＆指導メモ

● ① メンテナンス管理 × オイル抜きリマインド通知

という順番で実装を進めた。

なぜこの順番になったのか。

それは、第四弾・第五弾まで開発したあとに、既存機能とのつながりを確認しながら、一つずつ実装していった結果だった。

3．④ 個人カルテ × グループ単位出欠管理

第三弾では、初心者教室に複数名で申し込んだ参加者の出欠を、グループ単位で管理する設計を採用した。

これは第三弾の店舗運営側の考え方として、意図的に決めたものだった。

一方、第四弾では会員一人ひとりの成長を記録するため、個人単位の情報が必要になった。

教室全体としてはグループで進行していても、会員カルテでは「この人が何回参加したのか」「どの講座を受けたのか」といった個人単位の情報が必要になる。

そのため、第三弾のグループ単位の出欠管理を作り直すのではなく、既存のデータを第四弾の個人カルテにつなげる方向で考えた。

第三弾の運営設計を崩すのではなく、第四弾側から個人の視点を追加する。

これが、④を最初に実装した理由だった。

4．③ レーンアサイン自動化 × 達成バッジ・称号

次に取り組んだのが、レーンアサインと会員側の達成要素を組み合わせる拡張だった。

店舗側では、レーンをどう割り当てるか。

会員側では、練習や受講を通じて何を達成したのか。

一見すると別々の機能に見えるが、実際の店舗運営では、レーンを利用する会員の情報と、その会員の成長情報は同じ場所に存在する。

第三弾で作った店舗運営の仕組みと、第四弾で作った会員の成長管理をつなげることで、単なる予約・管理システムから、会員の継続利用や成長を支援する仕組みに近づいていく。

この段階では、店舗側の運営情報と会員側の成長情報を別々に考えるのではなく、両者をどうつなげるかという視点がはっきりしてきた。

5．② コーチシフト管理 × 全5回講座進捗＆指導メモ

続いて、初心者教室の運営をさらに店舗の実運用に近づける拡張に取り組んだ。

第三弾では、初心者教室を「全5回の講座」として運営できる仕組みを作った。

そこに第四弾の会員情報を組み合わせると、

● 誰がどの講座まで進んでいるのか

● どのコーチが担当するのか

● 会員ごとにどのような指導をしたのか

といった情報を、より継続的に扱えるようになる。

ここで重要だったのは、単に「教室予約ができる」だけではなく、受講して終わりではなく、その後の成長につなげられる構造にすることだった。

第三弾の「教室運営」と第四弾の「会員成長」が、ここでより直接的につながった。

6．① メンテナンス管理 × オイル抜きリマインド通知

最後に①へ進んだ。

①は、

店舗側「メンテナンス管理」× 会員側「オイル抜きリマインド通知」

という組み合わせだった。

このうち、会員側の「オイル抜きリマインド通知」は今回実装した。

一方、店舗側の「メンテナンス管理」は、レーンのメンテナンス状態を確認するだけではなく、点検予定や履歴などを管理する機能として、今後の拡張候補に残っている。

この機能は、会員のマイボール管理と店舗側の設備管理をつなぐものでもある。

第五弾では、レーンのオイルパターンを記録する仕組みも実装した。

そのため今後、店舗側のメンテナンス管理まで実装すれば、レーンコンディションの管理と会員側のボールメンテナンスを、さらに関連づけていくこともできる。

7．AIとの開発で起きたこと

今回の第三弾拡張機能は、第三弾と第四弾の両方を読み込みながら実装する必要がある、もともと重たい作業だった。

ところが今回は、第四弾のレビューから第五弾の実装まで進めていたClaudeの同じチャットの続きで、第三弾拡張機能の実装も進めてしまった。

これが今回の開発では一つの大きな問題になった。

前の作業の文脈が大量に残った状態で、第三弾と第四弾の設計を確認しながら実装することになったため、Claudeに一つ指示を出すだけでも長い文脈を必要とするようになった。

そして、何度もClaudeのメッセージ上限に引っかかった。

本来なら、第三弾拡張機能用に新しい作業環境を用意し、

● 第三弾の設計

● 第四弾の設計

● 第五弾で追加された内容

● これまでに決めた拡張候補

● 既存機能との関係

を整理したうえで進めるべきだった。

今回の経験で、AIとの開発では「何を指示するか」だけでなく、どの文脈を持たせ、どこで作業を区切るかも重要だと分かった。

結果として、④③②はClaudeを中心に実装し、①の会員側「オイル抜きリマインド通知」はChatGPTに引き継いで実装することになった。

ただし、その時点でChatGPTのWorkの残り使用量は15％だった。

Workは最後にコードをまとめる作業に使い、使用量が0％になったため、gears.py はChatGPTの通常のチャット欄で実装することになった。

8．「全終了」のあとに分かったこと

④③②の実装・テストを終え、①についても会員側の「オイル抜きリマインド通知」を実装した。

関連するリポジトリについても、起動確認や既存テストの確認を行った。

そこで、一度は、

「これで第三弾拡張機能も全終了」

と考えた。

ところが、そのあと改めてClaudeに「今後もし拡張するとしたら何があるか」と確認した。

そこで出てきたのが、

店舗側の「メンテナンス管理」がまだ残っている

という事実だった。

①はもともと、

店舗側「メンテナンス管理」× 会員側「オイル抜きリマインド通知」

という一つのペアだった。

今回実装できたのは、そのうち会員側だった。

つまり、「全終了」と思った時点で、実は①の店舗側が残っていた。

これは、新しく追加された仕様ではない。

最初から予定していた機能の片側が、実装の途中で抜けていた。

今回の開発では、最後まで完成したと思ってから、それに気づくことになった。

店舗側のメンテナンス管理については、今後ポートフォリオとして改めて取り組む候補として残している。

9．第三弾拡張機能で見えた「つながり」

今回の開発を終えて改めて見ると、第三弾と第四弾は別々のシステムを作っていたわけではなかった。

第三弾では、

「ボウリング場をどう運営するか」

を考えた。

第四弾では、

「会員一人ひとりの成長をどう記録し、支援するか」

を考えた。

第五弾では、さらに投球データを蓄積し、分析につなげる仕組みを作った。

第三弾拡張機能では、その間にあるつながりを実際の機能として形にしていった。

店舗側の運営情報と会員側の情報。

グループ単位で扱う情報と個人単位で扱う情報。

教室の運営と、受講後の成長。

レーンや設備の管理と、会員のギア管理。

それぞれを別々に作るだけではなく、同じスポーツボウリング場という場所の中で、どうつながるのかを考える段階に入ったのだと思う。

そして今回の開発では、AIとの作業環境についても大きな学びがあった。

AIに実装を任せる場合でも、プロジェクト全体を把握し、作業を分割し、必要な文脈を渡すのは人間側の役割になる。

うまくいった部分だけでなく、実装漏れや作業環境の失敗も含めて、今回の開発記録として残しておきたい。

また、今回一緒に開発してきたClaudeについては、収入が安定したらClaudeを有料プランにしたいと思っている。

今回の経験を踏まえて、より適切な環境で、また一緒に開発してみたいからだ。

おわりに

第三弾から第四弾、第五弾へ進んだあと、第三弾の拡張機能に取り組んだ。

一度先へ進んでから、以前の場所を見る。

それは後戻りではなかった。

前に進んだからこそ見えるようになった「つなぎ目」を埋める作業だった。

第三弾拡張機能は、機能を追加した記録であると同時に、ここまで作ってきた「スポーツボウリング場構想」が、少しずつ一つのシステムとしてつながっていく過程の記録でもある。

なお、ここで「今後の候補」として残した店舗側のメンテナンス管理は、その後、実際に形にした。その記録は、次の記事で。

スポーツボウリング場構想・第三弾開発記録は、まだ続きます。🎳

https://coconala.com/users/6008491