CRUD図の作成

• 日程: Day 8 / セッション 2
• 時間: [9:55-11:00]
• 形式: 実習
• ゴール: 機能一覧とテーブル定義書を突き合わせ、CRUD図を時間内に作成し、設計漏れを1件以上検出・修正できる
• 学習形式: ハンズオン実習（AIサポートあり）

前のセッションで、CRUD図が「設計のレントゲン写真」であることを学びました。
今からそのレントゲンを、自チームの設計に対して撮ります。

このセッションのゴールには、わざわざ「設計漏れを1件以上検出・修正できる」と書いてあります。
つまり、漏れが見つかることは織り込み済みです。

ここで考えてみてください。
漏れが見つかるのは、悪いことでしょうか？
——いいえ。実装が始まる前の今、紙の上で見つかる漏れは「最も安く直せる漏れ」です。
むしろ「1件も見つからない」方が、見方が甘い可能性を疑うべきです。

材料は2つ。外部設計書の機能一覧と、昨日のテーブル定義書です。

手順は4ステップです。

1. 表の枠を作る: 縦に機能一覧の全機能、横にテーブル定義書の全テーブルを並べる
2. マスを埋める: 機能ごとに「どのテーブルに何をするか」をC/R/U/Dで記入する
3. タテ・ヨコを点検する: 漏れのサインを探す
4. 漏れを修正する: 機能一覧・画面一覧など外部設計書まで遡って直す

点検の観点を整理します。

漏れの典型例:

• 会員テーブルにDがない→退会機能の漏れ。あるいは「論理削除（削除フラグでUにする）」という意図的な設計か、チームで決める
• お知らせテーブルにCがない→管理者がお知らせを登録する機能を忘れている
• 「設定画面」機能の行が全部空欄→何を設定する機能なのか定義が曖昧

漏れへの対処は2択です。
「機能を追加する」か「理由を明記して仕様としないことを決める」か。
どちらでもよいのですが、無自覚のまま放置するのが一番危険です。

• 機能一覧とテーブル定義書の「全部」を載せる。抜粋すると突き合わせの意味がなくなる
• 1機能ずつ「この機能を実装するとしたら、どのテーブルを触る？」と実装者の目で想像する
• 漏れの修正は必ず外部設計書に反映する。CRUD図の上だけで直すと設計書間に矛盾が生まれる
• 修正履歴を残す。「CRUD図点検により退会機能を追加（6/12）」のようなメモが後で効く

ソフトウェア工学の古典的データに「欠陥の修正コストは工程が進むごとに数倍〜数十倍に膨らむ」というものがあります（バリー・ベームの研究が有名）。
設計段階なら付箋1枚の修正が、リリース後ならユーザへの謝罪メールと深夜の緊急対応になります。
ベテランが設計レビューに異様に熱心なのは、深夜対応の記憶があるからです。
今日皆さんが見つける漏れ1件は、未来の夜更かし1回分の価値があります。

実習前の確認に使いましょう。たとえば：

• 「論理削除と物理削除の違いと、それぞれの使いどころを教えて」
• 「ログイン機能はどのテーブルに何をする？RだけでいいのかUも要るのか」
• 「CRUD図のマスが埋まらない機能がある。機能の定義が曖昧かどうか一緒に確認して」

自チームのCRUD図を作成し、設計漏れを検出・修正してください。

1. 機能一覧の全機能×テーブル定義書の全テーブルでCRUD図の枠を作る
2. 機能ごとにC/R/U/Dを記入する（1機能ずつ、操作の流れを声に出しながら埋めると漏れにくい）
3. タテ・ヨコ点検で漏れの候補を挙げる

   • C・R・U・Dが揃わない列は理由を言えるか
   • 空欄行（どのテーブルにも触らない機能）はないか
4. 漏れと判断したものは対応を決め、外部設計書（機能一覧・画面一覧・画面遷移図）とテーブル定義書まで遡って修正する
5. 完成したCRUD図と機能一覧・テーブル定義書をAIに渡し、「他に設計漏れの兆候はないか」をレビューしてもらう
6. 検出した漏れと対応内容を「設計漏れ記録」としてメモする（1件以上）

• CRUD図（全機能×全テーブル）
• 設計漏れ記録（検出した漏れ・対応・修正した設計書名）
• 修正済みの外部設計書・テーブル定義書（漏れがあった場合）

• マスの埋め方に迷ったら: 「ユーザがこのボタンを押した瞬間から画面が表示されるまで」を実況中継すると、触るテーブルが見えてきます
• 検索・一覧表示系の機能: ほぼ必ずRが入ります。Rの記入漏れが一番多いので注意
• 1つの機能がC・R・Uを全部行うこともある: 予約登録機能は、会員をR、空き状況をR、予約をC、のように複数マスを使います
• Dがない列を見つけたら: 即「漏れ」と決めず、「消さない設計（履歴保持・論理削除）」かをチームで議論しましょう。結論をメモに残せばどちらでも正解です
• AIレビューの依頼例: 「このCRUD図で、一般的なシステムにあるのにこの設計に欠けていそうな機能を3つ挙げて」
• 時間配分: 枠作り5分、マス埋め25分、点検と修正15分、AIレビューと記録10分が目安

今回学んだことを一言でまとめると「CRUD図は作って終わりではなく、タテ・ヨコに眺めて漏れを見つけ、外部設計まで遡って直すための道具」です。

• 機能×テーブルの全組み合わせを突き合わせた
• C・R・U・Dの欠けから設計漏れを検出した
• 修正は外部設計書まで遡って反映し、設計書間の矛盾を防いだ

次のセッションでは、機能1つひとつの中身（入力チェック・ボタンの動作・初期設定）を機能設計書に書き、内部設計書を完成させます。

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

• 自チームで検出した設計漏れは何でしたか？どう対応しましたか？
• 「Dがない列」を見つけたとき、漏れと意図的設計をどう区別しましたか？
• CRUD図の修正を、他のどの設計書に反映しましたか？

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

• 参考リンク: 自チームの外部設計書一式（機能一覧・画面一覧・画面遷移図・画面仕様書）
• 発展課題: 実装フェーズで機能を追加・変更したときにCRUD図をどう更新するか、チームの運用ルールを1行で決めておきましょう

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