フェーズ2 — 詳細タスク
スタッフのスコープ（このプロダクトでの前提）
-
目的: 検査表（画面・帳票）を見たときに「佐藤」「鈴木」のように 誰が検査したか分かればよい（表示・記録用）。
-
やらない: 検査した人で検索する機能は 不要（実施者名でのフィルタ・一覧検索はスコープ外でよい）。
-
必須データ: 名前が分かること（表示名／氏名など 1 列で足りるレベル）。
-
一旦省くもの: ログインID・メール・パスワード・ロールを スタッフ1件＝1ユーザー として縛る設計（必要になったら後から アカウントとスタッフの紐づけ を足す）。
フェーズ2のゴール（想定）
-
スタッフマスタ（名前中心）を DB で持てる か、検査レコードに 実施者名をそのまま保存するだけでもよい（表示さえできればよいため。正規化は好みで決める）。
-
（任意） アプリ全体の ログイン／認可 — スタッフの「氏名マスタ」とは切り離して検討する（フェーズ2の最小なら「開発用の単一ユーザー」や後回しで可）。
（フロントは別フェーズでもよいが、API は Postman/curl で検証できる状態）
1. ドメイン・DB
| # |
タスク |
補足 |
| 1.1 |
スタッフの要件を固定する |
表示に使う名前（必須）。必要なら 表示順・有効フラグ 程度まで。 |
| 1.2 |
ER を紙または Mermaid で書く |
検査1件に 実施者の表示名が載る形（staff_id 参照 または examiner_name 文字列など）。実施者での検索は設計不要
|
| 1.3 |
Flyway（または Liquibase）を導入 |
V1__create_staff.sql など |
| 1.4 |
staff テーブル作成マイグレーション |
PK、name（NOT NULL）、created_at など。login / email / password 列は 持たない方針で OK
|
| 1.5 |
（後回し可）「ログインユーザー」との関係 |
将来、アカウントとスタッフを紐づけるなら別テーブル or staff.user_id を検討 |
| 1.6 |
JPA エンティティ Staff とリポジトリ |
または JDBC Template + DAO（方針に合わせる） |
2. セキュリティ（Spring Security）— スタッフマスタとは別軸
| # |
タスク |
補足 |
| 2.1 |
認証の要否を決める |
名前マスタだけなら、API を一旦オープンにする期間もあり得る。本番想定なら 早めに最低限の認証を。 |
| 2.2 |
spring-boot-starter-security 追加 |
pom.xml |
| 2.3 |
SecurityFilterChain 定義 |
公開パスと保護パスの切り分け |
| 2.4 |
UserDetailsService |
スタッフテーブルと同一にしない（ログイン用ユーザーは別定義が分かりやすい） |
| 2.5 |
パスワードエンコーダ |
ログインを実装する場合は BCryptPasswordEncoder
|
| 2.6 |
ロール設計 |
例: ROLE_ADMIN, ROLE_STAFF — 職種マスタではなく認可用
|
| 2.7 |
メソッド／URL レベル認可 |
@PreAuthorize または requestMatchers
|
| 2.8 |
CORS 方針 |
フロント URL が決まっていれば CorsConfigurationSource
|
| 2.9 |
CSRF |
セッション + ブラウザから API なら CSRF を検討；SPA + JWT なら別 |
3. スタッフ API（名前マスタ）
| # |
タスク |
補足 |
| 3.1 |
POST /api/staff |
名前（と任意フィールド） の登録。パスワードは ない
|
| 3.2 |
GET /api/staff/{id} / GET /api/staff
|
マスタを持つ場合のみ。検索要件がないので、件数が少なければ 全件返しで十分なことも多い（ページングは任意） |
| 3.3 |
PATCH /api/staff/{id} |
名前の修正・無効化など |
| 3.4 |
入力検証 |
名前 @NotBlank など |
| 3.5 |
エラーレスポンスの形式を統一 |
例: problem+json または自前 JSON |
| 3.6 |
シードデータ（任意） |
開発用に「山田太郎」など 1〜2 件をマイグレーション or data で投入 |
4. テスト・品質
| # |
タスク |
補足 |
| 4.1 |
@WebMvcTest |
認証を入れたら 401/403；入れなければ通常の API テスト |
| 4.2 |
@DataJpaTest またはリポジトリテスト |
name NOT NULL など |
| 4.3 |
Testcontainers で結合テスト（任意） |
CI と本番に近い MySQL |
5. 運用・ドキュメント（最小）
| # |
タスク |
補足 |
| 5.1 |
.env.example |
JWT や管理用シークレットを使うなら追記 |
| 5.2 |
README |
起動・マイグレーション・サンプルスタッフがあれば一言 |
推奨する実装順（依存関係）
-
1.3 → 1.4 → 1.6（DB と
Staff エンティティ）
-
3.1 → 3.2 → 3.3 → 3.4（名前マスタ API）
-
2.x（アプリの認証が必要になったタイミングで）
-
4.x（テスト）
意思決定が残りやすい点
-
認証をフェーズ2に含めるか: 名前マスタだけなら 後回しも可。公開 API にするならネットワーク制限など別のリスク整理。
-
検査レコード側: 実施者は
staff_id で参照（名前変更に追従）か、実施者名を文字列で保存（スナップショット）か。実施者名での検索はしない前提なら、実装の簡単さ重視で 文字列1本でも十分なことが多い。
