はじめに
このガイドについて
Section titled “このガイドについて”Webアプリの画面設計でよく見かけるパターンと、その改善の考え方をまとめたガイドです。
このガイドでいう「画面設計」は、1画面内のレイアウトではなく、画面の分け方と遷移の設計を指します。
「入力画面 → 確認画面 → 完了画面」のような画面遷移は、多くのシステムで当たり前のように作られています。しかし、すべてのケースで本当に必要でしょうか？
このガイドでは、画面の分け方・まとめ方という視点から画面設計を見直していきます。画面構成を整理することで、ユーザーにとって使いやすく、開発者にとって保守しやすいシステムを目指します。
このガイドの立ち位置
Section titled “このガイドの立ち位置”このガイドは、画面を「切り口」として捉え、確認画面などのUIの都合で工程が増えることに注意を向けます。近い視点としては、OOUI（画面はオブジェクトの切り口）、DDD のアプリケーションサービス、CQRS の Task-based UI などがあります。とはいえ、本ガイドはそこから「画面構成とルート設計」に絞って扱います。
このガイドは、以下のような人を想定して書いています。
| 役割 | 状況 | ゴール |
|---|---|---|
| 開発者 | レビューで「この画面遷移、複雑すぎない？」と指摘される | 設計の根拠を説明できるようになりたい |
| 設計者 | 毎回「入力 → 確認 → 完了」を作っているが、本当に必要か疑問 | シンプルな設計パターンを身につけたい |
| 改善担当 | 長年運用されてきたシステムが画面だらけで使いにくい | どこから手をつければいいか知りたい |
「なぜこの画面が必要なのか」を問い直したい人に向けて書いています。
読者別ガイド
Section titled “読者別ガイド”| あなたが… | おすすめの読み方 |
|---|---|
| 開発者 | 第3部のケーススタディから。コード例は付録にあります |
| 設計者 | 第2部の原則から。「なぜこの設計が良いか」の理論を押さえる |
| 改善担当 | 第4部から。現状把握と提案の進め方を確認してから他を参照 |
通読する場合
Section titled “通読する場合”第1部から順に読むと、考え方の背景から理解できます。
辞書的に使う場合
Section titled “辞書的に使う場合”- 原則を知りたい → 第2部（設計の考え方）
- 具体例を見たい → 第3部（ケーススタディ）
- 改善を進めたい → 第4部（改善の進め方）
- 用語が分からない → 付録（用語集）
- 画面設計でよくある問題を整理する
- シンプルな設計の考え方を共有する
- 改善のヒントを提供する
「画面を減らす」こと自体が目的ではありません。必要な画面だけにすることが目的です。
対象システム
Section titled “対象システム”このガイドは、以下のようなシステムを想定しています：
- 認証（ログイン）がある
- CRUD 操作が中心
- RDB を使用
顧客管理、注文管理、申請システム、管理画面など、データの登録・更新・削除が中心のWebアプリが対象です。
一般向けWebサイトや、リアルタイム通信が中心のシステムは想定していません。
このガイドは画面（UI）を起点に考えています。
UIが複雑であれば、それを実現するコードも複雑になりがちです。UIをシンプルにすることで、コードもシンプルになる余地が生まれます。 その結果、ソースコードやDB 設計を複雑にせず、保守工数やテスト工数を下げ、品質を上げることにもつながります。
なお、このガイドではソースコードの書き方には深く言及しません。実装パターンやアーキテクチャについては、各技術スタックのベストプラクティスを参照してください。
ただし、画面の課題はDB 設計とも深く関わっていることが多いため、その関係にも触れていきます。「確認画面をなくす」には、DBの状態管理を見直す必要があるかもしれません。
| 部 | 内容 | 読むと分かること |
|---|---|---|
| 第1部 | このガイドについて | 背景と問題意識 |
| 第2部 | 画面とは何か + 7つの設計原則 | 画面を減らす考え方 |
| 第3部 | ケーススタディ | 典型パターンと再設計例 |
| 第4部 | 改善の進め方 | 現状把握から提案まで |
基本的な考え方
Section titled “基本的な考え方”このガイドでは、以下のような考え方を基本にしています：
| よくある設計 | このガイドの考え方 | 難易度 |
|---|---|---|
| 登録画面と編集画面を分ける | 同じフォームで対応できる | ★★☆ |
| 確認画面を挟む | 取り消しできれば不要なことが多い | ★★☆ |
| 入力と表示を別画面にする | 同じ画面で切り替えられる | ★★☆ |
| ステップで順序を固定する | 不足条件で示すほうが意図が明確 | ★★★ |
難易度は変更範囲の目安です。★が多いほどDB 設計の見直しが必要になります。詳しくは第4部「どこから始めるか」を参照してください。
画面構成を見直すことで、シンプルで使いやすい設計になることが多いです。
このガイドの原則は、すべてのケースに適用できるわけではありません。
- 法的要件がある場合（電子契約、金融取引など）
- 不可逆な操作の場合（外部システム連携、本番反映など）
- バッチ処理の場合（CSVインポートなど）
例外については、第2部の「例外と関係」および付録「シンプルにできない領域」で詳しく説明しています。
各画面内のUI設計（コントロールの選択、レイアウト、配置など）については、以下を参照してください：
- オブジェクト指向UIデザイン（上野学・藤井幸多 著、技術評論社）
- ソシオメディア ヒューマンインターフェース ガイドライン https://www.sociomedia.co.jp/category/shig
本ガイドで「一覧」「詳細」に画面を整理した後、各画面内の詳細設計はOOUIの原則を参考にすることを推奨します。
その他の関連文献は、付録の「関連するガイド・文献」を参照してください。