シリーズ: 要件定義とはそもそも何か
TRACERYプロダクトマネージャーの haru です。
画面は、ユーザーと製品やサービスをつなぐ重要な接点 です。
優れた画面は、ユーザーが迷うことなく操作できるよう設計されており、「使いやすい」と感じさせるユーザー体験を生み出します。
反対に、画面操作がわかりにくければ、どれほど高機能なシステムであっても、その価値に気づく前にユーザーが離れてしまいます。
そのため、画面はユーザーが継続的に使いたいと感じる体験を設計するうえで、極めて重要な役割を担っています 。
本記事では、システム開発における画面設計の進め方や、要件定義との関係について解説します。
メンタルモデルに沿った画面設計の重要性
メンタルモデル*1 とは、人がある物事や仕組みについて、「こうすればこうなる」と頭の中で思い描く理解の枠組みのこと です。
画面は、ユーザーのメンタルモデルと、画面の見え方や動作が一致していることが重要 です。
ユーザーが直感的に操作できたり、「思ったとおりに動いた」と感じられれば、迷わず使えて、学びやすく、ミスも起こりにくい画面になります。
一方で、メンタルモデルとのずれがあると、操作に戸惑い、不信感やストレスにつながりやすくなります 。
ユーザーのメンタルモデルと画面の挙動を一致させるには
どうすれば、システムにおいてユーザーのメンタルモデルと画面の挙動を一致させられるのでしょうか。
多くのユーザーは、システムを使うときに「この注文をキャンセルしたい」「この商品を登録したい」など、“どの対象に対して操作するか”を先に思い浮かべる傾向があります。
これは、認知心理学における「対象ベースの注意」の考え方*2 とも一致しており、人はまず行動対象に意識を向けたうえで、それに対する操作を決定するのが自然な思考プロセス とされています。
つまり、ユーザーの思考は次のような順序で組み立てられています。
対象の特定 ：操作の対象は何か（例：注文）操作する ：その対象に何をしたいか（例：キャンセル）
この「対象 → 操作」という順序が、ユーザーが持つメンタルモデルの核となる構造 です。この順序をそのまま画面に反映することが重要です。
ユーザーが思い浮かべたとおりの順序で操作できることで、迷いのない、自然な画面につながります。
クラス設計を元にした画面設計（オブジェクト指向UI）
「対象 → 操作」というユーザーのメンタルモデルを、画面設計に反映させるためのベースとして活用できるのが、オブジェクト指向のクラス設計です。
クラス設計については、要件定義とクラス設計 - TRACERY Lab.（トレラボ） を参照してください。
クラス設計を画面設計で利用する基本的な流れとしては、あるクラス（例：注文）を中心に据え、その属性情報（注文日、注文者情報、注文内容等）と操作（キャンセル等）を同一画面に配置します。
これにより、ユーザーは「注文に対して操作する」という自然な流れで画面を利用 できます。
クラス設計を画面設計で利用する
このように、クラス（オブジェクト）を起点に設計された画面を、オブジェクト指向UI と呼ばれます。
オブジェクト指向UIの着想は、1970年代に Xerox PARC（パロアルト研究所）で誕生した Smalltalk の GUI 環境に端を発し、オブジェクトを直接操作するという新しいユーザー体験を提示しました。
その後 Apple が 1980年代前半から Lisa／Macintosh で実用化し、IBM は 1990年代の OS/2 Workplace Shell でデスクトップ全体をオブジェクト化するなど各社が発展させ、現代UIの礎となりました。
オブジェクト指向UIの設計についてさらに知識を深めたい方は、以下の書籍を参照してください。
要件定義の成果物と画面設計の連携
機能要件、クラス設計から画面上の表示内容を設計する
画面設計では、要件定義で作成された開発品目一覧でリストアップされた画面（例：注文管理画面）を詳細化します。
以下は、注文管理画面の機能要件です。
開発品目
機能要件
注文管理画面
- 注文を検索し、リスト形式で表示できる
下図のように、画面機能要件の記述に含まれる名詞に着目し、その要件を実現するためのクラスを選定 します。
機能要件を実現するためのクラスを選定する
機能要件をどのように整理し定義するかについては、以下の記事で具体的な手順と考え方を解説しています。
ナビゲーションの設計
ユーザーが画面を操作する際の思考は、前述のとおり次の順序で進みます。
対象の特定 ：操作の対象は何か（例：注文）操作する ：その対象に何をしたいか（例：キャンセル）
画面設計では、この思考の流れを自然に誘導できる導線が重要です。
まず、ユーザーが操作対象を迷わず特定できるよう、導線（画面遷移・画面操作）を設計します。
多くの場合、この導線は「条件を指定する → 一覧を表示する → 一覧から対象を選択する」という流れが基本 です。このパターンは多くの画面設計に適用できます。
ナビゲーション設計
このように、操作対象をスムーズに特定できるように導く画面遷移や操作の流れを設計することを、ナビゲーション設計 と呼びます。
ナビゲーション設計は、ユーザーが迷うことなく目的の機能や情報にたどり着き、操作できるように導線を明確に整えるプロセス です。
ナビゲーションは、あたかも目的地までの道順を案内するカーナビのように、ユーザーの操作意図を先回りしてサポートする役割 を担います。
画面レイアウトの設計
ナビゲーション設計が完了したら、次は画面レイアウトの設計に進みます。
画面レイアウトとは、文字、画像、ボタンなどのUI要素を画面上で配置し、その配置によって操作のしやすさと視覚的な流れを生み出す構成 です。
画面レイアウトの設計では、次の4つの観点を考慮することが重要です。
観点
例
デバイス
PC、スマートフォン、タブレット、ゲーム機、スマートウォッチ、テレビなど
OS（オペレーティングシステム）
Windows、macOS、iOS、Android、Linuxなど
アプリケーションの実行形態
Webアプリ、スマートフォンのネイティブアプリ、デスクトップアプリなど
採用するフレームワーク
Single Page Application（SPA）、マルチページ構成など
これらは、画面の遷移構造、表示領域、操作方法、画面コンポーネントの選択 に直接影響します。
技術的な前提条件と利用環境を総合的に把握し、ユーザーの意図を自然に導くレイアウトを設計することで、使いやすく洗練された画面を実現 できます。
以下では、それぞれの観点について説明します。
デバイス
デバイスはユーザーの物理的な利用環境を規定します。
PC、スマートフォン、タブレット、ゲーム機、スマートウォッチ、テレビなど、画面サイズや入力手段（マウス、タッチ、リモコンなど）が異なるため、それぞれに適した情報の配置や操作導線が求められます。
OS（オペレーティングシステム）
OSは、標準的なUIのスタイルやユーザーの慣れに関わります。
Windows、macOS、iOS、Android、Linuxなど、プラットフォームごとに推奨されるUI設計や操作パターンがあります。
アプリケーションの実行形態
アプリケーションの実行形態は、Webアプリ、スマートフォンのネイティブアプリ、デスクトップアプリなどのことです。
形態によって使用できるUIコンポーネントやレスポンス速度、オフライン対応の可否が異なります。
採用するフレームワーク
近年では、採用するフロントエンドフレームワークも、画面設計に大きな影響を及ぼします。
たとえば、Single Page Application（SPA） では、画面遷移をURL単位で切り替えるのではなく、JavaScriptによって同一ページ内で動的にコンテンツを切り替えます。
この仕組みにより、ページ全体を再読み込みせずに必要な要素だけを差し替えることができ、モーダルやタブ、部分更新を活用したインタラクティブなUI設計が可能になります。
一方、従来のマルチページ構成（MPA：Multi Page Application、例：Django＋Djangoテンプレート）では、明確な画面遷移を前提とした設計となります。
最近はMPAとSPAの両方のメリットを兼ね備えたハイブリッド構成（例：Next.js、Nuxt.js）や、HTMXのような軽量フレームワークも登場しています。
このため、画面要件、保守性、開発のしやすさを考慮してフロントエンドフレームワークを選択し、これに合わせた画面設計を行う必要があります。
画面レイアウトの設計における要件定義との関係
デバイス、OS（オペレーティングシステム）、アプリケーションの実行形態、採用するフロントエンドフレームワークといった技術要素は、要件定義で作成されるシステム構成図 に明示されます。
システム構成図は、主に非機能要件を基盤として設計され、システムがどの環境で動作し、どのような技術的前提に基づくか を整理する役割を果たします。
画面設計もまた、非機能要件に強く依存しており、その品質や操作性を大きく左右します。
非機能要件と画面設計の関係については、後述します。
要件定義と画面レイアウト設計の関係
上図の例では、システム構成図で、以下の要素を指定しています(図内の赤線)。
技術観点
内容
デバイス
PC
OS
- macOS 15.x
ブラウザ
Chrome
SPAフレームワーク
Next.js 15.x
システム構成図の作成方法については、以下の記事で手順を解説していますので、参照してください。
レイアウトパターンの活用
レイアウト設計における4つの観点（デバイス、OS、アプリケーションの実行形態、採用するフレームワーク）の中で、デバイスは最も影響力の大きい要素 です。
なぜなら、デバイスごとに画面サイズや表示領域、操作方法が異なり、UIの構成やユーザー体験の設計方針が大きく変わる からです。
特にPCとモバイルでは、その差が明確です。
PCは広い画面を活かし、複数の情報を同時に表示して複雑な操作を提供できます。
一方、モバイルでは限られた表示領域の中で、情報を絞り込み、操作をシンプルに設計する必要があります。
このように、デバイス特性を理解し、それに応じた情報配置や操作導線を設計することが、使いやすく直感的な画面を実現する鍵 となります。
レイアウトパターンの参考書籍やガイドライン
画面レイアウトを設計する際は、既存のレイアウトパターンを参照することで設計の質とスピードを大きく高められます 。
これらのパターンは、画面サイズや操作特性に応じた情報配置や導線設計の成功事例を集約しており、一貫性のある設計を実現します。
適切なパターンを活用すれば、無駄な試行錯誤を減らし、短時間で高い完成度を備えたUIを構築できます。
以下では、レイアウトパターンを学ぶ上で参考となる書籍やデザインガイドラインを紹介します。
書籍
書籍は、3冊を紹介します。
オブジェクト指向UIデザイン──使いやすいソフトウェアの原理
オブジェクト指向UIデザイン（OOUI）の考え方と実践手順を、具体例を交えて体系的に解説しています。
以下で、レイアウトパターンを紹介しています。
『第3章 3-5 ステップ3. レイアウトパターンの適用』
モデルベースUIデザイン 構造化UIと情報設計の方法論
情報構造をモデル化し、それをもとにUIを段階的に設計していくプロセスを整理して解説しています。
以下で、レイアウトパターンを紹介しています。
6-3 デスクトップのためのインタラクションパターン
6-4 モバイルのためのインタラクションパターン
デザイニング・インターフェース 第2版 ―パターンによる実践的インタラクションデザイン
優れたUIを設計するための実践的なパターンを、豊富な事例とともに解説しています。
原著は2010年の出版ながら、現代のUIにも通用するパターンが数多く取り上げられています。
以下で、レイアウトパターンを紹介しています。
2〜9章 PC系のパターン
10章 モバイルへの対応
ガイドライン
ガイドラインは、Appleが提供する『Human Interface Guidelines 』とGoogleが提供する『Material Design 』が有名です。
Human Interface Guidelines（Apple）
Appleが提供するiOS、macOS、その他Appleプラットフォーム向けの公式ガイドラインです。タブバー、ナビゲーション、フォント、カラーなど、Apple製品に最適化されたUI設計指針を詳細に記載しています。
developer.apple.com
Material Design（Google）
Google が 2014 年に発表したデザイン言語（デザインシステム） で、WebやモバイルアプリなどのUIに統一性と操作性をもたらすことを目的としています。
物理世界の「紙（Material）」の特性 をメタファーとしており、影・奥行き・動きを利用して階層構造や操作可能性を直感的に伝えるのが特徴です。
Material Design は Android をはじめ、Google のサービス（Gmail、Google Drive など）や多数のWebアプリケーションで採用されています。
m3.material.io
非機能要件と画面設計の連携
非機能要件は下図に示す要素で構成されます。
画面設計では、これらの非機能要件のうち、利用品質 の有効性 、効率性 、満足性 、コンテキストカバレージ 、プロダクト品質 の性能効率 、互換性 、ユーザビリティ 、セキュリティ に着目します*3 。
これらの多くの特性が示す通り、画面設計は非機能要件を満たすことで初めて高品質なユーザー体験を実現します。
非機能要件の一覧
有効性
有効性*4 は、ユーザーや関係者が目標や成果を達成できる度合い です。
たとえば、オンラインショップでユーザーが目的の商品を検索し、正しくカートに追加して支払いまで完了できる場合、有効性が高いといえます。
設計観点
内容
操作対象の明確化
ユーザーが目的の機能や情報を迷わず見つけられるか
入力エラーの防止
入力フォームの設計やエラーメッセージの分かりやすさ
タスク完了までの誘導
適切な導線設計（ワークフロー）により、迷わず正しい手順を踏めるか
効率性
効率性*5 は、ユーザーが操作にかける時間や、システムが処理を行うために消費するCPU、メモリ、ネットワーク帯域といった資源に対して、どの程度の成果が得られるかを示す度合いです。
たとえば、オンラインショップで商品の購入手続きを行う場合、必要な情報が1画面に整理されており、住所や支払情報が自動で入力補完されると、ユーザーは短時間で購入を完了できます。
これにより、少ない操作と時間で目的が達成でき、効率性が高いといえます。
設計観点
内容
操作ステップの最小化
目標達成までに必要なクリック数や画面遷移を減らし、操作を簡潔にする
情報探索コストの削減
必要な情報を素早く見つけられるように配置やラベルを工夫する
入力負担の軽減
自動補完や選択リストを活用し、ユーザーの手入力や確認作業を最小限に抑える
満足性
満足性*6 は、使用体験や心理的影響を含む利用者の幸福感や受容性の度合いのことです。「有用性」「信頼性」など4つのサブ特性*7 に分類されています。概要を次の表に示します。
サブ特性
内容
有用性（Usefulness）
システムがユーザーのニーズや期待にどの程度応えるか
信頼性（Trust）
システムの動作や結果に対してユーザーがどれだけ信頼できると感じるか
楽しさ（Pleasure）
システムの使用が心理的に心地よく、ポジティブな体験をもたらすか
快適さ（Comfort）
物理的・精神的負担が少なく、安心して利用できるか
以下の表は、満足性のサブ特性を画面設計に落とし込む際の具体策をまとめたものです。
サブ特性
画面設計での具体例
有用性（Usefulness）
- 購入履歴からワンクリックで再注文できるショートカットを配置
信頼性（Trust）
- 常時SSL対応を明示し、セキュアな接続であることを表示（例：鍵アイコン）
楽しさ（Pleasure）
- 商品画像を拡大表示でき、360度ビューや動画で楽しめる体験を提供
快適さ（Comfort）
- 長時間閲覧しても疲れにくい落ち着いた配色や適切な文字サイズを採用
コンテキストカバレージ
コンテキストカバレージ*8 は、システムが想定される使用環境（コンテキスト）において適切に動作し、ユーザーが目標を達成できる範囲を表します。
ここでいう「コンテキスト」とは、ユーザーのスキル、使用するデバイス、ネットワーク環境、業務状況など、システム利用時のさまざまな条件を含みます。
「コンテキスト完全性」「柔軟性」など2つのサブ特性に分類されています。概要を次の表に示します。
サブ特性
内容
コンテキスト完全性（Context Completeness）
想定されたすべての利用条件や環境において、必要な性能や動作を提供できる度合い
柔軟性（Flexibility）
新しい利用環境や予期しない条件にも適応し、ユーザーが目標を達成できる度合い
以下の表は、コンテキストカバレージのサブ特性を画面設計に落とし込む際の具体策をまとめたものです。
サブ特性
画面設計での具体例
コンテキスト完全性（Context Completeness）
- PC、スマートフォン、タブレットなど異なるデバイスに対応するレスポンシブデザインを採用
柔軟性（Flexibility）
- 新しい支払方法（例：QRコード決済）の追加に対応できるUI構造を採用
性能効率
性能効率*9 は 、指定された条件下でシステムが必要な性能をどれだけ効率的に提供できるかを表します。
「時間効率性」「資源使用効率性」「容量」など3つのサブ特性に分類されています。概要を次の表に示します。
サブ特性
設計観点
時間効率性（Time Behaviour）
指定された条件下での応答時間、処理時間、スループットなど、システムやコンポーネントの応答が、性能要求やユーザーの期待に対して適切か
資源使用効率性（Resource Utilization）
指定された条件下で、システムやコンポーネントがどれだけ効率的にハードウェアやソフトウェアの資源（CPU、メモリ、ネットワークなど）を利用するか
容量（Capacity）
システムが、パフォーマンスを保ちながら処理できる最大ユーザー数、データ量、トランザクション数などの上限が要求を満たしているか、または想定された負荷に耐えられるか
以下の表は、性能効率のサブ特性を画面設計に落とし込む際の具体策をまとめたものです。
サブ特性
画面設計での具体例
時間効率性（Time Behaviour）
- 一覧画面はページングまたは無限スクロールで分割表示
資源使用効率性（Resource Utilization）
- 表示に不要な画像・動画の遅延読み込み（Lazy Load）
容量（Capacity）
- 初期表示では最新10件だけ表示、ユーザー操作でさらに表示
互換性
互換性*10 は、システムやソフトウェアが他の製品、コンポーネント、または環境と競合せずに共存し、相互に情報を交換・活用できる度合いを示します。異なるシステム間でのスムーズな動作やデータ連携を保証することが目的です。
互換性は、「共存性」「相互運用性」など2つのサブ特性に分類されています。概要を下表に示します。
サブ特性
設計観点
共存性（Co-existence）
他のシステムやアプリケーションと同じ環境（OS、ネットワーク、デバイス）上で動作する際に、競合を起こさず正常に機能できるか
相互運用性（Interoperability）
他のシステム、製品、コンポーネントと情報を交換し、相互に利用できる度合い。データ形式や通信プロトコルの互換性、APIの標準準拠が適切か
以下の表は、互換性のサブ特性を画面設計に落とし込む際の具体策をまとめたものです。
サブ特性
画面設計での具体例
共存性（Co-existence）
- 画面に組み込んだ外部サービス（広告・チャットウィジェットなど）が動作してもUIが崩れない設計
相互運用性（Interoperability）
- 外部サービスとの連携（例：SNSログイン、外部決済）に対応するため、統一されたUIで権限確認ダイアログを表示
ユーザビリティ
ユーザビリティ*11 は、使いやすさ・理解しやすさ・安全性・アクセスしやすさを包括的に評価する特性です。
システム開発においては、UI/UX設計の品質を直接的に測る重要な指標となります。
「適切度認識性」「学習容易性」「運用容易性」「ユーザーエラー防止性」など8つのサブ特性に分類されています。概要を次の表に示します。
サブ特性
設計観点
適切度認識性（Appropriateness Recognizability）
機能やコンテンツの意味・目的がユーザーにとって直感的にわかるか
学習容易性（Learnability）
初めて使うユーザーでもすぐに操作方法を理解できるか
運用容易性（Operability）
操作や制御が簡単に行えるか、操作負荷が少ないか
ユーザーエラー防止性（User Error Protection）
ユーザーの誤操作を未然に防ぎ、発生時にも適切に対応できるか
ユーザー関与性（User Engagement）
ユーザーが積極的に操作したくなるような工夫があるか
包括性（Inclusivity）
多様なユーザー（年齢、障がいなど）でも使いやすい設計か
ユーザー支援（User Assistance）
操作時に適切な支援が受けられるか
自己記述性（Self-Descriptiveness）
今なにをすべきか、次に何が起こるのかが自然とわかるか
以下の表は、ユーザビリティのサブ特性を画面設計に落とし込む際の具体策をまとめたものです。
サブ特性
画面設計での具体例
適切度認識性（Appropriateness Recognizability）
- ボタンに「保存」「削除」など具体的な動詞を使う
学習容易性（Learnability）
- 初回ログイン時のガイドツアー表示
運用容易性（Operability）
- キーボード操作やショートカットのサポート
ユーザーエラー防止性（User Error Protection）
- 削除操作には確認ダイアログを表示
ユーザー関与性（User Engagement）
- ステップ表示で進捗を可視化（例：申請手続きのフロー）
包括性（Inclusivity）
- カラーユニバーサルデザイン（CUD）対応
ユーザー支援（User Assistance）
- 入力欄にヒントや例（プレースホルダーやラベル）
自己記述性（Self-Descriptiveness）
- 現在のステータス表示（例：「下書き中」「承認待ち」）
セキュリティ
セキュリティ*12 は、「機密性」「完全性」「否認防止」「責任追跡性」「真正性」など5つのサブ特性に分類されています。概要を次の表に示します。
サブ特性
設計観点
機密性（Confidentiality）
権限を持つユーザーのみが情報にアクセスできるように制御し、データが不正に閲覧・漏洩されないことを保証するか
完全性（Integrity）
情報や処理が不正に改ざんされないように保護し、正確で一貫性のある状態を維持できるか
否認防止（Non-repudiation）
ユーザーまたはシステムが実行した行為について、後から否認できないよう証拠を保持し、責任を明確にできるか
責任追跡性（Accountability）
ユーザーやシステムの操作を特定の主体に関連付けられるよう記録し、必要に応じて追跡できるか
真正性（Authenticity）
ユーザー、デバイス、システム、通信が真正であることを確認し、なりすましを防止できるか
以下の表は、セキュリティのサブ特性を画面設計に落とし込む際の具体策をまとめたものです。
サブ特性
画面設計での具体例
機密性（Confidentiality）
- ログイン画面でパスワードをマスク表示し、表示切替ボタンを設置
完全性（Integrity）
- 重要な入力フォームでは送信前に確認画面を表示
否認防止（Non-repudiation）
- 注文完了時に電子署名付きの確認メールを送付
責任追跡性（Accountability）
- 管理画面でユーザーごとの操作ログを閲覧可能にする
真正性（Authenticity）
- ログイン時に多要素認証（MFA）を導入
まとめ
本記事では、システム開発における画面設計の重要性と、要件定義との連携について解説しました。
下図に、要件定義の成果物と画面設計の関係をまとめました。
要件定義の成果物と画面設計の関係
画面はユーザーとシステムをつなぐ重要な接点であり、優れた設計は直感的で迷いのない操作体験を提供します。その基盤となるのが、ユーザーのメンタルモデル を反映したUI設計です。特に「対象 → 操作」という自然な思考順序を画面構成に取り入れることで、使いやすさが向上します。
ユーザーのメンタルモデルを反映するために、オブジェクト指向UI を活用することで、クラス設計と画面構成を結び付け、情報と操作を一貫性のある形で提供できます。
加えて、ナビゲーション設計や画面レイアウト設計では、デバイス・OS・フレームワークなどの技術的前提を踏まえた導線設計が不可欠です。
画面設計は非機能要件 とも密接に関係し、有効性・効率性・満足性・ユーザビリティ・互換性・性能効率・セキュリティなどの品質特性を満たすことが求められます。
ユーザーの思考に沿った自然な操作性を備え、非機能要件を満たすよう技術的制約を踏まえて設計された画面は、業務効率を高め、ユーザー体験を向上させる と同時に、システムの信頼性と持続的な価値 を確実に支えます。
次の記事 では、要件定義とAPI設計の関係について説明します。
tracery.jp
この記事を書いた人
佐藤治夫。株式会社ビープラウド代表取締役社長。TRACERYのプロダクトマネージャー。エンジニアとして活動を始めて以来、モデリングを中心としたソフトウェアエンジニアリングを実践している。Xアカウント: https://x.com/haru860
![[改訂第2版] [入門+実践]要求を仕様化する技術・表現する技術 -仕様が書けていますか?](https://m.media-amazon.com/images/I/51hV6os4M5L._SL500_.jpg "[改訂第2版] [入門+実践]要求を仕様化する技術・表現する技術 -仕様が書けていますか?")
