はじめに
こんにちは。あずさくです！
バックエンドの経験を積みたいけど、モバイルの仕事をやっているとなかなかバックエンドの仕事を任せてもらえるチャンスがありません。
今回は、バックエンド実務経験ゼロの私が、バックエンド設計、実装ができるようになるための学習記録を残していきたいと思います！
About Me
- モバイルアプリ開発歴5年目（Dart, Swift, Kotlin）
- バックエンド歴0年0ヶ月
- 自己学習でtypescriptを書いた経験はあるがレビュー指摘を受けた経験なし
- 新人時代の研修でもAPIやDBについての学習経験なし
- 職場ではモバイル以外の業務に触れる機会がない
- 今後、システム設計ができるようになりたいのでバックエンドの必要性を感じ始めている
...と、いうことでバックエンドのコードと実装ができるようにと学習を始めています。よろしくお願いします。
作ったもの
予約管理システムのPoCを作成しました。
https://github.com/bluerabbits69/reservation-api-poc
バックエンドのことはわからないことが多すぎるので、Claude Codeに色々と質問をしながら実装しました。
（予約管理システムの案もClaude君に提案してもらいましたが、職場のバックエンドの新人たちも予約管理システムを研修で作っているので、もしかしたらよくある案なのかも）
作成した構成
「1つのユーザーが複数の予約枠を予約できる」「1つの予約枠に複数のユーザーが登録できる」という関係から、user: slot = N : Nの関係になります。そのため、reservationsという予約情報を持たせる中間テーブルを間に置く構成としました。
ER図
users slots
┌──────────────┐ ┌───────────────────┐
│ id (PK) │ │ id (PK) │
│ name │ │ name │
│ email (UQ) │ │ starts_at │
│ created_at │ │ ends_at │
└──────┬───────┘ │ capacity │
│ │ created_at │
│ └─────────┬─────────┘
│ │
│ reservations │
│ ┌──────────────────┐ │
└─────▶│ id (PK) │◀┘
│ slot_id (FK) │
│ user_id (FK) │
│ status │
│ created_at │
│ cancelled_at │
└──────────────────┘
エンティティの関係
Slotエンティティ
| 属性 | 説明 |
|---|---|
| id | 識別子 |
| name | 予約枠の名称（例: 「10:00-11:00 会議室A」） |
| starts_at | 開始日時 |
| ends_at | 終了日時 |
| capacity | 定員（1以上の整数） |
| created_at / updated_at | 作成・更新日時 |
Userエンティティ
| 属性 | 説明 |
|---|---|
| id | 識別子 |
| name | 氏名・表示名 |
| メールアドレス（一意） | |
| created_at | 作成日時 |
Reservationエンティティ
| 属性 | 説明 |
|---|---|
| id | 識別子 |
| slot_id | 対象Slot |
| user_id | 予約したUser |
| status |
CONFIRMED / CANCELLED
|
| created_at | 予約作成日時 |
| cancelled_at | 取消日時（CANCELLEDのときのみ値を持つ） |
予約のステータス設計について
作成
(存在しない) ────▶ CONFIRMED ────▶ CANCELLED
│ 取消
│
▼
（再取消・再確定は不可、一方向のみ）
- 予約のステータスは「CONFIRMED」「CANCELLED」の二種類にしています。
- ユーザーが予約を作成すると、「CONFIRMED」の予約が作成されます。取り消しすると、予約を物理削除するのではなく「CANCELLED」として更新します。
- 今回は予約の定員管理と二重予約防止の部分を作ることに重きを置いたので、ステータスは二種類にとどめました。
やってみての感想
テーブル設計
なんといってもテーブル設計に手こずりました。予約管理システムで「ユーザーが必要」「予約枠が出てきそう」っていうのはなんとなく理解はできたのですが、それをテーブルにどう落とし込むのかという考え方がわかりませんでした。
色々調べていくうちに「1:多」「多:多」といったようなエンティティの関係性がDB設計に非常に重要であることがわかってきました。
ER図も職場のバックエンドチームで作っているのは知っていたのですが、なんのために作っているのかも正直よくわかっていませんでした。
今回ER図を作って、エンティティの関係性を意識しながら設計をすることで、なんとなく理解は深められた（気がする）。
API設計
POST, GET, PUT, DELETEなどのメソッドは知っていましたが、それらのメソッドを使って何を表現するか、ということを設計することもやってみるととても難しかったです。
「APIを作って」と言われても、頭が真っ白になって何を書けばいいかわからない状態になり、AIに色々ヒントをもらいながら実装していくことがやっとです（笑）。
ここは、自分で書いて作っていく経験が大事だな...と思います。
まとめ
（今回はだいぶAIの力を借りながらでしたが）バックエンドの設計とコードに挑戦してみました。途中、理解ができない部分もあり、「なんでこんなこともわからないんだろう...私ダメだわ...」ってなりそうになりましたが、
やっぱり新しいことを学ぶって素敵！！！！！
これからもどんどん新しい技術に挑戦して学んだことを記事にできればと思います