アンチパターン早見表

レビューや設計時に「これ大丈夫かな？」と思ったときの参考に。

---

画面設計

危険なワード	問題	解決策	原則
「確認画面」	フローの中断、流し読み	Undo・取り消しに置き換え	確認画面は最低限に
「登録画面」	コンテキスト喪失	一覧にインライン追加	登録はその場で
「編集画面」	無駄な遷移	詳細画面に編集モード	編集はその場で
「ステップ1/2/3」	順序の強制	不足条件の明示	不足を画面で示す

---

DB設計

危険なワード	問題	解決策	参考
temp_フラグ	UIの都合がDBに漏れる	状態カラムで管理	状態と操作を分離
is_draft	下書き保存と保存が分離	保存は1つ、状態は別	下書き保存パターン
セッション保存	確認画面のための一時保存	常にDB保存	入力→確認→申請

---

ルート設計

危険なパターン	問題	解決策
/new と /edit が別	同じフォームなのに分離	同一ルートで対応
/confirm が必須	確認のためだけの画面	モーダルまたは削除
/back がある	「戻る」という操作が必要	画面遷移自体を見直す
ルートが7つ以上	複雑すぎる	3ルート以下を目指す

---

チェックリスト

設計レビュー時に確認：

• 1つの操作に3画面以上の遷移がないか
• 確認画面は本当に必要か（取り消しで代替できないか）
• 登録・編集が別画面になっていないか
• セッションに一時データを保存していないか
• DBにtemp_や_flgが増えていないか
• ルート数は3つ以下か

---

例外の判断

「うちは特殊だから…」と思ったら確認：

質問	はい → 例外かも	いいえ → 例外ではない
法的に確認画面が必要？	電子契約、金融取引など	社内システムの大半
操作が本当に不可逆？	外部API連携、物理的な発送	DB更新のみなら取り消し可能
複数人の承認が必要？	ワークフローで対応	確認画面は承認ではない

詳細は シンプルにできない領域 を参照。