CRUD図と機能設計の考え方

• 日程: Day 8 / セッション 1
• 時間: 09:30-09:55（25分）
• 形式: 座学
• ゴール: CRUD図の役割（機能とテーブルの対応を見える化し設計漏れを発見する）と機能設計書に書くべき項目（入力チェック・ボタン動作・初期設定）を挙げられ、CRUD図で設計漏れを発見する手順を実例で説明できる
• 学習形式: 対話型解説、ケーススタディ

昨日（Day 7）はテーブル定義書とER図を作りました。データの入れ物と、入れ物どうしの関係が見えてきました。

ここで質問です。作ったテーブルは、すべての機能から正しく使われているでしょうか？

• 「会員テーブルはあるけど、会員登録機能を作り忘れていないか？」
• 「お気に入りテーブルがあるのに、誰も登録できないのでは？」
• 「予約テーブルに Delete機能が無い。本当に削除不要？」

これに答える道具が CRUD図 です。今日のセッションでは、CRUD図と機能設計書の役割を学びます。

CRUD図は、機能（行）とテーブル（列）の交点に C/R/U/D を書き込んだマトリクスです。「どの機能がどのテーブルに対して何をするか」を1枚で見える化します。

CRUD図の真の価値は、設計漏れを発見できる点にあります。次のパターンを見つけたら要注意です。

そのテーブルにデータが生まれない＝誰も登録できない。

例：shops 列に C が無い → 「店舗マスタはどうやって登録するの？」管理者用の店舗登録機能が抜けている可能性。

そのテーブルが誰にも読まれない＝そもそもデータが必要か疑問。

例：logs 列に R が無い → 書き込むだけで読まないなら、本当にDBに保存する必要があるか再考。

意図的に残すなら問題なし。意図しないなら漏れ。

例：reservations 列に D が無い → ユーザは予約キャンセルできない仕様か？要件再確認。

「予約作成」機能が R だけだったら？　Create を忘れている。

そもそもそのテーブルは不要かもしれない。

以下のCRUD図を見て、設計漏れを3つ見つけてみましょう。

問いかけ：気になる点は？

→ 解答例

1. products 列に C/U/D が無い → 商品マスタ管理機能が漏れている
2. favorites 列に C/D が無い → お気に入りを追加・削除する機能が無い（表示だけ）
3. orders 列に R/U/D が無い → 注文履歴の閲覧・キャンセルができない

• CRUD図は マトリクスの空白に意味がある
• 「意図して空白」と「漏れの空白」を区別する
• 漏れを見つけたら 外部設計書まで遡って修正（画面一覧・機能一覧）

機能設計書は、各機能の中身（処理ロジック）を実装者向けに記述した文書です。次の3要素を必ず書きます。

• 必須／任意
• 型・桁数
• フォーマット（メール形式・電話番号形式・日付形式）
• 値の範囲（数値の上下限）
• 既存データとの整合性（一意性チェックなど）

例：会員登録機能

• 押したときに何が起きるか
• どのテーブルに対して C/R/U/D を行うか
• 成功時の遷移先・表示
• 失敗時のメッセージ・遷移先

例：会員登録ボタン

1. 入力チェック（上記）。エラーがあれば同画面で表示
2. メールアドレスの重複チェック（members テーブルを SELECT）。重複ありなら「既に登録済みです」
3. パスワードをハッシュ化
4. members テーブルに INSERT
5. 成功時：ログイン画面へ遷移、「登録完了」メッセージ
6. 失敗時：同画面で「登録に失敗しました。時間をおいて再試行してください」

• 画面表示時のデフォルト値
• 表示順序（並び順）
• 初期表示件数（ページネーション）
• 非表示／読み取り専用にする項目

例：予約一覧画面

• 表示順：予約日時の降順
• 1ページの表示件数：20件
• 過去の予約は薄いグレー文字で表示
• 未来の予約のみ「キャンセル」ボタンを表示

機能設計でよく抜けるのが 異常系 です。

「ユーザは仕様書通りに使わない」が大前提。異常系を設計してこそ、ユーザに優しいシステムになります。

CRUD図のアイデアは1980年代の構造化分析（James Martin らの Information Engineering）に遡ります。「機能 × データ」のマトリクスで設計の全体性を担保する考え方は、当時から変わっていません。アジャイル時代になっても、全機能と全テーブルが1枚に収まる図の効力は健在です。1枚見れば設計のバランスが分かる、これがCRUD図の長く愛される理由です。

• 「私たちの機能一覧（貼り付け）とテーブル定義書（貼り付け）から CRUD 図のたたき台を作って」
• 「次のCRUD図（貼り付け）から設計漏れの候補を5件挙げて」
• 「会員登録機能の異常系を10個挙げて。よくある順に」
• 「機能設計書の項目漏れチェックリストを作って」

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

1. CRUD図は 機能とテーブルの対応マトリクス。空白から設計漏れを発見する道具
2. 機能設計書には 入力チェック・ボタン動作・初期設定を必ず書く
3. 異常系（空入力・桁オーバー・競合） を必ず設計する

次のセッション（Session 2）では、自チームのCRUD図を実際に作り、設計漏れを1件以上見つけて修正します。

• CRUD図の役割を1文で説明できる
• CRUDのそれぞれの意味とSQLを対応づけられる
• 設計漏れの典型パターンを3つ挙げられる
• 機能設計書の3要素を挙げられる
• 異常系の例を3つ挙げられる

• 前日資料：Day7_Session01_内部設計とDBMS_正規化の考え方.md 〜 Day7_Session03_ER図の作成.md
• Day5 機能一覧（自チーム成果物）
• Day7 テーブル定義書（自チーム成果物）