よくある問題
善意から生まれる
Section titled “善意から生まれる”画面が増えすぎる問題は、悪意や怠慢から生まれるわけではありません。
むしろ、以下のようなよくある動機から生まれることが多いです:
| 動機 | 結果 |
|---|---|
| 安全にしたい | 確認画面を増やす |
| 分かりやすくしたい | 画面を分ける |
| 整理したい | 登録と編集を別画面に |
| 再利用したい | 汎用モーダルを作る |
どれも理解できる動機です。ただ、整理の仕方によっては、かえって複雑になってしまうことがあります。
なぜ繰り返されるか
Section titled “なぜ繰り返されるか”もう少し深く見ると、心理的な背景が見えてきます。
| 心理 | 行動 | 結果 |
|---|---|---|
| 「ミスが怖い」 | 確認画面を追加する | 画面が増える |
| 「責任を取りたくない」 | 「確認しましたね?」の証拠を残す | 形骸化した確認 |
| 「前の設計を壊したくない」 | 既存に合わせて /confirm を追加 | パターンが増殖 |
| 「仕様書にそう書いてあるから」 | 疑問を持たずに実装 | 思考停止 |
こうした問題は、善意と恐怖から生まれます。
これを理解しないと、また同じ問題を生み出してしまいます。「なぜこの画面が必要なのか」を問い直すことが、改善の第一歩かもしれません。
その時点では合理的だった
Section titled “その時点では合理的だった”過去の設計を批判するつもりはありません。
当時の環境では、その設計が合理的だったことも多いです。
2010年頃の状況
Section titled “2010年頃の状況”- ブラウザの「戻る」ボタンでデータが消える
- セッションタイムアウトでやり直しになる
- 回線が不安定で途中で切れることがある
→ 確認画面でユーザーに最終確認させるのは合理的だった
2025年の状況
Section titled “2025年の状況”- SPA で状態管理が容易になった
- 自動保存が一般的になった
- 回線は安定している
→ 確認画面の必要性は薄れた
環境が変わったから、最適解も変わっただけです。今の視点で過去を批判するのではなく、「今ならどうするか」を考えることが大切です。
よくある思い込み
Section titled “よくある思い込み”画面が増える背景には、暗黙の思い込みがあることが多いです。
| 思い込み | 実際 |
|---|---|
| 1操作 = 1画面 | 一覧画面で追加・編集できる |
| 入力と表示は別画面 | 同じ画面で切り替えられる |
| 確認画面は必須 | 取り消し可能なら不要なことが多い |
| 登録と編集は別フロー | 同じフォームで対応できる |
これらは「そういうものだ」と思い込んでいるだけで、技術的な制約ではありません。
見分け方のヒント
Section titled “見分け方のヒント”よくある問題には、共通する特徴があります。
たとえば、こんな画面名を見かけたら、少し立ち止まってみてください:
- ユーザー登録画面
- ユーザー編集画面
- 確認画面
「登録」「編集」「確認」は**操作(動詞)**です。操作が画面名になっているとき、画面が増えやすい傾向があります。
| 操作が画面名だと… | 起きやすいこと |
|---|---|
| 登録画面 | 一覧と分離して、コンテキストが失われる |
| 編集画面 | 別画面に遷移して、戻る操作が必要になる |
| 確認画面 | 確定のタイミングが曖昧になる |
画面は「何を見ているか」で名付けると、シンプルになりやすいです。
詳しくは第2部で説明します。