はじめに
個人開発で、スポーツボウリング場の運営システムを段階的に作ってきました。
最初から全体設計があったわけではありません。第一弾を作り、「次に必要なもの」を考え、AIと壁打ちしながら構想を広げていった結果、全体はこう整理できるようになりました。
| 段階 | テーマ | 一言でいうと |
|---|---|---|
| 第一弾 | 予約 | 予約できる |
| 第二弾 | 利用の広がり | いろいろな利用ができる |
| 第三弾 | 店舗運営 | 店舗を運営できる |
| 第四弾 | 会員・成長支援 | ボウラーが成長できる |
この4段階のあと、第五弾（独自スコアリング分析）と第三弾の拡張機能まで開発が続きました。
この記事は、その全体像を「個人開発の進め方」の視点でまとめたロードマップです。
第一弾：予約
「いつ、どのレーンを利用するか」を管理する、レーン予約システムです。
構想全体の土台になりました。
第二弾：利用の広がり
予約だけでは、ボウリングを「始める・続ける」仕組みになりません。そこで次を追加しました。
- 初心者教室
- 全5回コース
- 個人・グループ申込
- クラウドファンディング特典
- 教室修了者を対象とした資格制限
「予約する」から「ボウリングを始める・利用する」へ、対象の範囲を広げた段階です。
第三弾：店舗運営
利用者側の機能だけでは、店舗は回りません。視点をスタッフ側に移しました。
- スタッフログイン（4桁PIN）
- 当日予約確認、来店受付、チェックイン／チェックアウト
- レーン状態管理、故障・メンテナンス時のブロック
- 教室参加者管理
- 決済確認
AIの実装が目的から外れたとき
この段階で一番の学びになったのは、AIが作る実装が当初の目的から外れて広がることがある、という点でした。
AIの出力をそのまま採用せず、人間側が「このシステムで本当に何を実現したいのか」に立ち返り、必要な範囲を整理し直しました。
個人開発では、仕様の判断を最終的に自分が持つ必要があります。AIにどこまで任せるかを、開発の途中で見直した段階でもありました。
第四弾：会員・成長支援
運営側を作ると、次は「そこで活動する人」が気になりました。
最初は会員管理（名簿）のつもりでしたが、ギア、記録、練習、これからの成長まで考えるうちに、「会員管理」から「成長支援」へ構想が変わりました。
- 会員カルテ
- デジタルギア管理とメンテナンス履歴
- オートスコアラーCSVによる投球記録
- 全フレームのピン残りパターン、10フレーム目の詳細
- 会員レベル、練習メニュー、練習アドバイス
- 会員マイページ、ゲーム履歴
記録を残すだけでなく、「その記録を次の成長につなげられるか」を設計の軸にしました。
4段階の流れ
第一弾「予約できる」
↓
第二弾「いろいろな利用ができる」
↓
第三弾「店舗を運営できる」
↓
第四弾「ボウラーが成長できる」
予約 → 利用 → 運営 → 成長、という流れです。
その後：第五弾と第三弾拡張機能
第五弾：独自スコアリング分析
第四弾で貯められるようになった投球記録を、分析する段階です。
- 残りピンをビットマスクで構造化
- ストライク／スペア／タップ／スプリット／オープンのフレーム分類
- ギア別・レーン別の成績比較、失点要因の分析
- 実機を想定した汎用CSV（1行＝1投）の取込
- レーン番号とタイムスタンプから、セッションと投球者を自動で特定
- 会員向け・スタッフ向けダッシュボード（React + Recharts）
バックエンドはE2Eテスト77件で動作確認しました。
第五弾は、私にとって初めて本格的にフロントエンドを作った開発でもあります。
第三弾拡張機能
第三弾の周辺で、4つの拡張が生まれました。
- 修了記録（教室修了の事実を記録）
- 達成バッジ・称号
- コーチシフト管理
- 店舗側メンテナンス管理
このうちメンテナンス管理は、PostgreSQL・Docker・AWSで別リポジトリとして構築し、第三弾・第四弾とAPI連携させました。
作ってから削った機能
レーンの自動アサインは、一度実装したものの「4レーン運用なら目視で十分」と判断して削除しました。
個人開発では、機能を足す判断と同じくらい、足さない判断が重要だと感じています。
技術構成
| 段階 | フロントエンド | 補足 |
|---|---|---|
| 第一弾・第二弾 | Streamlit | 予約・教室・申込 |
| 第三弾 | React | 店舗・スタッフ管理 |
| 第四弾 | （バックエンド中心） | 会員認証・CSV取込・成長支援 |
| 第五弾 | React（Recharts） | スコアリング分析ダッシュボード |
| 拡張①（メンテナンス管理） | （API中心） | PostgreSQL・Docker・AWS |
バックエンドはPython／FastAPIが中心です。フロントエンドは、途中で「Reactに挑戦する」と決めて第三弾・第五弾に使いました。
振り返り
- 全体設計は最初になく、作りながら構想が育った
- AIの出力は、人間が目的に立ち返って取捨選択する
- 「作らない」と決めることも、開発の一部だった
このロードマップは、最初からすべてを決めていた計画書ではありません。
「作りながら考え、考えながら作る」
その過程そのものが、このスポーツボウリング場構想の開発でした。
これで、ひとまず開発として一区切りです。
スポーツボウリング場構想・ロードマップは以上です。各システムの開発記録は、このあと順次公開していきます。🎳
🏠 ホームページ(ポートフォリオ・開発記録・ご相談窓口)
https://junko-takahashi-cloud.github.io/personal-site/?utm_source=qiita&utm_medium=article&utm_campaign=roadmap
🐍 ココナラ(Python業務自動化シリーズ)
https://coconala.com/users/6008491