改善パターン

画面遷移を減らす、具体的な改善パターンを紹介します。

パターン1: 確認画面の削除

現状: 入力 → 確認 → 完了（3画面）

改善案: 入力 → 完了（2画面）+ 取り消し機能。

• 確認画面を削除
• 代わりに「取り消し」ボタンを追加
• または確認モーダルに置き換え

効果: 画面遷移が1つ減る。セッション管理が不要になる。テストケースも減る。

詳細は 登録に確認画面を挟む、編集に確認画面を挟む を参照

---

パターン2: 編集画面の統合

現状: 一覧 → 詳細 → 編集（3画面）

改善案: 一覧 → 詳細（編集モード付き）（2画面）

• 編集画面を削除
• 詳細画面に「編集モード」を追加
• 参照/編集をトグルで切り替え

効果: 画面が1つ減る。コンテキストが保たれる。ルートが減り、テストも単純になる。

詳細は 編集に確認画面を挟む を参照

---

パターン3: 登録画面の統合

現状: 一覧 → 登録画面 → 一覧（画面遷移あり）

改善案: 一覧（インライン追加）（画面遷移なし）

• 登録画面を削除
• 一覧に「+ 追加」行を表示
• その場で入力・保存

効果: 画面遷移がゼロになる。既存データを見ながら追加できる。E2Eテストのステップも減る。

詳細は 複製後に登録フローを経由する を参照

---

パターン4: モーダルの削除

現状: 一覧 → モーダルで編集。

改善案: 一覧 → インラインで編集。

• モーダルを削除
• 行をクリックで編集モードに
• 他の行を見ながら編集可能

効果: 背景が見えたまま操作できる。複数行を同時に編集可能。

詳細は 検索条件と結果を別画面にする を参照

---

共通するポイント

• 画面を減らす（遷移を減らす）
• その場で操作できる（コンテキストを保つ）
• 戻る操作を不要にする
• テストを単純にする（状態の組み合わせを減らす）

シンプルな設計は、テストもシンプルになります。テストが書きにくいと感じたら、設計を見直すきっかけかもしれません。