Feature #253
Updated by 關山 和丈 2 months ago
不要なのでは?
配送一覧がそもそも誰でも対応できるための候補
確実に担当が決まっている患者のみにhome_careで設定するため
```
複数割り当てを許容するかどうかの判断ポイントと設計案を整理しました。
運用面の要件確認: 欠員時の代替・当日柔軟対応・情報共有の可視化が主目的なら、「主担当＋副担当」や「複数担当（役割付き）」のどちらが妥当かを決める。
記録したいデータ: planごとの準備時間、配達～対応～帰着までの所要時間を「誰がどこにどれだけ関わったか」で紐付けたい。
設計案（シンプル→リッチ）
主担当＋副担当（少人数固定）
plansにprimary_pharmacist_idとbackup_pharmacist_idカラムを追加。
欠員対応と情報共有を最低限担保しつつ、複数割り当ての自由度は限定。
工数トラッキングは別テーブル（例: plan_work_logs）でpharmacist_idと工数/区間を記録。
多対多の担当テーブル（推奨の汎用形）
中間テーブル例: plan_pharmacists(plan_id, pharmacist_id, role, assigned_at, unassigned_at, notes)。
役割: primary, backup, supportなどをenumで管理。
工数/区間は別テーブルで記録: plan_work_logs(plan_id, pharmacist_id, task_type, started_at, ended_at, duration_seconds, notes)。
task_type: prep, delivery, patient_care, return_tripなどで分析粒度を確保。
利点: 欠員・繁忙対応が柔軟、将来的な分析軸（誰がどれだけ対応したか）が取りやすい。
注意: UIとバリデーションで「必ず主担当1人」「副担当は任意」などの運用ルールを付けて複雑さを抑える。
イベントログ駆動
plan_events(plan_id, pharmacist_id, event_type, occurred_at, payload)で全イベントを記録し、担当はイベントから導出。
もっとも柔軟で分析向きだが、集計コストと運用UIが重め。
おすすめ
運用ルールが「主担当必須＋副担当任意」なら案2をベースにroleで制約をかけるのがバランス良いです。
工数計測は担当テーブルとは分離し、plan_work_logsのようなログテーブルで区間やタスク種別を持つと分析しやすく、履歴も消さずに済みます。
データ整合の基本: 主担当は一意制約、同一roleの重複は禁止、過去の担当変更はassigned_at/unassigned_atで履歴保持。
将来の分析に備えてtask_typeとduration（あるいはstarted_at/ended_at）を必ず持たせ、pharmacist_idで紐付ける設計を優先すると良いでしょう。
```
Back