Zenn
👌

ポートフォリオの要件定義をしてみた

2024/08/08に公開
Python
React
ER 図
要件定義
フローチャート
idea

元美容師のDjangoポートフォリオリニューアル日記：要件定義編

はじめに

こんにちは、元美容師現SES社員のやぎです。
現在開発に取り組んでいるDjangoポートフォリオですが実は開発前に要件定義をしておりましたので、ほぼ箇条書きになりますがアウトプットとして投稿したいと思います。Djangoポートフォリオについてはこちらの記事をご覧ください。

あくまで初学者の個人開発レベルですので、誤った記載があるかと思います。その場合はコメントで是非ご指摘お願いします。

プロジェクト概要

今回は開発を行うSalonLinkというアプリは、美容室の空席を貸し出したいサロンオーナーと、その席をレンタルして柔軟に働きたい美容師をマッチングするサービスです。
なぜこのアプリを作ろうと思ったかは開発日記PART.1の記事に記載しておりますのでお読みいただけると嬉しいです。

このアプリの主な目的：

  1. サロンオーナー：サロン空席のマネタイズ
  2. 美容師：場所と時間に縛られない柔軟な仕事が出来る

主要機能の定義

続いこのアプリ自体の主要機能についてです。
現段階では以下の6つとなります。
アプリのフローチャートも作成しましたので添付します。こちらのフローチャートはDrow.ioという無料ツールで作成しました。インストールも不要でGoogleドライブ等と連携することも可能で、初めての僕でも直感的に使えたのでおすすめです！後ほど記載するER図もこちらで作成しました！

1. ユーザー管理

  • サロンオーナーと美容師の2種類のユーザー
  • 登録、ログイン、プロフィール編集機能

2. サロン管理機能（オーナー向け）

  • サロン情報の登録・編集
  • 空席の追加・編集・削除
  • 予約状況の確認

3. 予約システム（美容師向け）

  • サロン検索
  • 空席の確認（カレンダー表示）
  • 予約作成・編集・キャンセル

4. カレンダー機能

  • 時間単位での予約状況表示
  • リアルタイムでの更新

5. 通知システム

  • 予約情報、メッセージ受信の通知

6. チャット機能

  • サロンオーナーと予約した美容師間でのコミュニケーション機能

データベース設計

続いて作成するテーブルとフィールドについてです。今回はER図も作成しました。
最初の想定ではサロンオーナーと美容師でテーブルを分けようと思っていたのですが、ユーザー管理や拡張性を考え、同じユーザーテーブルとしてuser_typeフィールドで判断するような設計にしました。

  1. Users（ユーザー）

    • id (PK)
    • user_type（オーナー/美容師）
    • name
    • email
    • password_hash
    • phone_number
    • profile_info
    • created_at
    • updated_at

  2. Salons（サロン）

    • id (PK)
    • owner_id (FK → Users)
    • name
    • address
    • phone_number
    • description
    • created_at
    • updated_at

  3. Seats（席）

    • id (PK)
    • salon_id (FK → Salons)
    • name
    • description
    • price_per_hour
    • minimum_booking_time
    • created_at
    • updated_at

  4. Bookings（予約）

    • id (PK)
    • seat_id (FK → Seats)
    • stylist_id (FK → Users)
    • start_time
    • end_time
    • status
    • created_at
    • updated_at

関係性：

  • Users 1--* Salons（1人のオーナーが複数のサロンを所有可能）
  • Salons 1--* Seats（1つのサロンに複数の席）
  • Users(Stylists) 1--* Bookings（1人の美容師が複数の予約）
  • Seats 1--* Bookings（1つの席に対して複数の予約）

API設計

APIの設計をGET、POST、PUT、DELETEでしていきます。
RESTful APIってやつですね！

  1. ユーザー (Users)

    • POST /api/users/register - 新規ユーザー登録
    • POST /api/users/login - ユーザーログイン
    • GET /api/users/{id} - ユーザー情報取得
    • PUT /api/users/{id} - ユーザー情報更新
    • DELETE /api/users/{id} - ユーザー削除

  2. サロン (Salons)

    • POST /api/salons - 新規サロン登録
    • GET /api/salons - サロン一覧取得
    • GET /api/salons/{id} - サロン詳細取得
    • PUT /api/salons/{id} - サロン情報更新
    • DELETE /api/salons/{id} - サロン削除

  3. 席 (Seats)

    • POST /api/salons/{salon_id}/seats - 新規席登録
    • GET /api/salons/{salon_id}/seats - サロンの席一覧取得
    • GET /api/seats/{id} - 席詳細取得
    • PUT /api/seats/{id} - 席情報更新
    • DELETE /api/seats/{id} - 席削除

  4. 予約 (Bookings)

    • POST /api/bookings - 新規予約作成
    • GET /api/bookings - 予約一覧取得
    • GET /api/bookings/{id} - 予約詳細取得
    • PUT /api/bookings/{id} - 予約更新
    • DELETE /api/bookings/{id} - 予約キャンセル

追加のユースケース特有のエンドポイント:

  • GET /api/salons/{salon_id}/availability - サロンの空き状況取得
  • GET /api/stylists/{stylist_id}/schedule - 美容師のスケジュール取得

ユーザーごとの権限

ユーザー毎の権限を決めました。権限については現段階での想定の為変更する可能性もあります。

ユーザーごとの権限：

  • サロンオーナー：自身のサロン情報管理、席の追加/編集/削除、予約確認
  • 美容師：予約作成/編集/キャンセル、自身の情報編集

技術スタック

  1. バックエンド：

    • Django
    • Django REST Framework

  2. フロントエンド：

    • React (TypeScript)

  3. データベース：

    • PostgreSQL

  4. 開発環境：

    • Docker
    • GitHub

要件定義をしてみて

お恥ずかしい話ですが、僕は今まで個人開発で要件定義はほぼ実施しておりませんでした。頭の中で「こんな感じのアプリを作りたい」といったイメージのみで教材を漁って開発をしていました。

今回要件定義をした理由はポートフォリオとしての厚みがでるかなと思ったこともありますが、それ以上に以前に比べて圧倒的に開発がスムーズに進むようになりました。
開発前にしっかりとしたイメージを持って取り組むことで設計について悩むことが減りました。

今まで個人開発で要件定義なんてしたことがないという方も、簡単でいいので要件定義のドキュメント作成をしてみると今までと違った視点で開発を進めることができるかもしれません。

では引き続き開発日記を投稿していく予定なので気長に見守っていただけると幸いです。
次回の記事もお楽しみに！

やぎ

Discussion