要件をデータモデルに落とす
エンティティ、関連、状態機械。そして、いずれ必ず変わるフィールド
この要件をデータモデルに落としてください。コードはまだ書きません。出力：1）エンティティ一覧。それぞれが現実の何を表すかを一文で；2）エンティティ間の関連と多重度。多対多で中間テーブルが要るものを示す；3）中核オブジェクトの状態機械（状態、遷移のトリガー、不可逆な遷移）；4）今は足りて見えるが半年以内に変わりそうなフィールド（価格、権限、多言語、論理削除）；5）要件が不明確で、先にプロダクトに確認すべき点を3つ。 ［要件を貼り付けてください］
使い方
5番の疑問はそのままプロダクト担当に聞きましょう。当て推量でモデリングするよりずっと楽です。
向いている場面
- 要件レビューが通った直後で、見積もりの前にテーブル構造と影響範囲を出したいとき。
- この機能が「フィールド追加」なのか「エンティティ追加」なのかを、リリース 2 か月後のテーブル分割の前に判断したいとき。
向いていない場面
- 要件が「ざっくり会員制度を作る」の段階なら、まず役割とフローを確認します。今モデルを作っても空になります。
- 一度きりのレポートやエクスポートなら、一時テーブルかビューで足ります。長期のモデルは作りません。
例
入力
要件：ユーザーは実店舗のサービスを予約できる。1 つの予約に 1〜3 のサービス項目を含み、担当スタッフを指定できる。 24 時間前までは無料でキャンセルでき、それ以降は 30% の取消料。 店舗は一時休業でき、休業中の既存予約は自動でキャンセルし返金する。
得られるもの
user、store、service_item、technician、booking、booking_item、payment/refund の 7 エンティティを出します。booking と service_item は多対多で、booking_item という中間テーブルに価格のスナップショットと担当者を持たせる必要があると示します。24 時間の境界と返金率は、pending → confirmed → completed / cancelled_by_user / cancelled_by_store の遷移条件として書き、cancelled が不可逆であることを明記します。最後に、変わりやすいフィールドとして価格（スナップショット）、キャンセル規定（店舗やキャンペーンで変わる）、タイムゾーンを挙げます。
よくある誤用
- 要件を 1 文だけ貼って DDL を出させると、書いていないルールを補完し、それが仮定だと示しません。
- フィールド一覧をそのまま最終スキーマとして扱い、「誰が書き、誰が読み、誰が変えるか」の確認を飛ばします。
こう変えると効く
- 「仮定はすべて別に列挙して。プロダクトに確認します」と加えると、出力がモデルから確認リストに変わります。
- 「半年後にチェーン展開と店舗をまたぐ担当者に対応するとしたら」と加えると、エンティティ境界の問題が早く出ます。