processGroup の N+1 問題解消（user/date/weather のバッチ取得）

[taminororo]

開発概要

目的

• notification_usecase.go の processGroup 関数で発生している N+1 問題を解消する
• shift / task のバッチ化と同じ手法で、user / date / weather もバッチ取得に統一する
• 通知件数増加時のDB負荷を線形ではなく定数時間に抑える

開発期間

• 開始日：
• 締切日：

考えられる開発内容

1. N+1 箇所の特定（既知）

1.1 processGroup 関数内の個別Find

ファイル: api/lib/usecase/notification_usecase.go

• L225: `n.userRep.Find(ctx, ...)` をバッチ化
• L244: `n.dateRep.Find(ctx, ...)` をバッチ化
• L278: `n.weatherRep.Find(ctx, ...)` をバッチ化

10ユーザー × 5日間で50グループ = 150 個別クエリ発生。

2. 実装方針

既存の `loadShiftMap` / `loadTaskMap` と同じパターンで以下を追加：

• `loadUserMap(ctx, logs)` を実装
• `loadDateMap(ctx, logs)` を実装
• `loadWeatherMap(ctx, shiftMap)` を実装（shiftMapからweatherIDを抽出）
• `processGroup` のシグネチャに userMap / dateMap / weatherMap を追加
• 個別Findを削除してmapからのlookupに置き換え

3. 関連箇所の調査（uchidaさん提案）

• notification系の他関数で同種のN+1がないか確認
• 修正後、通知件数の多いケースでクエリ数を実測

備考

• PR シフト変更通知機能 #254 のレビュー中、Copilot が `notification_usecase.go:288-308` で指摘
• 親Issue: バックエンドのN + 1問題の解消 #247（バックエンドのN+1問題の解消）
• レビューで uchida189 さんから「別Issue化してまとめて修正でもOK」と提案あり

参考

開発の流れ

1. PMにIssue（タスク）をもらう
2. 開発をする（↓の「リンク」の『開発のやり方』を見よう！）
3. チェックボックスを押していこう
4. ヤバい状況になったらIssueの右側にあるStatusを「Help」にしてPMにSlackで連絡しよう
5. チェックボックスが全部押せたらプルリクを作ろう
6. レビューを待とう
7. 修正点があれば修正しよう。なければPMがマージします！お疲れ様！

リンク

• 開発のやり方
• SeeFT Projects
• 親Issue: バックエンドのN + 1問題の解消 #247
• 兄弟Issue: getShiftCardsByUserAndDateAndWeather の N+1 問題解消 # 251 #251, UpdateShiftsFromGASの N + 1問題の解消# 252 #252
• 関連PR: シフト変更通知機能 #254