はじめに

このガイドについて

Webアプリの画面設計でよく見かけるパターンと、その改善の考え方をまとめたガイドです。

「入力画面 → 確認画面 → 完了画面」のような画面遷移。当たり前のように作られていますが、本当に必要でしょうか？

技術の問題でも、人の問題でもなく、整理の仕方によって、システムは使いやすくも使いにくくもなります。このガイドでは、そうした構造的な視点から画面設計を見直していきます。

想定読者

このガイドは、以下のような人を想定して書いています。

ペルソナ	状況	ゴール
開発者の山田さん（30歳）	レビューで「この画面遷移、複雑すぎない？」と指摘される	設計の根拠を説明できるようになりたい
設計者の佐藤さん（35歳）	毎回「入力 → 確認 → 完了」を作っているが、本当に必要か疑問	シンプルな設計パターンを身につけたい
改善担当の田中さん（40歳）	10年もののシステムが画面だらけで使いにくい	どこから手をつければいいか知りたい

「なぜこの画面が必要なのか」を問い直したい人に向けて書いています。

読み方

読者別ガイド

あなたが…	おすすめの読み方
開発者	第3部のケーススタディから。コード例は付録にあります
設計者	第2部の原則から。「なぜこの設計が良いか」の理論を押さえる
改善担当	第4部から。現状把握と提案の進め方を確認してから他を参照

通読する場合

第1部から順に読むと、考え方の背景から理解できます。

辞書的に使う場合

原則を知りたい → 第2部（設計の考え方）
具体例を見たい → 第3部（ケーススタディ）
改善を進めたい → 第4部（改善の進め方）
用語が分からない → 付録（用語集）

目的

画面設計でよくある問題を整理する
シンプルな設計の考え方を共有する
改善のヒントを提供する

「画面を減らす」ことが目的ではありません。必要な画面だけにすることが目的です。

対象システム

このガイドは、以下のようなシステムを想定しています：

認証（ログイン）がある
CRUD操作が中心
RDBを使用

顧客管理、注文管理、申請システム、管理画面など、データの登録・更新・削除が中心のWebアプリが対象です。

パブリック向けWebサイトや、リアルタイム通信が中心のシステムは想定していません。

視点

このガイドは画面（UI）を起点に考えています。

UIが複雑であれば、それを実現するコードはさらに複雑になります。UIをシンプルにすることは、コードをシンプルにする前提条件です。

なお、このガイドではソースコードの書き方には深く言及しません。実装パターンやアーキテクチャについては、各技術スタックのベストプラクティスを参照してください。

ただし、画面の課題はDB設計とも深く関わっていることが多いため、その関係にも触れていきます。「確認画面をなくす」には、DBの状態管理を見直す必要があるかもしれません。

全体構成

部	内容	読むと分かること
第1部	このガイドについて	背景と問題意識
第2部	画面とは何か + 7つの設計原則	画面を減らす考え方
第3部	ケーススタディ	典型パターンと再設計例
第4部	改善の進め方	現状把握から提案まで

基本的な考え方

このガイドでは、以下のような考え方を基本にしています：

よくある設計	このガイドの考え方	難易度
登録画面と編集画面を分ける	同じフォームで対応できる	★★☆
確認画面を挟む	取り消しできれば不要なことが多い	★★☆
入力と表示を別画面にする	同じ画面で切り替えられる	★★☆
ステップで順序を固定する	不足条件で示せばいい	★★★

難易度は変更範囲の目安です。★が多いほどDB設計の見直しが必要になります。詳しくは第4部「どこから始めるか」を参照してください。

画面を減らすことで、シンプルで使いやすい設計になる可能性があります。

注意事項

このガイドの原則は、すべてのケースに適用できるわけではありません。

法的要件がある場合（電子契約、金融取引など）
不可逆な操作の場合（外部システム連携、本番反映など）
バッチ処理の場合（CSVインポートなど）

例外については、第2部の「例外と関係」および付録「シンプルにできない領域」で詳しく説明しています。

このガイドの領域	OOUIの領域
画面構成の決め方	コントロールの選択
確認画面の要否	レイアウト・配置
状態管理・DB設計との関係	ラベリング
ルート設計	インタラクションの詳細
既存システムの改善方法	—