入力順序をStepで固定する

ケース：経費精算システム

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

システム要件

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

典型例

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

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 まで進む必要がある
• 全体を把握しにくい - いま何が入力済みで、何が足りないのか一目でわからない
• 修正に手間がかかる - 明細を1行追加するためにStep3に戻り、確認画面まで進み直す
• 代理入力が煩雑 - 秘書が途中まで入力し、本人が続きを入力する場合、「どのStepまで進んだか」を伝える必要がある

開発・運用の視点から

• セッション管理が複雑 - 4つのStep分のデータをセッションで保持し、整合性を担保する必要がある
• ルートが多い - 12ルートあり、それぞれのテストとエラーハンドリングが必要
• 状態が2軸ある - step_no（どこまで進んだか）と temp_flg（仮保存か）の両方を管理する
• テストケースが多い - 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 のみ
テストケース	多い（12ルート × Step遷移パターン）	少ない（8ルート × 状態）
起きやすい不具合	セッション切れ、Step間の整合性崩れ	構造的に発生しない

---

改修に向けて

再設計には3つの変更がある。一度にやる必要はない。

変更	内容	効果
1	下書き保存（draft）を導入	セッション不要、途中離席可能
2	Step画面を詳細画面のセクションに統合	画面数とルート数が減る
3	不足条件表示を追加	順番の制約がなくなる

変更1だけでも「セッション切れで消える」問題は解消する。

変更1: 下書き保存を導入する

やること

• 新規作成時に空のレコードを作成する（status=draft）
• 各Stepの内容を即座にDBへ保存する
• セッション管理を廃止する

効果

• セッション切れで入力が消えなくなる
• 途中離席しても続きから再開できる
• 代理入力時に「どこまで進んだか」を伝える必要がなくなる

変更2: Step画面を詳細に統合する

やること

• Step1〜4の画面を削除する
• 詳細画面内に「セクション」として統合する（基本/旅程/明細/添付）
• 各セクションを独立して編集可能にする

効果

• 画面数が7から2に減る
• 任意の順番で入力できる
• 添付だけ差し替えたいときに、他のセクションを通過する必要がない

変更3: 不足条件表示を追加する

やること

• 申請に必要な条件をビジネスロジックとして定義する
• 詳細画面の上部に「未入力項目」を表示する
• 条件を満たすまで申請ボタンを非活性にする

効果

• 「いま何が足りないか」が一目でわかる
• Step番号という概念が不要になる
• 入力順序の自由度が上がる

進め方

自社プロダクトの場合

1. 影響範囲を確認する: 申請後の承認フローに影響がないことを確認
2. 下書き保存から始める: 変更1だけでも効果がある
3. 段階的に統合する: 変更2、3は優先度を見て順次対応

申請系は承認フローと連動していることが多い。上流の変更が下流に影響しないか確認してから進める。

受託開発の場合

1. 現行の運用を確認する: 代理入力がどの程度あるか、途中離席がどの程度あるか
2. 課題を共有する: セッション切れの問い合わせ件数など、具体的な数字で示す
3. 段階的な提案をする: 「まず下書き保存を導入し、効果を見てから統合を検討」

補足: 承認フローとの関係

申請系の再設計では、以下の点を確認する。

確認事項	注意点
承認者は何を見るか	申請時点のスナップショットか、最新のデータか
差し戻し後の編集	差し戻されたら draft に戻すか、別の状態を設けるか
代理申請	作成者と申請者を分けて記録するか

これらは業務要件に依存するため、先に確認してから設計を進める。