ありがちな状態

画面設計の問題が蓄積すると、システムはこのような状態になりがちです。

セッション地獄

よくある症状

• 確認画面のためにセッションに一時保存している
• 「戻る」ボタンでセッションを復元している
• セッション切れでデータが消える
• 複数タブで開くと壊れる

コードの例

session.set('input_data', formData)
session.get('input_data')
session.clear('input_data')

なぜこうなるか

「入力 → 確認 → 完了」の画面遷移を作ると、確認画面で入力データを保持する必要があります。DBに保存するのは「確定後」なので、それまでセッションに置くしかありません。

---

ルートの乱立

よくある症状

GET    /users/new           新規登録画面
POST   /users/new/confirm   確認画面へ
GET    /users/new/confirm   確認画面
POST   /users/new/back      入力に戻る
POST   /users/new/submit    登録実行
GET    /users/new/complete  完了画面

GET    /users/:id/edit      編集画面
POST   /users/:id/confirm   編集確認画面へ
GET    /users/:id/confirm   編集確認画面
POST   /users/:id/back      編集に戻る
PUT    /users/:id/submit    更新実行
GET    /users/:id/complete  更新完了画面

数えてみると

• 1つのCRUD操作に 12ルート
• 新規と編集で似たルートが重複
• /confirm, /back, /complete が増殖

なぜこうなるか

「画面 = ルート」という発想で設計すると、画面が増えるたびにルートも増えます。

---

DBの歪み

よくある症状: temp_flg の存在

CREATE TABLE applications (
  id INT,
  user_id INT,
  content TEXT,
  temp_flg BOOLEAN,      -- 一時保存フラグ
  confirmed_flg BOOLEAN, -- 確認済みフラグ
  submitted_flg BOOLEAN, -- 申請済みフラグ
  ...
);

よくある症状: status の肥大化

-- statusの値が増え続ける
status = 'draft'
status = 'temp_saved'
status = 'input_complete'
status = 'confirmed'
status = 'submitted'
status = 'approved'
status = 'rejected'
status = 'cancelled'
status = 'deleted'  -- 論理削除

よくある症状: セッション用テーブル

CREATE TABLE form_sessions (
  session_id VARCHAR(255),
  form_type VARCHAR(50),
  step_no INT,
  input_data JSON,
  created_at TIMESTAMP,
  updated_at TIMESTAMP
);

なぜこうなるか

画面の都合でDBが設計されると、「一時保存」「確認済み」「入力途中」といった画面の状態がそのままカラムになります。

DBには「ビジネスの状態」を保持し、「UIの工程」は保持しないのが望ましいです。

---

画面遷移の多さ

よくある症状: 1操作に3画面以上

ユーザーを1人追加するのに:
一覧 → 新規登録画面 → 確認画面 → 完了画面 → 一覧

合計: 5画面遷移

よくある症状: 「戻る」の複雑さ

• 確認画面から入力画面に戻る
• 戻ったときに入力値を復元する
• 「戻る」と「キャンセル」の違い
• ブラウザバックで壊れる

よくある症状: 完了画面の存在

「登録が完了しました」
[一覧に戻る]

一覧に戻って「登録しました」と表示すれば、この画面は不要かもしれません。

---

コントローラーの肥大化

よくある症状: 1つの操作に複数メソッド

class UserController {
  newForm()      // 新規登録画面
  confirmNew()   // 確認画面へ
  showConfirm()  // 確認画面
  backToNew()    // 入力に戻る
  submitNew()    // 登録実行
  complete()     // 完了画面

  editForm()     // 編集画面
  confirmEdit()  // 編集確認画面へ
  ...
}

よくある症状: 似たようなバリデーションの重複

• 新規登録のバリデーション
• 編集のバリデーション
• 確認画面でのバリデーション
• 微妙に違うが、ほぼ同じ

---

テストの困難さ

よくある症状: テストケースの爆発

# 確認画面ありの場合のテストケース
- 入力画面の表示
- 入力バリデーション
- 確認画面への遷移
- 確認画面の表示
- 確認画面から戻る
- 確認画面から実行
- 完了画面の表示
- セッション切れの場合
- ブラウザバックの場合

ルートが12個あれば、テストケースもそれに比例して増えます。

よくある症状: 状態の組み合わせ

セッションを使う設計では、テストで考慮すべき状態が増えます：

• セッションがある/ない
• セッションが有効/期限切れ
• 入力途中/確認済み/完了
• 複数タブで開いた場合

状態の組み合わせが増えるほど、テストは複雑になります。

よくある症状: E2Eテストの脆弱さ

# 画面遷移が多いE2Eテスト
1. 一覧画面を開く
2. 「新規登録」ボタンをクリック
3. フォームに入力
4. 「確認」ボタンをクリック
5. 確認画面を待つ
6. 「登録」ボタンをクリック
7. 完了画面を待つ
8. 「一覧に戻る」をクリック
9. 一覧に追加されたことを確認

ステップが多いほど、どこかで失敗する確率が上がります。

なぜこうなるか

画面が増えれば、テストも増えます。セッションを使えば、状態の組み合わせが増えます。テストが書きにくい設計は、使いにくい設計であることが多いです。

---

チェックリスト

自分のシステムを確認してみてください。

チェック項目	ある？
確認画面用のセッション管理	□
/confirm, /complete ルート	□
temp_flg, confirmed_flg カラム	□
1操作に3画面以上の遷移	□
「完了しました」画面	□
新規と編集で似たルートが重複	□
E2Eテストが5ステップ以上	□

3つ以上当てはまったら、改善の余地があるかもしれません。