登録と申請が一体になっている

典型例

典型パターン：入力と申請が一体別タブで開く ↗

現行の画面遷移

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 完了画面

現行のテーブル構造

利用者の視点から

入力したら即座に申請される - 「登録」と「申請」が分かれておらず、下書き保存ができない
見直しのタイミングがない - 確認画面はあるが、そこで修正すると最初からやり直し
途中で中断できない - 入力→確認→完了の流れを一気に進めないといけない

開発・運用の視点から

「登録」と「申請」が密結合 - 本来は別の操作なのに、1つのフローにまとめられている
確認画面のためにセッション管理が必要 - 即座にDBに保存すれば不要
単純な登録なのにルートが7つある - ロジックが散らばり、変更時にどこを直せばいいかわからなくなる
テストが多いのは設計の問題 - 画面が多いからテストが多い。画面を減らせばテストも減る

再設計

適用する原則: 登録はその場で行う、状態と操作を分離する

再設計パターン：登録と申請を分離別タブで開く ↗

再設計の画面遷移

GET    /requests              申請一覧
POST   /requests              登録実行 → 未申請状態でDB保存
GET    /requests/:id          申請詳細（編集モード含む）
PUT    /requests/:id          更新
POST   /requests/:id/apply    申請実行 → ステータス更新

再設計のテーブル構造

設計のポイント

登録と申請を分離: 登録は「未申請」状態でDBに保存、申請は別の操作
申請は詳細画面から: 内容を確認してから申請ボタンを押す
セッション不要: すべてDBに保存されるため、セッション管理が不要
下書き保存が自然にできる: 途中で中断しても、後から続きができる

比較

画面遷移の比較

観点	典型	再設計
画面数	4画面	2画面（一覧・詳細）
ルート数	7	5
登録と申請	一体（1つのフロー）	分離（別の操作）
申請の実行	確認画面から	詳細画面から
下書き保存	できない	自然にできる
保存	セッション + DB	DB のみ
テストケース	多い（7ルート × 状態）	少ない（5ルート × 状態）
起きやすい不具合	セッション切れ、戻るボタン問題	構造的に発生しない

改修に向けて

変更	内容	効果
1	登録と申請を分離	下書き保存が可能に、セッション不要

変更1: 登録と申請を分離する

やること

登録時は「未申請」状態でDBに保存する
詳細画面を追加し、そこから「申請」を実行する
確認画面・完了画面を削除する

効果

下書き保存が自然にできる
申請前に内容を見直す時間ができる
セッション管理が不要になる
「セッション切れ」「戻るボタン問題」が構造的に消える

懸念への対応

懸念	対応
申請忘れが心配	未申請データの一覧表示、リマインダー通知
下書きが溜まる	一定期間後に自動削除、または明示的に削除
申請前の確認が必要	詳細画面で内容を確認してから申請ボタンを押す

進め方

自社プロダクトの場合

小さく試す: 特定の申請種別だけで試す
効果を測る: 問い合わせ件数やエラー発生率を確認する
横展開する: 成功事例をもとに他の申請にも適用

受託開発の場合

懸念を先に聞く: 「登録と申請のフローについてどうお考えですか？」
選択肢を示す: 顧客が判断できる材料を提供する
推奨を添える: 「弊社としては登録と申請を分離することを推奨します」

いきなり「こうします」ではなく、相手の立場を理解してから提案する。

補足: なぜ詳細画面から申請するのか

一覧からでも申請はできるが、詳細画面から申請する方が自然な理由:

申請前に内容を確認できる: 詳細画面で全項目を見てから申請ボタンを押す
修正と申請が近い: 修正が必要なら編集し、そのまま申請できる
一覧の役割が明確: 一覧は「どれがどの状態か」を把握する場所