コンテンツにスキップ

よくある問題

画面が増えすぎる問題は、悪意や怠慢から生まれるわけではありません。

むしろ、以下のようなよくある動機から生まれることが多いです:

動機結果
安全にしたい確認画面を増やす
分かりやすくしたい画面を分ける
整理したい登録と編集を別画面に
再利用したい汎用モーダルを作る

どれも理解できる動機です。ただ、整理の仕方によっては、かえって複雑になってしまうことがあります。

もう少し深く見ると、心理的な背景が見えてきます。

心理行動結果
「ミスが怖い」確認画面を追加する画面が増える
「責任を取りたくない」「確認しましたね?」の証拠を残す形骸化した確認
「前の設計を壊したくない」既存に合わせて /confirm を追加パターンが増殖
「仕様書にそう書いてあるから」疑問を持たずに実装思考停止

こうした問題は、善意と恐怖から生まれます。

これを理解しないと、また同じ問題を生み出してしまいます。「なぜこの画面が必要なのか」を問い直すことが、改善の第一歩かもしれません。

過去の設計を批判するつもりはありません。

当時の環境では、その設計が合理的だったことも多いです。

  • ブラウザの「戻る」ボタンでデータが消える
  • セッションタイムアウトでやり直しになる
  • 回線が不安定で途中で切れることがある

確認画面でユーザーに最終確認させるのは合理的だった

  • SPA で状態管理が容易になった
  • 自動保存が一般的になった
  • 回線は安定している

確認画面の必要性は薄れた

環境が変わったから、最適解も変わっただけです。今の視点で過去を批判するのではなく、「今ならどうするか」を考えることが大切です。

画面が増える背景には、暗黙の思い込みがあることが多いです。

思い込み実際
1操作 = 1画面一覧画面で追加・編集できる
入力と表示は別画面同じ画面で切り替えられる
確認画面は必須取り消し可能なら不要なことが多い
登録と編集は別フロー同じフォームで対応できる

これらは「そういうものだ」と思い込んでいるだけで、技術的な制約ではありません。


よくある問題には、共通する特徴があります。

たとえば、こんな画面名を見かけたら、少し立ち止まってみてください:

  • ユーザー登録画面
  • ユーザー編集画面
  • 確認画面

「登録」「編集」「確認」は**操作(動詞)**です。操作が画面名になっているとき、画面が増えやすい傾向があります。

操作が画面名だと…起きやすいこと
登録画面一覧と分離して、コンテキストが失われる
編集画面別画面に遷移して、戻る操作が必要になる
確認画面確定のタイミングが曖昧になる

画面は「何を見ているか」で名付けると、シンプルになりやすいです。

詳しくは第2部で説明します。