[Go static/refactor] shift_usecase.go の連鎖 Find→Scan リファクタ（ineffassign 12件・対象4関数）

[taminororo]

現状（2026-06-23 更新）

当初の主対象だった GetShifts / GetShiftByID / GetShiftsByUser / GetShiftsByUserAndDateAndWeather は、いずれも未使用エンドポイントだったため #376 / PR #377 で削除済み。これに伴い ineffassign の大半が解消し、shift_usecase.go は 1604 → 1133 行に縮小した。

• ineffassign: 約60 → 13件（uncapped）。うち shift_usecase.go は 12件
• 旧本文で触れていた line 122 付近の rows.Scan 誤り疑いは、該当の GetShifts が削除されたため解消済み

残っている対象（すべて LIVE。テストを書く価値がある）

連鎖 Find→Scan と中間エラーの握り潰しが残るのは、生きている次の4関数。

関数	ineffassign	備考
GetUsersByShift	7件	#353 でシフト担当者が空になった不具合の関数。密度が最も高い
GetShiftAdminByID	1件	DeleteShiftAdmin が内部利用するため残した関数
CreateShiftAdmin	2件
UpdateShiftAdmin	2件

ファイル: api/lib/usecase/shift_usecase.go
件数確認: golangci-lint run --max-same-issues=0 --max-issues-per-linter=0

なぜ機械修正でなく設計を伴うか（変わらず）

各関数で Find→Scan が連鎖し、中間の Scan エラーが握り潰されている（最後の Scan の err しかチェックしていない）。

row, err := a.rep.Find(c, id)
err = row.Scan(...)                 // err 上書き（中間エラー握り潰し）
row, err = a.taskRep.Find(c, taskID)
err = row.Scan(...)                 // さらに上書き
if err != nil { return shift, err } // 最後の Scan のみ検出

ここに機械的に if err != nil { return } を挿入すると、今まで隠れていた中間エラーが表面化して挙動が変わりうる（例: 削除済みタスクを参照するシフトが、空表示 → エラー）。テストが無い本番コードなので一括変更はリスクが高い。

やること

1. 対象4関数に characterization テスト（入出力テスト）を先に書く。リファクタ前後で挙動が一致することを担保する。対象は全て LIVE なので、死にコードにテストを書く無駄打ちにはならない。
2. 連鎖 Find→Scan をヘルパー関数に切り出し、各段でエラーを検出・ラップする。
3. パッケージレベルのグローバル変数 var TaskID, UserID, YearID, DateID, TimeID, WeatherID, PlaceID string（shift_usecase.go:66）を削除する。主な利用元だった GetShifts 系が消え、残った関数は構造体フィールド（shift.TaskID など）へ Scan していて、グローバルへの bare 参照は無い。エクスポート名のため unused linter が検出しないので手動で消す。削除前に api 全体で bare 参照が無いことだけ確認する。

着手順（価値順）

ineffassign が最も多く（7件）、過去に #353 で事故った GetUsersByShift から入るのが安全で効果的。

関連

• [Go static/refactor] 未使用の shift エンドポイントを削除 #376 / PR refactor: 未使用の shift エンドポイントを削除 #377（未使用 shift エンドポイント削除。本issueの前段で対象を大幅に縮小）
• [Go static] ineffassign: 無効な代入の解消 (3件) #360（単発 Find→Scan の機械修正）
• [Go static] golangci-lint 指摘の解消（親タスク） #314（Go 静的解析 親タスク）