入力→確認→申請パターン

例：購入申請システム

備品や消耗品の購入を申請し、承認を受ける。

適用する原則: 登録はその場で行う、確認画面は最低限にする

要件

品名・カテゴリ・金額・購入理由などを入力
入力内容を確認してから申請
申請後は承認待ち状態になる

典型

典型パターン：入力→確認→完了別タブで開く ↗

現行の画面遷移

GET    /requests              申請一覧
GET    /requests/new          入力画面
POST   /requests/new/confirm  確認画面へ → セッション保存
GET    /requests/new/confirm  確認画面   ← セッションから表示
POST   /requests/new/back     修正する   → 入力画面へ戻る
POST   /requests/new/submit   申請実行   → DB保存
GET    /requests/new/complete 完了画面

現行のテーブル構造

起きる問題

入力 → 確認 → 完了と3画面を遷移する
確認画面のためにセッション管理が必要
ルートが多い（7ルート）

再設計

再設計パターン：1画面で完結別タブで開く ↗

再設計の画面遷移

GET    /requests   申請一覧（登録フォーム含む）
POST   /requests   登録実行 → 未申請状態でDB保存
PUT    /requests/:id/apply   申請実行 → ステータス更新

再設計のテーブル構造

設計のポイント

登録と申請を分離: まず「未申請」状態でDBに保存し、後から申請
確認はモーダル: 一覧上の「申請」ボタンで確認モーダルを表示
セッション不要: すべてDBに保存されるため、セッション管理が不要
2段階操作: 登録と申請を分けることで、ユーザーに考える時間を提供

比較

画面遷移の比較

観点	典型	再設計
画面数	4画面	1画面
ルート数	7	3
確認	別画面	モーダル
完了	別画面	ステータス更新
保存	セッション + DB	DB のみ
操作	入力→確認→申請	登録→申請