Future Muscle Partner

～いきつけのジムでパーソナルトレーニングを受けよう～

サービスコンセプト

パーソナルトレーナーを身近なものにして、質が高く安全で楽しいフィットネス体験を提供する。

サービス概要:

• アプリ上でジム公認のトレーナーを検索＆予約し、いきつけのジムでトレーニングを受けることができる

主なアクターとメリット:

• トレーニー
  • 自分が通っているジムでパーソナル受けられる
  • トレーナーの得意分野ごとにトレーナーを使い分けられる
• パーソナルトレーニー
  • 24H型ジムでサービスを提供できる
  • いつ/誰に/どんなメニューでトレーニングしたかを管理できる

フォルダ階層

.
├── backend          # バックエンド系のコード
├── docs             # 設計書
│    ├── 01_画面      # Figma、画面アクション
│    ├── ...
│    └── README.md
├── frontend         # フロントエンド系のコード
├── infra            # インフラ系のコード

設計書

• 画面設計書
• WebAPI定義書: openapi.yaml
• ERD: erd.a5er

コード体系

機能IDのコード体系は以下に従う。

種別	種別	例	備考
UIS	通常画面	UIS01、UIS02	UI Standard から
UIM	モーダル画面	UIM01、UIM02	UI Mordal から
API	Web API	API01、API02
IFS	システムI/F 送信	IFS01、IFS02	InterFace Send から
IFR	システムI/F 受信	IFR01、IFR02	InterFace Receive から
BAT	バッチ	BAT01、BAT02	BATch から
RPT	帳票	RPT01、RPT02	RePorT から

コード体系について補足:

• UISであれば、 UIS(0[1-9]{1}|[0-9]{2} といったフォーマットに従うこと
• Future Muscle Partnerのプロダクト規模であれば、機能数が爆発しないという想定で2桁とする
  • 万が一あぶれた場合、16進数と見なしてA~Fを導入する拡張を行う

機能IDの採番について注意点:

• 採番後の変更は許可しない
• 連番とする（数字部分に新しい体系を作らない）

画面設計書の記載方針

• Web API の応答項目が、画面項目のどこにマッピングすべきかという情報は、多くの業務画面で重要である
  • 理由は、類似名称の項目がWeb API応答項目にも画面項目多く、紐づけの認識の齟齬が生じやすいからである
• future muscle partnerにおいては、項目数は多くなくFigmaを見れば自明であるため、画面項目定義を省略する