画面とは何か

第2部では設計原則を紹介します。その前に、「画面とは何か」を考えておきましょう。

---

システムの全体像

業務システムには、多くのオブジェクト（もの・こと）が存在します。ユーザー、注文、商品、配送、権限…。これらは互いに関連し、複雑なネットワークを形成しています。

人間は、この全体を一度に把握できません。

---

画面 = システムの切り口

画面とは、システム全体から「人間が把握できる範囲」を切り出したものです。

ユーザーは、この「切り口」を通してシステムを操作します。

---

オブジェクトとは

顧客、注文、商品、請求書…。ユーザーが認識し操作する**対象（もの・こと）**を、オブジェクトと呼びます。

オブジェクトとは、ユーザーの関心や操作の対象となる「もの」や「こと」である。 — 上野学・藤井幸多「オブジェクト指向UIデザイン」

画面の対象になるのは、それ自体で意味を持ち、独立して扱えるものです。「注文」は独立して扱えますが、「注文明細」は注文の一部として扱うのが自然です。

---

一覧と詳細

切り口の基本は、2種類です。

• 一覧: 複数のオブジェクトを一望します。比較、選択、一括操作に向いています。
• 詳細: 1つのオブジェクトを深く見ます。関連するオブジェクトも一緒に表示します。

実際には「ダッシュボード」（複数の情報をまとめて表示）や「レポート」（分析結果を表示）など、バリエーションもあります。しかし、多くの業務画面は「一覧」と「詳細」の組み合わせで構成されています。

---

切り口から切り口へ

ユーザーは、システム全体の中から、見たい部分を次々と切り替えていきます。

• 一覧で選んで、詳細を開く
• 詳細から、関連するオブジェクトの詳細へ
• 詳細から、一覧に戻る
• 一覧を絞り込んだり、並び順を変えたりする

具体例

1. 注文一覧を開く（注文というオブジェクトの一覧）
2. 注文#002をクリック → 注文詳細に移動
3. 顧客名「田中太郎」をクリック → 顧客詳細に移動
4. ブラウザの戻るボタン、またはパンくずで一覧に戻る

URLで表すと: /orders → /orders/002 → /customers/123

この切り替えはスムーズでなければなりません。ユーザーが「今どこにいるのか」を見失わないように、切り口同士の関係は明確であるべきです。

「入力画面 → 確認画面 → 完了画面」のような一方通行の遷移は、この自由な行き来を制限してしまいます。

なぜ従来の設計が生まれたか

「入力→確認→完了」のフローは、間違いを防ぎたいという意図から生まれました。「本当に実行していいですか？」と確認することで、ユーザーのミスを防ごうとしたのです。

しかし現代では、操作を取り消せるようにすることで、同じ目的を達成できます。確認画面で止めるより、実行後に「元に戻す」方が、ユーザーにとって自然な流れになります。

---

操作は「その切り口」で行う

この考え方に立つと、操作（登録、編集、削除、承認…）はその切り口の中で行えばいいことが分かります。

操作	自然な場所
新規作成	一覧の中で（インライン追加）
編集	詳細の中で（インライン編集）
削除	一覧または詳細の中で

「登録画面」「編集画面」を別に作るのは、同じ切り口で見られるものを、わざわざ別の画面に切り出していることになります。

別画面が必要なケース

ただし、すべてを同じ画面で行うのが正解とは限りません。

• 処理に時間がかかる場合は、進捗を表示する画面が必要です
• 大量のデータを一括処理する場合は、別のフローが適切です

なお、入力項目が多い場合は、まず名前など最低限の情報だけで登録し、後から詳細画面で埋めていくアプローチも有効です。

原則を理解した上で、状況に応じて判断してください。

---

第2部の読み方

以降の原則は、この「画面 = システムの切り口」という考え方を前提にしています。

原則	切り口の視点で言うと
画面名は「何を見ているか」で名付ける	切り口には「何が見えるか」で名前をつける
登録はその場で行う	一覧という切り口の中で追加する
編集はその場で行う	詳細という切り口の中で編集する
確認画面は最低限にする	切り口を増やさず、取り消しで対処する
モードレスを優先する	どの切り口を見るかは、ユーザーが自由に決められる
状態と操作を分離する	オブジェクトの状態を、操作の副作用で変えない
ステップではなく不足条件で示す	切り口を順番に開かせるのではなく、何が足りないかを示す
見たいものを先に見せる	切り口は「方法」ではなく「見たいもの」で決める

この視点を持って、各原則を読み進めてください。