ステップフォーム（順序固定）パターン

例：経費精算システム

出張や経費の申請を作成し、承認を受ける。

適用する原則: ステップではなく不足条件で示す

要件

• 添付（領収書・予約票）が途中で差し替わる
• 交通・宿泊・日当など明細が複数行（増減あり）
• 申請者≠作成者（秘書・総務が代理入力するケースあり）

---

典型

典型パターン 別タブで開く ↗

GET    /trip-requests                  一覧
GET    /trip-requests/new/step1        Step1 基本情報
POST   /trip-requests/new/step1        次へ → セッション保存

GET    /trip-requests/new/step2        Step2 旅程（交通/宿泊）
POST   /trip-requests/new/step2        次へ → セッション保存

GET    /trip-requests/new/step3        Step3 経費明細
POST   /trip-requests/new/step3        次へ → セッション保存

GET    /trip-requests/new/step4        Step4 添付
POST   /trip-requests/new/step4        次へ → セッション保存

GET    /trip-requests/confirm          確認画面 ← セッションから表示
POST   /trip-requests/submit           申請実行 → DB保存
GET    /trip-requests/complete         完了画面

起きがちな破綻

• 添付差し替えのたびに Step4 に戻る
• 明細追加で Step3 が崩れる（整合性がステップ順序に依存）
• 代理入力時に「どのStepの情報か」が曖昧

---

再設計

再設計パターン 別タブで開く ↗

GET    /trips                          一覧
POST   /trips                          作成 → 空の出張を作る（status=draft）
GET    /trips/:id                      詳細（セクション編集＋不足表示）

PUT    /trips/:id/basic                基本情報 → DB保存
PUT    /trips/:id/itinerary            旅程 → DB保存
PUT    /trips/:id/expenses             経費明細 → DB保存
PUT    /trips/:id/files                添付 → DB保存

POST   /trips/:id/submit               申請（操作）→ DB保存

UIの要点

• 一覧画面で出張件名のみで新規作成（インライン登録）
• 詳細画面内でセクションを分ける（基本/旅程/明細/添付）
• 「順番」ではなく不足条件を上部に出す
  • 例：未入力：旅程(交通) / 添付(領収書1件以上)
• 申請は「操作」であり、直前に確認モードを出す

---

比較

観点	典型	再設計
画面数	7画面	2画面
ルート数	12	8
UIの進行	Step番号で前進	状態＋不足項目
修正	特定Stepに戻る	該当箇所だけ直す
添付差替え	工程が壊れやすい	追加/削除が独立
状態管理	step_no, temp_flg	status のみ