画面仕様書の作成と外部設計書の完成
概要
- 日程: Day 6 / セッション 3
- 時間: 11:10-12:40(90分)
- 形式: 実習
- ゴール: 主要画面の画面仕様書を作成し、画面一覧・機能一覧・画面遷移図と合わせて外部設計書として時間内にまとめ、AIとチームで整合性をクロスチェックできる
- 学習形式: ハンズオン実習(AIサポートあり)
導入(5分)
ここまでで揃ったもの:
- 状態遷移図(Day5 Session2)
- 画面一覧・機能一覧(Day5 Session3)
- 画面遷移図(Day6 Session2)
最後に画面仕様書を加えれば、外部設計書が完成します。
問いかけ: 外部設計書ができたあと、誰がどう使うと思いますか?
答えは2つ。お客様との認識合わせと、Day7以降の内部設計の入力です。今日完成させる成果物は、明日からの内部設計の土台になります。だから「曖昧さ」を残してはいけません。
このセッションの進め方:
- 画面仕様書を1つ全員で書く(20分)
- 主要画面を分担して書く(40分)
- 外部設計書としてまとめる(15分)
- クロスチェックと修正(10分)
本編(10分)
1. 画面仕様書テンプレート(再掲)
Session1で学んだ7項目を再確認します。
画面ID: S-xxx
画面名: 〇〇画面
目的: この画面で何を達成するか(1文)
レイアウト:
(ワイヤーフレームまたはテキストアート)
入力項目:
| 項目名 | 型 | 必須 | バリデーション |
ボタン・リンク:
| ボタン名 | 動作 | 遷移先画面ID |
表示項目:
| 項目名 | データソース(情報モデル)|
エラー時挙動:
- 入力エラー:
- 通信エラー:
- セッション切れ:
コード例: 「予約一覧画面」の画面仕様書(実例)
画面ID: S-201
画面名: 予約一覧画面
目的: ログイン中ユーザが自分の予約を一覧で確認し、詳細・キャンセルに進める
レイアウト:
+------------------------------------+
| ヘッダー [マイページ] [ログアウト] |
+------------------------------------+
| タイトル: 予約一覧 |
| |
| [絞り込み: 全て|今後|過去] [検索] |
| |
| | 日時 | 店舗 | 人数 | 状態 | 操作||
| |2024..|A店 | 2名 |予約済| 詳細|
| |2024..|B店 | 4名 |予約済| 詳細|
| |... |
| |
| [予約する] (新規) |
+------------------------------------+
入力項目:
| 項目名 | 型 | 必須 | バリデーション |
| 絞り込み | select | 任意 | 全/今後/過去 |
ボタン・リンク:
| ボタン名 | 動作 | 遷移先 |
| 詳細 | 該当行の詳細へ | S-202 |
| 予約する | 新規予約 | S-101 |
| ログアウト| セッション削除 | S-001 |
表示項目:
| 項目名 | ソース |
| 日時 | 予約情報.日時 |
| 店舗 | 店舗情報.名前 |
| 人数 | 予約情報.人数 |
| 状態 | 予約情報.状態 |
エラー時挙動:
- 予約0件: 「予約はありません」と表示し、[予約する]ボタンを目立たせる
- 通信エラー: 「読み込みに失敗しました [再試行]」を画面中央に表示
- セッション切れ: ログイン画面(S-011)にリダイレクト
2. 外部設計書のクロスチェック観点
外部設計書は4つの成果物の集合体です。互いに矛盾がないか確認します。
| チェック観点 | 確認内容 |
|---|---|
| 画面一覧 ↔ 画面遷移図 | 一覧の全画面が遷移図に登場するか |
| 画面遷移図 ↔ 画面仕様書 | 仕様書のボタン遷移先IDが遷移図と一致するか |
| 機能一覧 ↔ 画面仕様書 | 仕様書のボタン動作が機能一覧に登録されているか |
| 状態遷移図 ↔ 機能一覧 | 状態遷移1本につき機能が割り当てられているか |
| CJM To-Be ↔ 画面遷移図 | ペルソナのゴール到達経路が描かれているか |
コラム: 「設計書はラブレター」
外部設計書は、お客様・チームメンバー・未来の自分への手紙です。読む人が迷わない・誤解しない・抜けに気づける、それが良い設計書。完璧を目指すと終わりませんが、「自分が初めて読む人だったら困らないか」を基準にすると質が決まります。曖昧な表現は実装時に必ず問題化します。今日5分かけて明文化する手間は、明日以降の何時間も節約します。
💬 AIに聞いてみよう
- 「以下の画面仕様書をレビューしてください。実装者が迷う点はありますか?[仕様書貼付]」
- 「外部設計書一式(画面一覧・機能一覧・画面遷移図・画面仕様書)の整合性をチェックしてください。矛盾を5つ挙げて」
- 「画面仕様書に書くべき項目で、私たちが書き忘れている可能性が高いものは?」
実習・演習(70分)
課題
主要画面の画面仕様書を作成し、外部設計書として4つの成果物をまとめる。
進め方
1画面を全員で書く(20分)
- 一番複雑そうな画面(例: 予約フォーム、検索結果)を選ぶ
- テンプレートに沿って全項目を埋める
- 書きながら、項目の意味と粒度をチームで合意する
主要画面を分担(40分)
- 主要画面(最低5〜10画面)を分担
- 1人2〜3画面ずつ
- 画面遷移図の動線上にある画面を優先
外部設計書としてまとめる(15分)
- 1つの場所に集約
- 構成案:
- 表紙(プロジェクト名・チーム名・更新日)
- 1章: 画面一覧
- 2章: 機能一覧
- 3章: 画面遷移図
- 4章: 画面仕様書(画面ID順)
- 付録: 状態遷移図
クロスチェックと修正(15分)
- 5つのチェック観点を1つずつ確認
- 見つけた矛盾はその場で修正
- 修正できないものはissueとして列挙
成果物
- 外部設計書(画面一覧、機能一覧、画面遷移図、画面仕様書)
ヒント
- すべての画面を完璧に書こうとしない。主要画面で十分。残りは「画面一覧」に「未着手」と明記
- 共通レイアウト(ヘッダー・フッター)は1度だけ定義し、各画面では参照する
- 画面間で共通の項目(ユーザ名表示等)はテンプレート化
まとめ(5分)
外部設計書が完成しました。明日からは内部設計(Day7-8)に入ります。今日の成果物に書かれた「画面」「機能」「情報モデル」が、テーブル設計とCRUD図に変わります。
成果物を「設計レビュー」としてチーム全員で読み合わせ、誇りを持って完成宣言してください(話す&行う)。
🔄 振り返りチェック
- 主要画面の画面仕様書を作成した
- 4つの成果物を1つの外部設計書としてまとめた
- 5つのクロスチェック観点を全部確認した
- AIに整合性レビューを依頼した
- チームで完成宣言の読み合わせを行った
補足資料
- 入力: 画面一覧、機能一覧、画面遷移図(Day5-6)
- 出力: 外部設計書一式(Day7内部設計の入力)
- 参考: 状態遷移図(Day5 Session2)
学習ガイド
想定される質問と回答例
| 質問 | ヒント |
|---|---|
| 全画面の仕様書を時間内に書けない | 主要画面(メイン動線上)を優先。残りは「画面一覧で定義済み」とし、必要に応じて実装時に補足 |
| レイアウト図が描けない(絵心がない) | テキストアート(+とハイフンの枠)で十分。Markdownのコードブロックで書ける |
| バリデーションの細かいルールが決まらない | 「型」と「必須/任意」だけでも今日決める。詳細は内部設計(Day8 機能設計書)でもよい |
| 画面間で同じ情報を表示する箇所がある | 「共通表示部品」として別途定義し、各画面では参照する |
| 設計書のレビューで指摘が多すぎる | 「今修正するもの」「実装時でよいもの」「次工程で再検討するもの」に分類する |
つまずきやすいポイント
| つまずきポイント | ヒント |
|---|---|
| 仕様書を書きながら設計を変える | 設計変更が必要なら一旦止めてチーム合意。1人で勝手に変えない(合意した内容の変更は事前に報告して調整) |
| エラー時挙動を書き忘れる | 7項目のチェックリストを毎回確認する |
| 画面仕様書と画面遷移図のボタン名が違う | クロスチェック観点に「ボタン名の一致」も加える |
| 「外部設計書」というファイルを作らずバラバラに | 必ず1つの場所(ディレクトリまたは集約ファイル)にまとめる |
| 完成後にメンテナンスせず実装で乖離 | 「設計書とコードがずれたら設計書を直す」ルールをチームで合意(Day11で扱う) |