シリーズ: 要件定義とはそもそも何か
- 要件定義の目的とゴールとは
- 要件定義の重要ポイント〜要望・要求・要件を見極める
- 事業・業務・システムの3階層で要件を捉える
- 業務フロー図で見える化する業務プロセスからシステム要件への道筋
- ユースケースとロバストネス図によるシステム要件定義
- システム要件定義の成果物〜設計へのインプットを作成する
- 要件定義とソフトウェアアーキテクチャ設計
- 要件定義とクラス設計
- 要件定義とデータベース設計
- 要件定義と画面設計（本記事）
- 要件定義とAPI設計
- 要件定義とバッチ処理設計
- 要件とは何か
- 非機能要件とは何か
- 要件定義を学ぶ人におすすめの書籍まとめ
- 移行要件とは何か
- 要件定義のプロセスと成果物を体系的に理解する【全体像まとめ】
- 要件定義と設計の関係を体系的に理解する【全体像まとめ】
TRACERYプロダクトマネージャーの haru です。
画面は、ユーザーと製品やサービスをつなぐ重要な接点です。
優れた画面は、ユーザーが迷うことなく操作できるよう設計されており、「使いやすい」と感じさせるユーザー体験を生み出します。
反対に、画面操作がわかりにくければ、どれほど高機能なシステムであっても、その価値に気づく前にユーザーが離れてしまいます。
そのため、画面はユーザーが継続的に使いたいと感じる体験を設計するうえで、極めて重要な役割を担っています。
本記事では、システム開発における画面設計の進め方や、要件定義との関係について解説します。
- メンタルモデルに沿った画面設計の重要性
- ユーザーのメンタルモデルと画面の挙動を一致させるには
- クラス設計を元にした画面設計（オブジェクト指向UI）
- 要件定義の成果物と画面設計の連携
- まとめ
メンタルモデルに沿った画面設計の重要性
メンタルモデル*1とは、人がある物事や仕組みについて、「こうすればこうなる」と頭の中で思い描く理解の枠組みのことです。
画面は、ユーザーのメンタルモデルと、画面の見え方や動作が一致していることが重要です。
ユーザーが直感的に操作できたり、「思ったとおりに動いた」と感じられれば、迷わず使えて、学びやすく、ミスも起こりにくい画面になります。
一方で、メンタルモデルとのずれがあると、操作に戸惑い、不信感やストレスにつながりやすくなります。
ユーザーのメンタルモデルと画面の挙動を一致させるには
どうすれば、システムにおいてユーザーのメンタルモデルと画面の挙動を一致させられるのでしょうか。
多くのユーザーは、システムを使うときに「この注文をキャンセルしたい」「この商品を登録したい」など、“どの対象に対して操作するか”を先に思い浮かべる傾向があります。
これは、認知心理学における「対象ベースの注意」の考え方*2とも一致しており、人はまず行動対象に意識を向けたうえで、それに対する操作を決定するのが自然な思考プロセスとされています。
つまり、ユーザーの思考は次のような順序で組み立てられています。
- 対象の特定：操作の対象は何か（例：注文）
- 操作する：その対象に何をしたいか（例：キャンセル）
この「対象 → 操作」という順序が、ユーザーが持つメンタルモデルの核となる構造です。この順序をそのまま画面に反映することが重要です。
ユーザーが思い浮かべたとおりの順序で操作できることで、迷いのない、自然な画面につながります。
クラス設計を元にした画面設計（オブジェクト指向UI）
「対象 → 操作」というユーザーのメンタルモデルを、画面設計に反映させるためのベースとして活用できるのが、オブジェクト指向のクラス設計です。
クラス設計については、要件定義とクラス設計 - TRACERY Lab.（トレラボ）を参照してください。
クラス設計を画面設計で利用する基本的な流れとしては、あるクラス（例：注文）を中心に据え、その属性情報（注文日、注文者情報、注文内容等）と操作（キャンセル等）を同一画面に配置します。
これにより、ユーザーは「注文に対して操作する」という自然な流れで画面を利用できます。
このように、クラス（オブジェクト）を起点に設計された画面を、オブジェクト指向UIと呼ばれます。
オブジェクト指向UIの着想は、1970年代に Xerox PARC（パロアルト研究所）で誕生した Smalltalk の GUI 環境に端を発し、オブジェクトを直接操作するという新しいユーザー体験を提示しました。
その後 Apple が 1980年代前半から Lisa／Macintosh で実用化し、IBM は 1990年代の OS/2 Workplace Shell でデスクトップ全体をオブジェクト化するなど各社が発展させ、現代UIの礎となりました。
オブジェクト指向UIの設計についてさらに知識を深めたい方は、以下の書籍を参照してください。
要件定義の成果物と画面設計の連携
機能要件、クラス設計から画面上の表示内容を設計する
画面設計では、要件定義で作成された開発品目一覧でリストアップされた画面（例：注文管理画面）を詳細化します。
以下は、注文管理画面の機能要件です。
| 開発品目 | 機能要件 |
|---|---|
| 注文管理画面 | - 注文を検索し、リスト形式で表示できる - 顧客名、メールアドレス、注文ID、商品ID、注文ステータスで検索できる - 注文内容の詳細を表示できる。購入した商品名、数量、単価など、顧客情報（名前・メールアドレス、配送先住所） - 注文ステータスを更新できる（例：処理中 → 出荷済） - 注文のキャンセル処理ができる（キャンセル理由記録含む） |
下図のように、画面機能要件の記述に含まれる名詞に着目し、その要件を実現するためのクラスを選定します。
機能要件をどのように整理し定義するかについては、以下の記事で具体的な手順と考え方を解説しています。
ナビゲーションの設計
ユーザーが画面を操作する際の思考は、前述のとおり次の順序で進みます。
- 対象の特定：操作の対象は何か（例：注文）
- 操作する：その対象に何をしたいか（例：キャンセル）
画面設計では、この思考の流れを自然に誘導できる導線が重要です。
まず、ユーザーが操作対象を迷わず特定できるよう、導線（画面遷移・画面操作）を設計します。
多くの場合、この導線は「条件を指定する → 一覧を表示する → 一覧から対象を選択する」という流れが基本です。このパターンは多くの画面設計に適用できます。
このように、操作対象をスムーズに特定できるように導く画面遷移や操作の流れを設計することを、ナビゲーション設計と呼びます。
ナビゲーション設計は、ユーザーが迷うことなく目的の機能や情報にたどり着き、操作できるように導線を明確に整えるプロセスです。
ナビゲーションは、あたかも目的地までの道順を案内するカーナビのように、ユーザーの操作意図を先回りしてサポートする役割を担います。
画面レイアウトの設計
ナビゲーション設計が完了したら、次は画面レイアウトの設計に進みます。
画面レイアウトとは、文字、画像、ボタンなどの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 - Windows11 |
| ブラウザ | 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設計指針を詳細に記載しています。
Material Design（Google）
Google が 2014 年に発表したデザイン言語（デザインシステム）で、WebやモバイルアプリなどのUIに統一性と操作性をもたらすことを目的としています。
物理世界の「紙（Material）」の特性をメタファーとしており、影・奥行き・動きを利用して階層構造や操作可能性を直感的に伝えるのが特徴です。
Material Design は Android をはじめ、Google のサービス（Gmail、Google Drive など）や多数のWebアプリケーションで採用されています。
非機能要件と画面設計の連携
非機能要件は下図に示す要素で構成されます。
画面設計では、これらの非機能要件のうち、利用品質の有効性、効率性、満足性、コンテキストカバレージ、プロダクト品質の性能効率、互換性、ユーザビリティ、セキュリティ に着目します*3。
これらの多くの特性が示す通り、画面設計は非機能要件を満たすことで初めて高品質なユーザー体験を実現します。
有効性
有効性*4は、ユーザーや関係者が目標や成果を達成できる度合いです。
たとえば、オンラインショップでユーザーが目的の商品を検索し、正しくカートに追加して支払いまで完了できる場合、有効性が高いといえます。
| 設計観点 | 内容 |
|---|---|
| 操作対象の明確化 | ユーザーが目的の機能や情報を迷わず見つけられるか |
| 入力エラーの防止 | 入力フォームの設計やエラーメッセージの分かりやすさ |
| タスク完了までの誘導 | 適切な導線設計（ワークフロー）により、迷わず正しい手順を踏めるか |
効率性
効率性*5は、ユーザーが操作にかける時間や、システムが処理を行うために消費するCPU、メモリ、ネットワーク帯域といった資源に対して、どの程度の成果が得られるかを示す度合いです。
たとえば、オンラインショップで商品の購入手続きを行う場合、必要な情報が1画面に整理されており、住所や支払情報が自動で入力補完されると、ユーザーは短時間で購入を完了できます。
これにより、少ない操作と時間で目的が達成でき、効率性が高いといえます。
| 設計観点 | 内容 |
|---|---|
| 操作ステップの最小化 | 目標達成までに必要なクリック数や画面遷移を減らし、操作を簡潔にする |
| 情報探索コストの削減 | 必要な情報を素早く見つけられるように配置やラベルを工夫する |
| 入力負担の軽減 | 自動補完や選択リストを活用し、ユーザーの手入力や確認作業を最小限に抑える |
満足性
満足性*6は、使用体験や心理的影響を含む利用者の幸福感や受容性の度合いのことです。「有用性」「信頼性」など4つのサブ特性*7に分類されています。概要を次の表に示します。
| サブ特性 | 内容 |
|---|---|
| 有用性（Usefulness） | システムがユーザーのニーズや期待にどの程度応えるか |
| 信頼性（Trust） | システムの動作や結果に対してユーザーがどれだけ信頼できると感じるか |
| 楽しさ（Pleasure） | システムの使用が心理的に心地よく、ポジティブな体験をもたらすか |
| 快適さ（Comfort） | 物理的・精神的負担が少なく、安心して利用できるか |
以下の表は、満足性のサブ特性を画面設計に落とし込む際の具体策をまとめたものです。
| サブ特性 | 画面設計での具体例 |
|---|---|
| 有用性（Usefulness） | - 購入履歴からワンクリックで再注文できるショートカットを配置 - ユーザーが求める商品を素早く見つけられるよう、検索結果にフィルターや並び替え機能を提供 - レコメンド機能で関連商品を提示し、ユーザーのニーズを先回りして提案 - 配送状況をリアルタイムで確認できるトラッキング画面を提供 |
| 信頼性（Trust） | - 常時SSL対応を明示し、セキュアな接続であることを表示（例：鍵アイコン） - 返品・返金ポリシーをわかりやすく表示し、ユーザーに安心感を与える - レビューや評価を偽装なく表示し、信頼性を担保 - 決済画面で信頼できる決済事業者のロゴや認証マークを表示 |
| 楽しさ（Pleasure） | - 商品画像を拡大表示でき、360度ビューや動画で楽しめる体験を提供 - セールやキャンペーン時に視覚的にワクワク感を演出するアニメーションやアイコンを使用 - 購入完了画面で「ありがとう」メッセージや次回クーポンを表示して購買体験を向上 |
| 快適さ（Comfort） | - 長時間閲覧しても疲れにくい落ち着いた配色や適切な文字サイズを採用 - ローディング中は進捗バーやメッセージを表示し、不安感を与えない - 入力フォームはエラー時に具体的な改善ヒントを表示し、ユーザーが安心して修正できる - モバイル利用時に片手操作でも快適に操作できるUI配置を採用 |
コンテキストカバレージ
コンテキストカバレージ*8は、システムが想定される使用環境（コンテキスト）において適切に動作し、ユーザーが目標を達成できる範囲を表します。
ここでいう「コンテキスト」とは、ユーザーのスキル、使用するデバイス、ネットワーク環境、業務状況など、システム利用時のさまざまな条件を含みます。
「コンテキスト完全性」「柔軟性」など2つのサブ特性に分類されています。概要を次の表に示します。
| サブ特性 | 内容 |
|---|---|
| コンテキスト完全性（Context Completeness） | 想定されたすべての利用条件や環境において、必要な性能や動作を提供できる度合い |
| 柔軟性（Flexibility） | 新しい利用環境や予期しない条件にも適応し、ユーザーが目標を達成できる度合い |
以下の表は、コンテキストカバレージのサブ特性を画面設計に落とし込む際の具体策をまとめたものです。
| サブ特性 | 画面設計での具体例 |
|---|---|
| コンテキスト完全性（Context Completeness） | - PC、スマートフォン、タブレットなど異なるデバイスに対応するレスポンシブデザインを採用 - 高齢者や視覚障害者向けに文字サイズ変更やコントラスト調整機能を提供 - オフライン環境でも閲覧できるキャッシュ機能を導入し、一部機能を制限付きで利用可能にする |
| 柔軟性（Flexibility） | - 新しい支払方法（例：QRコード決済）の追加に対応できるUI構造を採用 - キャンペーンやセールに応じてバナーやメニューを動的に差し替え可能な設計 - 画面要素をコンポーネント化し、デザイン変更や機能拡張が容易な構成にする - 想定外のエラーやネットワーク断に対しても、再試行や案内メッセージを表示してユーザーが続行できるようにする |
性能効率
性能効率*9は 、指定された条件下でシステムが必要な性能をどれだけ効率的に提供できるかを表します。
「時間効率性」「資源使用効率性」「容量」など3つのサブ特性に分類されています。概要を次の表に示します。
| サブ特性 | 設計観点 |
|---|---|
| 時間効率性（Time Behaviour） | 指定された条件下での応答時間、処理時間、スループットなど、システムやコンポーネントの応答が、性能要求やユーザーの期待に対して適切か |
| 資源使用効率性（Resource Utilization） | 指定された条件下で、システムやコンポーネントがどれだけ効率的にハードウェアやソフトウェアの資源（CPU、メモリ、ネットワークなど）を利用するか |
| 容量（Capacity） | システムが、パフォーマンスを保ちながら処理できる最大ユーザー数、データ量、トランザクション数などの上限が要求を満たしているか、または想定された負荷に耐えられるか |
以下の表は、性能効率のサブ特性を画面設計に落とし込む際の具体策をまとめたものです。
| サブ特性 | 画面設計での具体例 |
|---|---|
| 時間効率性（Time Behaviour） | - 一覧画面はページングまたは無限スクロールで分割表示 - ボタン押下から処理完了までを2秒以内に収める - 重い処理は非同期で実行し、完了通知を出す |
| 資源使用効率性（Resource Utilization） | - 表示に不要な画像・動画の遅延読み込み（Lazy Load） - 高頻度で利用されるデータをローカルストレージにキャッシュ - 画像やフォントは軽量形式（WebP, WOFF2など）を使用 |
| 容量（Capacity） | - 初期表示では最新10件だけ表示、ユーザー操作でさらに表示 - 検索条件の入力を必須にし、全件表示を避ける - 「全選択」や「一括操作」は件数制限を設ける（例：最大100件） - データ量に応じて警告や注意書きを表示（例：「1万件以上のデータがあります」） |
互換性
互換性*10は、システムやソフトウェアが他の製品、コンポーネント、または環境と競合せずに共存し、相互に情報を交換・活用できる度合いを示します。異なるシステム間でのスムーズな動作やデータ連携を保証することが目的です。
互換性は、「共存性」「相互運用性」など2つのサブ特性に分類されています。概要を下表に示します。
| サブ特性 | 設計観点 |
|---|---|
| 共存性（Co-existence） | 他のシステムやアプリケーションと同じ環境（OS、ネットワーク、デバイス）上で動作する際に、競合を起こさず正常に機能できるか |
| 相互運用性（Interoperability） | 他のシステム、製品、コンポーネントと情報を交換し、相互に利用できる度合い。データ形式や通信プロトコルの互換性、APIの標準準拠が適切か |
以下の表は、互換性のサブ特性を画面設計に落とし込む際の具体策をまとめたものです。
| サブ特性 | 画面設計での具体例 |
|---|---|
| 共存性（Co-existence） | - 画面に組み込んだ外部サービス（広告・チャットウィジェットなど）が動作してもUIが崩れない設計 - ブラウザの拡張機能（例：翻訳ツール、広告ブロッカー）が動作しても重要なUIが欠けない設計 - 他アプリとの同時利用を想定し、ポップアップや通知の重なりを避ける |
| 相互運用性（Interoperability） | - 外部サービスとの連携（例：SNSログイン、外部決済）に対応するため、統一されたUIで権限確認ダイアログを表示 - データのインポート／エクスポート画面で、標準フォーマット（CSV、JSONなど）を選択できる機能を提供 - 連携APIの結果やエラーをユーザーにわかりやすくフィードバックし、必要な操作案内を表示 |
ユーザビリティ
ユーザビリティ*11は、使いやすさ・理解しやすさ・安全性・アクセスしやすさを包括的に評価する特性です。
システム開発においては、UI/UX設計の品質を直接的に測る重要な指標となります。
「適切度認識性」「学習容易性」「運用容易性」「ユーザーエラー防止性」など8つのサブ特性に分類されています。概要を次の表に示します。
| サブ特性 | 設計観点 |
|---|---|
| 適切度認識性（Appropriateness Recognizability） | 機能やコンテンツの意味・目的がユーザーにとって直感的にわかるか |
| 学習容易性（Learnability） | 初めて使うユーザーでもすぐに操作方法を理解できるか |
| 運用容易性（Operability） | 操作や制御が簡単に行えるか、操作負荷が少ないか |
| ユーザーエラー防止性（User Error Protection） | ユーザーの誤操作を未然に防ぎ、発生時にも適切に対応できるか |
| ユーザー関与性（User Engagement） | ユーザーが積極的に操作したくなるような工夫があるか |
| 包括性（Inclusivity） | 多様なユーザー（年齢、障がいなど）でも使いやすい設計か |
| ユーザー支援（User Assistance） | 操作時に適切な支援が受けられるか |
| 自己記述性（Self-Descriptiveness） | 今なにをすべきか、次に何が起こるのかが自然とわかるか |
以下の表は、ユーザビリティのサブ特性を画面設計に落とし込む際の具体策をまとめたものです。
| サブ特性 | 画面設計での具体例 |
|---|---|
| 適切度認識性（Appropriateness Recognizability） | - ボタンに「保存」「削除」など具体的な動詞を使う - アイコン＋ラベルの併用 - 「＋」ボタンに「新規作成」とツールチップを表示 |
| 学習容易性（Learnability） | - 初回ログイン時のガイドツアー表示 - 一貫性のあるボタン配置・用語（例：常に右下に「保存」） - 操作履歴やチュートリアルリンクの配置 |
| 運用容易性（Operability） | - キーボード操作やショートカットのサポート - 頻繁に使うボタンを目立つ位置に配置 - フォーカス順の最適化（Tabキーで自然な順に移動） |
| ユーザーエラー防止性（User Error Protection） | - 削除操作には確認ダイアログを表示 - 入力チェックはリアルタイムで実施（例：必須項目、形式） - Undo機能や「元に戻す」オプションの提供 |
| ユーザー関与性（User Engagement） | - ステップ表示で進捗を可視化（例：申請手続きのフロー） - 成果や進捗の視覚化（例：グラフ、バッジ） - ローディング時のアニメーションやヒント表示 |
| 包括性（Inclusivity） | - カラーユニバーサルデザイン（CUD）対応 - 文字サイズ変更機能の提供 - 音声読み上げ対応（ARIA属性の付与など） |
| ユーザー支援（User Assistance） | - 入力欄にヒントや例（プレースホルダーやラベル） - コンテキストヘルプの用意 - FAQやチャットサポートへの導線 |
| 自己記述性（Self-Descriptiveness） | - 現在のステータス表示（例：「下書き中」「承認待ち」） - フォームの入力欄に「ここに電話番号を入力してください」などの案内文 - エラーや成功時のフィードバック表示（例：「保存しました」） |
セキュリティ
セキュリティ*12は、「機密性」「完全性」「否認防止」「責任追跡性」「真正性」など5つのサブ特性に分類されています。概要を次の表に示します。
| サブ特性 | 設計観点 |
|---|---|
| 機密性（Confidentiality） | 権限を持つユーザーのみが情報にアクセスできるように制御し、データが不正に閲覧・漏洩されないことを保証するか |
| 完全性（Integrity） | 情報や処理が不正に改ざんされないように保護し、正確で一貫性のある状態を維持できるか |
| 否認防止（Non-repudiation） | ユーザーまたはシステムが実行した行為について、後から否認できないよう証拠を保持し、責任を明確にできるか |
| 責任追跡性（Accountability） | ユーザーやシステムの操作を特定の主体に関連付けられるよう記録し、必要に応じて追跡できるか |
| 真正性（Authenticity） | ユーザー、デバイス、システム、通信が真正であることを確認し、なりすましを防止できるか |
以下の表は、セキュリティのサブ特性を画面設計に落とし込む際の具体策をまとめたものです。
| サブ特性 | 画面設計での具体例 |
|---|---|
| 機密性（Confidentiality） | - ログイン画面でパスワードをマスク表示し、表示切替ボタンを設置 - 個人情報入力欄には入力内容のツールチップ非表示、コピー不可を設定 - 重要情報を表示する際は二段階認証や再入力を要求 |
| 完全性（Integrity） | - 重要な入力フォームでは送信前に確認画面を表示 - 入力データを改ざん防止のためチェックサムや署名付きで送信 - 更新履歴を画面で確認できる監査ログ表示機能を提供 |
| 否認防止（Non-repudiation） | - 注文完了時に電子署名付きの確認メールを送付 - ユーザー操作（購入、解約など）ごとに日時・ユーザーIDを明示した履歴を表示 - 重要操作の確認画面で「同意」チェックボックスを必須化 |
| 責任追跡性（Accountability） | - 管理画面でユーザーごとの操作ログを閲覧可能にする - 画面上に「最終更新者」「最終更新日時」を表示 |
| 真正性（Authenticity） | - ログイン時に多要素認証（MFA）を導入 - セッションタイムアウト後は再ログインを要求し、なりすましを防止 - 外部連携サービス利用時に信頼できる認証プロバイダ（OAuth、SAMLなど）を使用し、画面上に認証済みマークを表示 |
まとめ
本記事では、システム開発における画面設計の重要性と、要件定義との連携について解説しました。
下図に、要件定義の成果物と画面設計の関係をまとめました。
画面はユーザーとシステムをつなぐ重要な接点であり、優れた設計は直感的で迷いのない操作体験を提供します。その基盤となるのが、ユーザーのメンタルモデルを反映したUI設計です。特に「対象 → 操作」という自然な思考順序を画面構成に取り入れることで、使いやすさが向上します。
ユーザーのメンタルモデルを反映するために、オブジェクト指向UIを活用することで、クラス設計と画面構成を結び付け、情報と操作を一貫性のある形で提供できます。
加えて、ナビゲーション設計や画面レイアウト設計では、デバイス・OS・フレームワークなどの技術的前提を踏まえた導線設計が不可欠です。
画面設計は非機能要件とも密接に関係し、有効性・効率性・満足性・ユーザビリティ・互換性・性能効率・セキュリティなどの品質特性を満たすことが求められます。
ユーザーの思考に沿った自然な操作性を備え、非機能要件を満たすよう技術的制約を踏まえて設計された画面は、業務効率を高め、ユーザー体験を向上させると同時に、システムの信頼性と持続的な価値を確実に支えます。
次の記事では、要件定義とAPI設計の関係について説明します。
*1:概念モデルともいう。
*2:「対象ベースの注意（object-based attention）」は、人が空間全体ではなく、物体や対象そのものに注意を向けるという認知心理学の理論です。これは視覚情報処理において、対象が人の注意の単位になることを示しており、UI設計における「ユーザーはまず対象を見つけ、それから操作を選ぶ」という行動傾向を裏付ける根拠とされています（Duncan, J. (1984). Selective attention and the organization of visual information. Journal of Experimental Psychology: General, 113(4), 501–517. ）。
*3:"Usability"は、ISO/IEC 25010:2023で、"Interaction Capability"に表現が変更された。この記事では、REBOKに従い、ユーザビリティのままとする。
*4:ISO/IEC 25010:2011に定義されている。
*5:ISO/IEC 25010:2011に定義されている。
*6:ISO/IEC 25010:2011に定義されている。
*7:非機能要件の特性（例：性能効率、セキュリティなど）の、下位に定義されている要素
*8:ISO/IEC 25010:2011に定義されている。
*9:ISO/IEC 25010:2023に定義されている。
*10:ISO/IEC 25010:2023に定義されている。
*11:"Usability"は、ISO/IEC 25010:2023で、"Interaction Capability"に表現が変更された。この記事では、REBOKに従い、ユーザビリティのままとする。
*12:ISO/IEC 25010:2023に定義されている。
