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

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

ここまでで、データの入れ物（テーブル定義書）、入れ物どうしの関係（ER図）、機能と入れ物の対応（CRUD図）が揃いました。

最後に必要なのは、機能の中身＝処理ロジックです。実装者が「この機能を作って」と渡されて、迷わず書ける詳細度の文書を作ります。

問いかけ：実装者が機能設計書を読んで「ここが分からない」と困るのはどんなとき？

→ 「エラー時の挙動が書いていない」「成功時にどこへ遷移するかが曖昧」「入力チェックの順序が不明」など。これらをすべて先に決めるのが今日のゴールです。

機能ごとに以下のテンプレートで書きます。

## 機能名: 会員登録

### 概要
新規ユーザがメールアドレス・パスワード・氏名で会員登録する機能。

### 関連画面
- 入力画面：`screen-001-signup`
- 完了画面：`screen-002-signup-done`

### 入力項目
| 項目 | 必須 | 型 | 桁数 | 形式 | エラー時メッセージ |
|------|------|-----|------|------|-------------------|
| 氏名 | YES | string | 1-50 | - | 「氏名を入力してください」 |
| メール | YES | string | 1-100 | RFC5322 | 「メールアドレスの形式が正しくありません」 |
| パスワード | YES | string | 8-32 | 英数字混在 | 「8文字以上32文字以下、英数字混在で入力してください」 |

### ボタン動作
#### 「登録する」ボタン
1. 入力チェック（上表）。エラーがあれば同画面で表示。以降の処理は実行しない
2. メール重複チェック（`members` テーブル SELECT WHERE email = ?）
   - 重複あり：「このメールアドレスは既に登録されています」を表示
3. パスワードをハッシュ化（bcrypt 等）
4. `members` テーブルに INSERT
   - 失敗時：「登録に失敗しました。時間をおいて再試行してください」
5. 成功時：完了画面（`screen-002`）へ遷移。「登録完了」メッセージ表示

#### 「キャンセル」ボタン
1. 入力内容を破棄し、トップ画面（`screen-000`）へ遷移

### 初期設定
- 全項目空欄
- フォーカス：氏名項目
- パスワードは伏字で表示
- 「登録する」ボタンは全必須項目入力後に活性化（任意）

### 異常系
| 異常 | 挙動 |
|------|------|
| 全項目空のまま送信 | 各項目に「○○を入力してください」を表示 |
| メール100文字超 | 「メールアドレスが長すぎます」 |
| 同時登録（競合） | DBの UNIQUE 制約でエラー → 「このメールアドレスは既に登録されています」 |
| ネットワーク断 | 「通信エラーが発生しました。接続を確認してください」 |
| 想定外のサーバエラー | 「システムエラーが発生しました。管理者に連絡してください」 |

すべての機能をこの詳細度で書くと時間が足りません。優先順位を付けます。

実装に入る前に、最低限「核となる体験」のフル設計書がある状態を目指します。

• 「実装者が見て迷わない」が詳細度の基準
• 全機能を完璧にではなく、重要機能を確実に
• 機能設計書は実装中に 更新される前提（コードと設計書は同期）

異常系を漏らさないため、5観点でチェックします。

これら5観点を機能ごとに確認すれば、抜けはほぼ防げます。

「設計書ドリブン開発」とは、設計書をコードの先に置き、コードを設計書に合わせるスタイルです。コードを先に書いて後から設計書を書く（または書かない）のとは対照的です。

なぜ設計書ドリブンが大切なのか。それは コードを書く前のほうが直すのが安い からです。設計書の修正は5分、同じ修正をコードに反映するのは1時間、本番リリース後に直すのは数日──設計の早い段階で固めるほど、後工程のコストが下がります。

ただし「設計書を完璧にしてから実装」は不可能です。本研修のルール「設計書とコードがずれたら設計書を直す」を守れば、設計書ドリブンとアジャイルは両立します。設計書は 生きている文書 です。

内部設計書一式（テーブル定義書・ER図・CRUD図・機能設計書）の整合性をチェックします。

• 「次の機能設計書（貼り付け）を見て、実装者が迷う点を5件指摘して」
• 「『予約作成』機能の異常系を10個挙げて。発生頻度順に」
• 「機能設計書の入力チェックの記述は実装者が SQL に落とせるレベルになっているか確認して」
• 「機能設計書とCRUD図の不整合があれば指摘して」

自チームの主要機能について機能設計書を作成し、内部設計書一式を完成させます。

• 機能設計書（高優先度機能はフルテンプレート、中優先度は簡易版）
• 内部設計書一式：テーブル定義書 + ER図 + CRUD図 + 機能設計書
• 最終チェックリストの完了

• メンバーA：会員関連機能（登録・ログイン・更新・退会）
• メンバーB：主要機能（予約・申込・購入など）
• メンバーC：補助機能（一覧・詳細・検索）
• 全員：最後に集まって整合性をクロスチェック

私たちは○○システムを設計しています。
「○○機能」の機能設計書を以下のテンプレートで書きたい。
- 関連画面、入力項目、ボタン動作、初期設定、異常系
入力情報：（自チームの該当画面仕様書と関連テーブル定義書を貼り付け）

(1) たたき台を作って
(2) 異常系を5観点（空入力・桁/形式・範囲・競合・権限）で網羅して
(3) 実装者が迷いそうな箇所を指摘して

ペルソナと CJM（To-Be版）に戻ります。ペルソナがゴールに到達するために絶対必要な機能が「核」です。

今日のセッション要点を3つに絞ります。

1. 機能設計書には 入力項目・ボタン動作・初期設定・異常系 を書く
2. 「核となる体験」から優先的にフル設計。全機能を完璧にする必要はない
3. 内部設計書一式の 最終整合性チェックで実装フェーズに引き継ぐ

ここまでで 設計フェーズの主要成果物がほぼ揃いました。明日（Day 9）はプロジェクトマネジメント。実装期間（Day 10-17）に向けた計画を立てます。

• 高優先度機能の機能設計書が完成している
• 各機能で異常系が5観点でチェック済み
• 内部設計書一式（テーブル定義書・ER図・CRUD図・機能設計書）が揃っている
• 最終整合性チェックリストの全項目をクリアしている
• AI に「実装者が迷う点」をレビューしてもらった

• 前セッション資料：Day8_Session01_CRUD図と機能設計の考え方.md、Day8_Session02_CRUD図の作成.md
• Day5-6 外部設計書（自チーム成果物）
• Day7 テーブル定義書、ER図（自チーム成果物）
• Day8 Session2 CRUD図（自チーム成果物）