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

• 日程: Day 6 / セッション 3
• 時間: [11:10-12:40]
• 形式: 実習
• ゴール: 主要画面の画面仕様書を作成し、画面一覧・機能一覧・画面遷移図と合わせて外部設計書として時間内にまとめられる
• 学習形式: ハンズオン実習（AIサポートあり）

外部設計もいよいよ大詰めです。手元にはもう、画面一覧・機能一覧・画面遷移図が揃っています。
残るピースは画面仕様書。そして4点セットを外部設計書として1つにまとめれば完成です。

ここで問いかけです。

「画面遷移図を見れば『どの画面からどの画面へ行くか』は分かります。
では、実装する人がそれでも作れないのはなぜでしょうか？」

そう、画面の中身が決まっていないからです。
どんな項目を入力するのか、ボタンを押すと何が起きるのか。それを言い切るのが画面仕様書です。
Day 2の言葉を借りれば、外部設計書は「ユーザ・お客様とチームの共通認識」の集大成。今日中に完成させましょう。

時間は有限です。全画面の仕様書を均等に書くのではなく、主要画面から書きます。

主要画面の選び方:

• 背骨（ペルソナの最短経路）上の画面 → 最優先
• 入力項目が多い画面（登録・変更系） → 仕様の決めどころが多いので優先
• 表示だけの単純な画面 → 後回し（時間が余ったら）

セッション1で学んだ項目を、予約登録画面で書くとこうなります。

「電話番号: 文字列」だけでは仕様になりません。「ハイフンなし10〜11桁」まで書いて、初めて実装者が迷わなくなります。
逆に、細かくしすぎて「ボタンの色は#FF6600」まで書く必要は今はありません。見た目の詳細はDay 10のプロトタイプで詰めます。

• 主要画面（背骨上・入力が多い画面）から書く。全画面均等は時間切れのもと
• 入力項目は「型・必須/任意・制約」の3点セットで言い切る
• 異常系（未入力・範囲外・形式違い）を必ず1項目以上書く

入力チェックの世界には「ユーザの入力を信用するな」という鉄則があり、セキュリティ業界では「すべての入力は悪意があるものとして扱え」とまで言われます。有名な小話が「Bobby Tables事件」——海外の人気漫画xkcdに、息子の名前を「Robert'); DROP TABLE Students;--」と名付けてデータベースを破壊する母親が登場し、世界中のエンジニアが「入力チェック大事」と頷きました。実在の人物では、姓が「Null」さんという方が世界中のシステムでエラー扱いされて困っている、という本当の話もあります。

4点セットが揃ったら、外部設計書として綴じます。構成はこうです。

1. 表紙（システム名・チーム名・版数・日付）
2. 画面一覧
3. 機能一覧
4. 画面遷移図
5. 画面仕様書（主要画面分）

ただし、綴じる前にクロスチェックが必須です。バラバラに作った文書には、必ずと言っていいほど矛盾が潜んでいます。

チェック観点の例:

• 画面一覧にあるのに遷移図にない画面（またはその逆）はないか
• 画面仕様書のボタンの遷移先は、遷移図の矢印と一致しているか
• 機能一覧の全機能が、いずれかの画面仕様書（または画面一覧の備考）に現れるか
• 画面ID・画面名・機能IDの表記ゆれはないか

人間の目とAIの両方でチェックするのが今日の定石です。AIは表記ゆれや対応漏れの検出が得意です。

• クロスチェックは文書のペアごとに行う（一覧↔遷移図、遷移図↔仕様書、仕様書↔機能一覧）
• 矛盾が見つかったら「どちらが正しいか」をチームで決めてから直す。勝手に片方を直さない（合意した内容の変更は事前に報告して調整）
• 外部設計書は来週のDay 7（内部設計）とDay 10（プロトタイプ）の入力になる。未来の自分たちへの引き継ぎ書のつもりで仕上げる

文書間の矛盾チェックは、実務では「トレーサビリティ（追跡可能性）」と呼ばれ、医療機器や自動車のソフトウェア開発では法規制で義務付けられているほど重要です。1999年、NASAの火星探査機マーズ・クライメイト・オービターは、チーム間で単位（メートル法とヤード・ポンド法）の認識がずれていたために火星の大気で燃え尽きました。損失は約1億2500万ドル。「文書間の整合性チェックを怠ると探査機が落ちる」——皆さんのクロスチェック10分には、それだけの価値があります。

実習中に迷ったら、AIに相談しましょう。たとえば：

• 「この画面の入力項目に必要な制約（型・桁・範囲）を一緒に考えて」（項目リストを貼る）
• 「この画面仕様書を実装者の目線でレビューして。迷う点・曖昧な点を指摘して」
• 「画面一覧・機能一覧・画面遷移図・画面仕様書を貼るので、矛盾や対応漏れを表で指摘して」
• 「異常系で考慮すべきパターンを、この画面について列挙して」

主要画面の画面仕様書を作成し、外部設計書を完成させてください。

手順:

1. 主要画面を選定する（背骨上の画面＋入力の多い画面、目安3〜5画面）（5分）
2. 画面仕様書をチームで分担して作成する（25分）

   • 項目: 画面ID・画面名／目的／レイアウト／入力項目（型・必須/任意・制約）／ボタンと遷移先／異常系
3. クロスチェックを行う（15分）

   • チームで文書ペアごとに突き合わせる
   • AIに4点セットを見せて矛盾・対応漏れを検出してもらう
4. 指摘を修正し、表紙をつけて外部設計書として綴じる（10分）

ルール:

• 仕様は数字・選択肢・画面IDで言い切る（「適切に」「ちゃんと」は禁止）
• 矛盾の修正は、どちらを直すかチームで合意してから行う

• 「外部設計書」一式（表紙＋画面一覧＋機能一覧＋画面遷移図＋主要画面の画面仕様書）
• クロスチェックで発見した矛盾とその修正内容のリスト（1件以上見つかるのが普通です。0件の場合はチェック不足を疑いましょう）

• レイアウトに時間がかかる → 手描きの写真やワイヤーフレームで十分です。きれいな見た目はDay 10のプロトタイプで作ります。今日は「何がどこにあるか」が伝わればOK
• 制約が決められない → 「氏名は何文字まで？」に正解はありません。チームで決めて書くことが大事。迷ったらAIに「一般的な相場」を聞いて参考にしましょう
• 異常系が思いつかない → 「空で送信したら？」「ありえない値（人数0人・過去の日時）を入れたら？」「同じ予約を2回送信したら？」の3つの型から考え始めると出てきます
• クロスチェックで矛盾が大量に出た → 慌てない。影響の大きい順（背骨上の画面 → 枝の画面）に直しましょう。時間内に直しきれない分は「未修正リスト」として残し、来週の朝会で対応します
• AIレビューのコツ → 4点セットを一度に貼り、「矛盾を表形式で、文書名と該当箇所つきで指摘して」と頼むと、修正作業がしやすい形で返ってきます

今回学んだことを一言でまとめると、**「仕様は言い切る、文書はクロスチェックで揃える」**です。

• 画面仕様書は主要画面から。入力項目は型・必須/任意・制約の3点セット、異常系も忘れずに
• 外部設計書は4点セットの綴じ込み＋クロスチェックで完成
• これでDay 5-6の成果物「外部設計書」が完成。到達目標No.4の達成です

振り返れば、この2日間は一本道でした。
情報モデル → 状態遷移（CRUD）→ 機能一覧・画面一覧 → 画面遷移図 → 画面仕様書 → 外部設計書。
「情報を状態遷移させるのが機能であり画面になる」という1つの考え方が、すべての成果物を貫いています。

次回Day 7からは内部設計です。外部設計書を「システムの中でどう実現するか」、データベースの正規化とテーブル設計から始めます。今日完成させた外部設計書が、そのまま明日の入力になります。

以下の問いに答えられるか確認してみましょう：

• 画面仕様書の入力項目に書くべき3点セットは何ですか？
• クロスチェックの観点を2つ以上、具体的に挙げられますか？
• 「情報モデル」から「外部設計書」までの流れを、成果物名を順に並べて説明できますか？
• 自チームの外部設計書を、他チームの人に5分で説明できますか？

答えに自信がない場合は、該当部分を読み返すか、AIに質問してみてください。

• 参考リンク: IPA「機能要件の合意形成ガイド（画面編）」（画面仕様書の記載項目の実務例）
• 発展課題: 完成した外部設計書をAIに渡し「この設計書だけで実装できるか、実装者として質問リストを出して」と依頼する。出てきた質問が、設計書の曖昧さの正体です

このセクションは、受講者が理解を深めることをサポートする参考情報です。