画面が増える背景

善意から生まれる

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

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

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

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

こうした背景を理解することが、改善の第一歩です。「なぜこの画面が必要なのか」を問い直すきっかけになります。

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

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

このような環境では、確認画面を設けるのは合理的でした。

こうした変化により、確認画面以外の選択肢（取り消し機能、インライン編集など）が現実的になりました。

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

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

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

このガイドの考え方を理解しているエンジニアがいない、あるいは**「言われた通りに実装する」だけの体制**が続くと、次のようなことが起きやすくなります。

状況	起こりやすいこと
設計を問い直す人がいない	仕様書や前例の通りに画面が増え、確認・完了画面が積み重なる
「依頼されたから作る」だけ	本当に必要か検討されず、ルートと画面が増え続ける
誰も根拠を説明できない	「昔からこう」になり、手を入れるほどリスクが高いと感じられ、改修されない

その結果、第4部の「ありがちな状態」に挙げたような症状（セッション地獄、ルートの乱立、DBの歪み、テストの困難さ）が蓄積していきます。使いにくさや保守コストの高さは、一気に悪化するのではなく、少しずつ積み重なることが多いです。

逆に、この考え方を共有しておくことで、「この画面、本当に必要か？」「確認画面でなく取り消しでは？」と問い直すきっかけが生まれます。必ずしも「設計ができるエンジニア」が多数である必要はなく、問いを立てられる人がいるだけでも、設計がずれていくのを防ぐ助けになります。

画面が増えやすい設計には、共通する特徴があります。

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

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

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

ここまで、画面が増える背景を見てきました。

第2部では、「画面とは何か」を定義した上で、画面構成をシンプルにするための7つの設計原則を紹介します。