UI起点で考えるアプリケーション設計 / UI‑Driven Application Design
はじめに
アプリケーション設計の議論では、いまだに DB・バックエンド主体 の考え方が中心に語られることが多い。ER図、API、ドメインモデル、レイヤー構成──それらは確かに重要だ。しかし、UIが語られていない設計は本当にプロダクトの設計と言えるのだろうか。
本ドキュメントは、次の前提から出発する。
アプリケーションにおいて、ユーザーが触るのは UI だけである。
DBもAPIもドメインも、ユーザーから見れば存在しない。ユーザーが現実として認識するのは、表示され、操作できる UI だけだ。本稿では、この前提に立った「UI起点の設計思想」を整理する。
1. UIは要件である
要件定義書に UI が書かれていないケースは少なくない。しかし、それは本質的に ユーザー要件を定義していない。
UIが存在して初めて、次の問いが定義できる。
- ユーザーは何を見て判断するのか
- どの操作が許され、どれが許されないのか
- 失敗したとき、何が起きたように「見える」のか
- 操作途中で中断された場合、どう再開されるのか
これらはすべて UI の問題であり、UI を書かずに裏側だけ定義しても、現実の利用状況は固定されない。
UIはデザインではなく、要件の可視化された完成形である。
2. UI仕様書と機能仕様書は往復する
正しい設計の流れは一方向ではない。
- UI仕様書を書く
- そのUIを成立させるために必要な処理を考える
- 機能仕様書を書く
- 機能制約により UI が成立しない箇所に気づく
- UI仕様書に戻って修正する
この UI ↔ 機能 の往復 こそが設計である。
機能仕様書だけを書いている場合、UIは暗黙知や実装者の解釈に委ねられ、結果として「想定外」が量産される。
3. DB中心設計が古くなった理由
DB中心設計は、次の前提のもとでは合理的だった。
- ユーザーは正しい手順で操作する
- 操作は同期的に完了する
- 途中中断は例外
- UIは単なる入力フォーム
しかし現代のアプリケーションでは、
- 操作は頻繁に中断される
- 通信は不安定
- 複数デバイスを跨ぐ
- ユーザーは UI の表示を「真実」として判断する
もはや 事実の発生源は DB ではなく UI である。
DBは「最終的な記録係」に過ぎず、現実は UI 上で発生している。
4. 常時サーバー前提モデルへの違和感
従来のクライアント・サーバーモデルは、
- サーバーは常に稼働
- クライアントは薄い
- 通信は安定
という前提に依存している。
しかしモバイル・Webアプリの現実は異なる。
- アプリはOSにより停止される
- 回線は頻繁に切れる
- オフライン状態が常態
そのため、
- UIは自立して状態を持つ
- 通信はイベント
- サーバーは検証・同期・集約役
という UI主権モデル が自然に導かれる。
5. ペルソナではなくコンテキスト
アプリ設計において、趣味や性格を含むペルソナはほとんど役に立たない。
必要なのは「誰か」ではなく「どんな状況か」である。
例：
産後ママが育児の合間に使うアプリ
この一文には、
- 片手操作
- 中断前提
- 集中力が断続的
- 失敗コストが高い
といった UI制約 が含まれている。
有効なのは、
- ITリテラシー
- 利用頻度
- 失敗コスト
- 共有されているUI語彙（よく使うアプリ）
といった 設計に変換可能な情報 だけである。
6. なぜ設計本はUIを扱わないのか
設計本の多くは、UIを「実装詳細」として切り捨てている。一方、UI/UX本は実装や制約をブラックボックス化する。
結果として、
- UIで起きる現実
- 設計で保証すべき責任範囲
を同時に扱う書籍が存在しない。
このドキュメントは、その空白を埋める試みである。
7. 結論
UIは要件であり、 設計はその翻訳である。
UIが書かれていない要件定義やアーキテクチャは、ユーザー不在の設計であり、現代のアプリケーションでは信頼できない。
UI‑Driven Application Design (English)
Introduction
In many discussions about application architecture, design is still centered around databases and backend systems. While these elements are important, they are not what users interact with.
In an application, the only thing users actually touch is the UI.
Databases, APIs, and domains are invisible to users. The UI defines reality.
1. UI Is a Requirement
A requirement specification without UI does not define user requirements.
Only with UI can we define:
- What users see and decide
- What actions are allowed
- How failure appears
- How interruption and recovery work
UI is not decoration. It is the finalized form of requirements.
2. UI and Functional Specifications Must Iterate
Correct design is iterative:
- Define UI
- Derive required functions
- Discover constraints
- Revise UI
This back-and-forth is design itself.
3. Why Database‑Centric Design Is Outdated
Modern applications assume:
- Interruption
- Unstable connectivity
- Multi‑device usage
- UI as the perceived source of truth
The database is no longer the origin of reality. The UI is.
4. Rethinking Always‑On Server Models
Clients must be autonomous.
- UI holds state
- Communication is event‑based
- Servers validate, synchronize, and aggregate
5. Context Over Personas
Personas based on hobbies or personalities are ineffective.
What matters is context:
- Cognitive load
- Time constraints
- Error cost
- Shared UI vocabulary
6. The Missing Link in Design Literature
Architecture books ignore UI. UI/UX books ignore implementation.
This document argues that UI is the foundation of application design.
Conclusion
UI is the requirement. Architecture is its translation.