📖 テーマ設定
🔊 音声設定
1.2
1.0
1.0
▶️ 再生コントロール
🎵 BGM設定
0.3
🔔 効果音設定
0.3

画面仕様書の作成と外部設計書の完成

概要

  • 日程: Day 6 / セッション 3
  • 時間: 11:10-12:40(90分)
  • 形式: 実習
  • ゴール: 主要画面の画面仕様書を作成し、画面一覧・機能一覧・画面遷移図と合わせて外部設計書として時間内にまとめ、AIとチームで整合性をクロスチェックできる
  • 学習形式: ハンズオン実習(AIサポートあり)

導入(5分)

ここまでで揃ったもの:

  • 状態遷移図(Day5 Session2)
  • 画面一覧・機能一覧(Day5 Session3)
  • 画面遷移図(Day6 Session2)

最後に画面仕様書を加えれば、外部設計書が完成します。

問いかけ: 外部設計書ができたあと、誰がどう使うと思いますか?

答えは2つ。お客様との認識合わせと、Day7以降の内部設計の入力です。今日完成させる成果物は、明日からの内部設計の土台になります。だから「曖昧さ」を残してはいけません。

このセッションの進め方:

  1. 画面仕様書を1つ全員で書く(20分)
  2. 主要画面を分担して書く(40分)
  3. 外部設計書としてまとめる(15分)
  4. クロスチェックと修正(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. 1画面を全員で書く(20分)

    • 一番複雑そうな画面(例: 予約フォーム、検索結果)を選ぶ
    • テンプレートに沿って全項目を埋める
    • 書きながら、項目の意味と粒度をチームで合意する
  2. 主要画面を分担(40分)

    • 主要画面(最低5〜10画面)を分担
    • 1人2〜3画面ずつ
    • 画面遷移図の動線上にある画面を優先
  3. 外部設計書としてまとめる(15分)

    • 1つの場所に集約
    • 構成案:
      • 表紙(プロジェクト名・チーム名・更新日)
      • 1章: 画面一覧
      • 2章: 機能一覧
      • 3章: 画面遷移図
      • 4章: 画面仕様書(画面ID順)
      • 付録: 状態遷移図
  4. クロスチェックと修正(15分)

    • 5つのチェック観点を1つずつ確認
    • 見つけた矛盾はその場で修正
    • 修正できないものはissueとして列挙

成果物

  • 外部設計書(画面一覧、機能一覧、画面遷移図、画面仕様書)

ヒント

  • すべての画面を完璧に書こうとしない。主要画面で十分。残りは「画面一覧」に「未着手」と明記
  • 共通レイアウト(ヘッダー・フッター)は1度だけ定義し、各画面では参照する
  • 画面間で共通の項目(ユーザ名表示等)はテンプレート化

まとめ(5分)

外部設計書が完成しました。明日からは内部設計(Day7-8)に入ります。今日の成果物に書かれた「画面」「機能」「情報モデル」が、テーブル設計とCRUD図に変わります。

成果物を「設計レビュー」としてチーム全員で読み合わせ、誇りを持って完成宣言してください(話す&行う)。

🔄 振り返りチェック

  • 主要画面の画面仕様書を作成した
  • 4つの成果物を1つの外部設計書としてまとめた
  • 5つのクロスチェック観点を全部確認した
  • AIに整合性レビューを依頼した
  • チームで完成宣言の読み合わせを行った

補足資料

  • 入力: 画面一覧、機能一覧、画面遷移図(Day5-6)
  • 出力: 外部設計書一式(Day7内部設計の入力)
  • 参考: 状態遷移図(Day5 Session2)

学習ガイド

想定される質問と回答例

質問 ヒント
全画面の仕様書を時間内に書けない 主要画面(メイン動線上)を優先。残りは「画面一覧で定義済み」とし、必要に応じて実装時に補足
レイアウト図が描けない(絵心がない) テキストアート(+とハイフンの枠)で十分。Markdownのコードブロックで書ける
バリデーションの細かいルールが決まらない 「型」と「必須/任意」だけでも今日決める。詳細は内部設計(Day8 機能設計書)でもよい
画面間で同じ情報を表示する箇所がある 「共通表示部品」として別途定義し、各画面では参照する
設計書のレビューで指摘が多すぎる 「今修正するもの」「実装時でよいもの」「次工程で再検討するもの」に分類する

つまずきやすいポイント

つまずきポイント ヒント
仕様書を書きながら設計を変える 設計変更が必要なら一旦止めてチーム合意。1人で勝手に変えない(合意した内容の変更は事前に報告して調整)
エラー時挙動を書き忘れる 7項目のチェックリストを毎回確認する
画面仕様書と画面遷移図のボタン名が違う クロスチェック観点に「ボタン名の一致」も加える
「外部設計書」というファイルを作らずバラバラに 必ず1つの場所(ディレクトリまたは集約ファイル)にまとめる
完成後にメンテナンスせず実装で乖離 「設計書とコードがずれたら設計書を直す」ルールをチームで合意(Day11で扱う)
読み上げを開始します...

AIに質問する