前回（Vol.1）では、画面駆動設計の進め方やそのメリットについてご紹介しました。
今回は、実際にその画面駆動設計を適用して作成した「画面フロー」「各画面のUI構成」「処理とデータ設計図」について、具体例を挙げながら解説していきます。
🔗 設計資料へのリンク
以下のGitHubに、今回紹介する資料をすべて公開しています。ぜひ合わせてご覧ください。
1. 🎯 画面フローの作成
まず最初に取り組むのが「画面遷移図（画面フロー）」の作成です。
- 目的： ユーザーの操作に応じた画面の遷移パターンを明確にする
- ポイント： 各画面がどのように連携しているかを俯瞰して理解できる
例：ユーザー管理画面からの遷移
- ユーザー作成画面
- ユーザー編集画面
- 管理メニュー など
2. 🧩 各画面のUI構成と入力制約
画面ごとの設計資料では、次の情報を網羅的に定義しています：
✅ UI要素定義
| 項目名 | 分類 | フォーマット |
|---|---|---|
| ユーザー名 | テキストボックス | 全角かな |
| メールアドレス | テキストボックス | 半角英数 |
| ステータス | ドロップダウン | 有効/無効 |
✅ 初期表示状態の定義
- ユーザー管理画面では、画面初期表示時に全ユーザーの情報を一覧表示
3. ⚙️ 各UI操作に対する処理定義
ボタンやリンクなど、各UIコンポーネントに対して紐づく処理を明記します。
例：ユーザー管理画面の操作
| ボタン名 | 操作内容 |
|---|---|
| ユーザー作成 | 「ユーザー作成画面」へ遷移 |
| 編集 | 該当ユーザー情報を持って「ユーザー編集画面」へ遷移 |
| 削除 | 対象ユーザーを削除後、ユーザー一覧を最新状態で再表示 |
| 戻る | 管理メニューへ遷移 |
4. 🗃 データ構造とDAOの逆算設計
表示に必要な情報から、DBのデータ構造や取得方法を逆算して設計を行います。
例：ユーザー一覧表示に必要な項目
- ユーザーID
- ユーザー名
- ステータス
- 登録日時
これに応じて、DAOのSQLや取得メソッドの仕様を設計します。
✅ 画面駆動設計のメリットまとめ
- ユーザー視点に立った設計ができる
- 画面単位で仕様を管理できるため、漏れやブレが起きにくい
- エンジニア以外のメンバーとも共通認識を持ちやすい
🌟 このアプローチの特徴
| 特徴 | 説明 |
|---|---|
| ユーザー視点でスタート | 画面＝業務フローに近いため、関係者とも共有しやすい |
| 処理の漏れが少ない | 入力 → 処理 → 出力の流れが自然に設計に反映される |
| 非エンジニアとも共有しやすい | モック画面があれば、仕様のすり合わせがしやすい |
| プロトタイプ開発にも最適 | まず画面だけ作って「こんな感じです」と合意が取れる |
📝 実際にやってみた感想
この「画面から考える」やり方は、過去に文法中心でつまずいた自分にとって
非常にしっくり来るスタイル でした。
- 何を作るのかが常に明確
- モチベーションが保ちやすい
- ロジックの設計にも自然と流れができる
「画面 → 処理 → データ」と段階的に組み立てるので、初心者でも迷いにくいのが魅力です。
▶️ 次回予告：Vol.3へ続く
次回は、【Vol.3】詳細設計編：ER図で見るデータ構造と実装の土台 に入っていきます。