機能設計書の作成と内部設計書の完成

• 日程: Day 8 / セッション 3
• 時間: [11:10-12:40]
• 形式: 実習
• ゴール: 主要機能の機能設計書（入力チェック・ボタンの動作・初期設定）を作成し、内部設計書一式を時間内に完成できる
• 学習形式: ハンズオン実習（AIサポートあり）

内部設計もいよいよ大詰めです。
テーブル定義書・ER図・CRUD図が揃い、残るは機能設計書だけになりました。

ここで考えてみてください。
来週の月曜（Day 10以降）、実装を始めるあなたは「予約登録ボタンを押したとき、空きがなかったら何と表示する？」と必ず迷います。
そのとき頼れるのは、今日のあなたが書く機能設計書だけです。

機能設計書は、未来の自分たちへの手紙です。
「いい感じに」と書かれた手紙ほど困るものはありません。
具体的に、言い切りで書きましょう。

このセッションの後半では、内部設計書一式（テーブル定義書・ER図・CRUD図・機能設計書）をまとめて完成させます。
Day 8のゴール達成まであと70分です。

機能1つにつき、次の3点セットを書きます。

(1) 初期設定（画面を開いた瞬間の状態）

(2) 項目の入力チェック

(3) ボタンの動作

• 正常系: 入力チェックOK→予約テーブルにC→完了画面に遷移し「予約を受け付けました」と表示
• 異常系1: 入力チェックNG→登録せず、該当項目の下に赤字でメッセージ表示。入力値は保持する
• 異常系2: 同時刻に空きがない→登録せず「この時間は満席です。別の時間をお選びください」と表示

正常系だけ書いて満足しないこと。
ユーザは設計者の想像どおりには操作しません。
空欄のまま連打する人、ブラウザの戻るボタンを押す人、絵文字を入力する人。全員が本番にはいます。

「すべての機能を同じ深さで書く時間はない」のも事実です。
そこで優先順位をつけます。

• 主要機能（ペルソナの課題解決に直結する機能、CでデータをつくるC系機能）→3点セットをフル装備で書く
• 補助機能（一覧表示など）→初期設定中心に簡潔に書く

• 3点セット: 初期設定・入力チェック・ボタンの動作。この順に書くと画面の時間軸（開く→入力→押す）と一致して漏れにくい
• 異常系（不正な入力・空入力）を必ず書く。「チェックしない」と決めた項目も「チェックなし」と明記する
• エラーメッセージは文言まで書く。ユーザを責めない表現（「不正な入力です」より「〜で入力してください」）にする
• CRUD図と整合させる。ボタンの動作に書いたテーブル操作がCRUD図のマスと一致しているか確認する

エラーメッセージ史上もっとも有名な迷文は、Windowsの「キーボードが接続されていません。続行するには何かキーを押してください」だと言われています。
キーボードがないのにキーを押せ、という無理難題。
笑い話ですが、原因は「異常系のメッセージを誰も設計しなかった」ことです。
エラーメッセージは、システムが一番困っているときにユーザと交わす唯一の会話。
だからこそ、平常時の今日、落ち着いて文言を設計しておくのです。

機能設計書ができたら、内部設計書として一式をまとめます。

統合時のチェック観点:

• ER図の全テーブルがテーブル定義書にあるか（逆も）
• CRUD図の横軸とテーブル定義書のテーブル一覧が一致するか
• 機能設計書のテーブル操作とCRUD図のマスが一致するか
• 機能設計書の入力チェックと画面仕様書の入力項目が一致するか（外部設計との整合）

チェックは「人の目」と「AIの目」の二段構えで行います。
AIには設計書を渡して「実装者として読んだとき迷う点はないか」をレビューしてもらいます。

• 設計書は単体で正しくても、組み合わせると矛盾していることがある。完成宣言の前に必ずクロスチェック
• 「この機能設計で実装者が迷う点はないか」というAIレビューは、明日以降の自分たちを助ける最後の安全網
• 矛盾を直したら、修正がさらに別の設計書に波及しないかをもう一周確認する

建築の世界では、図面一式の整合を確認する「図面照合」という専門工程があり、照合専門の技術者までいます。
意匠図では窓なのに構造図では壁、という矛盾は実際に起きるからです。
ソフトウェアの設計書も同じで、「書類同士のケンカ」は珍しくありません。
今日の皆さんは、設計者と照合技術者の一人二役というわけです。

実習前に確認しておきましょう。たとえば：

• 「入力チェックの観点を網羅したチェックリストを作って」
• 「ユーザを不安にさせないエラーメッセージの書き方のコツは？」
• 「機能設計書のテンプレートを、うちのチームの予約登録機能向けに作って」

機能設計書を作成し、内部設計書一式を完成させてください。

1. 機能一覧から主要機能を選ぶ（ペルソナの課題解決に直結する機能とC系機能を優先）
2. 主要機能の機能設計書を3点セット（初期設定・入力チェック・ボタンの動作）で作成する。異常系（不正な入力・空入力）を必ず含める
3. 補助機能は簡潔版（初期設定中心）で作成する
4. AIに各機能設計書を渡し、「この機能設計で実装者が迷う点はないか」をレビューしてもらい、指摘を反映する
5. テーブル定義書・ER図・CRUD図・機能設計書を内部設計書として1つにまとめる
6. 一式の整合性チェック（本編のチェック観点）をチームで行い、矛盾があれば修正する
7. 最後にチーム全員で内部設計書をめくりながら、1人1パート口頭で説明する読み合わせを行う（話す＆行う）

• 機能設計書（主要機能は3点セットフル装備、補助機能は簡潔版）
• 内部設計書一式（テーブル定義書・ER図・CRUD図・機能設計書）
• 整合性チェックの結果メモ（確認した観点と修正内容）

• どの機能から書くか迷ったら: CRUD図でCが付いている機能から。データを生むところが一番設計の濃度が必要です
• 入力チェックの洗い出し: 画面仕様書の入力項目一覧を縦に並べ、1項目ずつ「必須？形式？範囲？」と3回問います
• 異常系が思いつかないとき: AIに「この機能に意地悪なユーザがやりそうな操作を10個挙げて」と頼むと一気に出てきます
• AIレビューの依頼例: 「あなたはこの機能の実装担当です。この機能設計書を読んで、実装前に確認したい質問をすべて挙げてください」——出てきた質問が、設計書に足りない記述です
• 時間が足りないとき: 全機能を浅く書くより、主要機能を深く書く方が実装フェーズで効きます
• 時間配分: 主要機能の設計25分、AIレビューと反映10分、統合と整合性チェック10分、読み合わせ5分が目安

今回学んだことを一言でまとめると「機能設計書は初期設定・入力チェック・ボタンの動作の3点セットを異常系まで書き切り、一式の整合性チェックを経て内部設計書が完成する」です。

• 機能設計書＝未来の実装者（自分たち）への手紙。迷わせない解像度で書く
• 異常系の設計が品質を決める
• テーブル定義書・ER図・CRUD図・機能設計書のクロスチェックで「書類同士のケンカ」を解消した

これで設計フェーズの主要成果物が出揃いました。
次回（Day 9）はプロジェクトマネジメントです。この設計を「いつ・誰が・どの順で」作るのか、WBSとかんばんで計画します。

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

• 機能設計書の3点セットを、自チームの機能を例に説明できますか？
• 自チームの主要機能で、どんな異常系を設計しましたか？
• 整合性チェックで見つけた矛盾（または確認した観点）を1つ挙げられますか？
• 内部設計書一式には何が含まれますか？

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

• 参考リンク: 自チームの外部設計書（画面仕様書の入力項目一覧は入力チェック設計の直接の材料になる）
• 発展課題: 主要機能1つについて、機能設計書から「テスト項目表」をAIと一緒に作ってみましょう。設計書がそのままテストのチェックリストになることが実感できます（Day 16の先取り）

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