version: "1.0.0" name: screen-design description: 要件定義から画面一覧・画面遷移図・ワイヤーフレーム・画面項目定義を作成するスキル。ユーザーストーリーを元に画面設計を行う際、または画面設計書の作成・レビューが必要な場面で使う。

画面設計

目的

要件定義で整理されたユーザーストーリーを、実装可能な画面仕様へ落とし込む。 画面一覧・遷移図・ワイヤーフレーム・項目定義・状態定義を一貫した形式で作成し、開発チームが迷わず実装できる設計書を成果物とする。

使うタイミング

• 要件定義完了後、アーキテクチャ設計・詳細設計の前
• 新規画面追加時や既存画面の大幅改修時
• フロントエンド実装前にUI仕様を確定したいとき
• 画面設計書のレビュー依頼を受けたとき

進め方

1. ユーザーストーリーの棚卸し

要件定義書のユーザーストーリーを一覧化し、「誰が」「何をする」画面が必要かを抽出する。 画面IDを SCR-001 形式で採番する。

1. 画面一覧の作成

画面ID・画面名・対応するユーザーストーリー・担当ロール・優先度をまとめた表を作成する。

1. 画面遷移図の作成

MermaidのflowchartまたはstateDiagramで遷移を可視化する。 条件分岐（権限・認証状態・データ有無）も明記する。

``mermaid flowchart TD A[ログイン画面 SCR-001] -->|認証成功| B[ダッシュボード SCR-002] A -->|認証失敗| A B -->|新規作成クリック| C[登録フォーム SCR-003] C -->|保存成功| D[詳細画面 SCR-004] C -->|キャンセル| B D -->|編集クリック| E[編集フォーム SCR-005] E -->|保存| D ``

1. ワイヤーフレームの作成

テキスト/ASCIIで各画面のレイアウトを表現する。 コンポーネントの配置・優先度・サイズ感を伝えることが目的であり、デザインの精度は問わない。

``` +----------------------------------+

+----------------------------------+

+----------------------------------+

+----------------------------------+

+----------------------------------+ ```

1. 画面ごとの項目定義

各画面について表示項目・入力項目・アクションを定義する（後掲テンプレート参照）。 入力項目は型・必須/任意・バリデーションルール・エラーメッセージを必ず記載する。

1. 状態の網羅

全画面で以下5状態を定義する。未定義の場合は「N/A（理由）」と明記して省略可。

• 空状態(empty): データが0件のとき何を表示するか
• ローディング: データ取得中のインジケーター・スケルトン方針
• エラー: API失敗・ネットワーク断時のメッセージとリカバリーアクション
• 成功: 操作完了時のフィードバック（トースト・ダイアログ・遷移）
• 権限なし: 閲覧・操作権限がないユーザーへの表示

1. デザイン原則の確認

• 一貫性: ボタン・フォーム・カードなどはコンポーネントを再利用し、画面ごとに独自UIを作らない
• フィードバック: 全操作に対して結果を明示（成功トースト・エラーメッセージ・ローディングスピナー）
• アクセシビリティ: コントラスト比4.5:1以上、キーボード操作可能、画像にalt属性
• レスポンシブ方針: ブレークポイント（例: sp<768px / tab<1024px / pc≥1024px）と各サイズでの挙動を明記

1. レビューとチェックリスト確認

後掲チェックリストで抜け漏れを確認し、設計書を完成させる。

成果物テンプレート

# 画面設計書
 
## 画面一覧
 
| 画面ID  | 画面名       | 対応ストーリー | 担当ロール | 優先度 |
|---------|------------|------------|--------|------|
| SCR-001 | ログイン画面  | US-001     | 全ユーザー | 高   |
| SCR-002 | ダッシュボード | US-002     | 一般・管理者 | 高  |
 
## 画面遷移図
 

flowchart TD SCR-001 -->|認証成功| SCR-002

 
## 画面定義: [SCR-XXX] 画面名
 
**目的**: この画面でユーザーが達成することを1文で記述
 
**遷移元**: SCR-XXX（〇〇操作時）
**遷移先**: SCR-XXX（〇〇操作時）
 
### レイアウト（ワイヤーフレーム）
 

+---------------------------+

+---------------------------+

+---------------------------+

+---------------------------+

 
### 表示項目
 
| 項目名 | データ元（API/Store） | 形式・備考 |
|------|------------------|---------|
| ユーザー名 | GET /users/me | 文字列 |
 
### 入力項目
 
| 項目名 | 型 | 必須 | バリデーション | エラーメッセージ |
|------|--|----|-----------| ------------|
| メールアドレス | text | 必須 | RFC5322形式 | 有効なメールアドレスを入力してください |
| パスワード | password | 必須 | 8文字以上 | パスワードは8文字以上で入力してください |
 
### アクション
 
| ラベル | 種別 | 遷移先/処理 | 非活性条件 |
|------|----|-----------| --------|
| ログイン | ボタン（primary） | POST /auth → SCR-002 | 入力エラーあり |
| キャンセル | ボタン（ghost） | SCR-001に留まる | なし |
 
### 状態別表示
 
| 状態 | 表示内容 |
|----|--------|
| 空状態(empty) | N/A（認証画面のため） |
| ローディング | ボタンをスピナーに切り替え、フォームをdisable |
| エラー | フォーム下部にエラーメッセージを赤テキストで表示 |
| 成功 | ダッシュボードへ遷移 |
| 権限なし | N/A（認証前のため） |

チェックリスト

• [ ] 全ユーザーストーリーに対応する画面が存在する
• [ ] 全画面に画面IDが採番されている
• [ ] 画面遷移図に全画面が含まれ、孤立画面がない
• [ ] 全入力項目にバリデーションルールとエラーメッセージが定義されている
• [ ] 全画面で5状態（空/ローディング/エラー/成功/権限なし）が定義されている
• [ ] 表示項目のデータ出所（APIエンドポイントまたはStore）が明記されている
• [ ] コンポーネントの再利用方針が記載されている
• [ ] アクセシビリティ要件が記載されている
• [ ] レスポンシブ対応のブレークポイントと挙動が記載されている
• [ ] 設計書がアーキテクチャ設計と整合している

アンチパターン

• ハッピーパスしか設計しない: エラー状態・空状態を後回しにすると実装時に仕様が曖昧になる。必ず全5状態を先に定義する
• エラーメッセージ未定義: 「エラーを表示する」だけでは実装者がコピーを考えることになる。具体的な文言まで設計書に含める
• 画面ごとにUIパターンがバラバラ: 同種の操作に異なるUIパターンを使うとユーザーの混乱を招く。コンポーネント一覧を先に定義し再利用を徹底する
• データの出所が未定: 「ユーザー名を表示」と書いても取得元APIが不明だと実装できない。表示項目には必ずデータ元を明記する
• 遷移条件の未定義: 「詳細画面へ遷移する」だけでは権限・データ状態による分岐が漏れる。条件分岐を遷移図と定義表の両方に記載する
• アクセシビリティの後回し: 実装後の対応は工数が大きい。コントラスト・キーボード操作・alt属性は設計段階で要件化する

モデル委譲ガイド

共通原則は [[orchestration]] を参照。

関連スキル

• [[requirements-definition]] — ユーザーストーリーの元となる要件定義
• [[architecture-design]] — 画面設計と整合するフロントエンド構成の設計
• [[detailed-design]] — 画面設計を受けてコンポーネント・API仕様を詳細化
• [[implementation]] — 画面設計書を元にした実装
• [[task-breakdown]] — 画面単位でのタスク分解
• [[non-functional-requirements]] — アクセシビリティ・パフォーマンス要件の定義
• [[orchestration]] — マルチエージェント委譲の共通原則