CRUD図と機能設計の考え方

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

昨日、テーブル定義書とER図ができました。
そして以前、外部設計で機能一覧も作りました。

ここで考えてみてください。
「会員登録機能は会員テーブルに行を作る」——これは当然わかります。
では「退会した会員の予約データは、どの機能が消すのでしょうか？」

……即答できないチームが多いはずです。
機能一覧とテーブル定義書は、それぞれ単体では正しくても、突き合わせると穴が見つかります。
その突き合わせ表がCRUD図です。

CRUDという言葉自体はDay 5で登場済みです。
あのときは「情報の状態遷移」から画面・機能を洗い出すために使いました。
今日は同じCRUDを「機能×テーブル」の整合性チェックに使います。

CRUD図は、縦に機能、横にテーブルを並べた表です。
各マスに、その機能がそのテーブルに行う操作を書きます。

• C（Create）: 行を作る
• R（Read）: 行を読む
• U（Update）: 行を書き換える
• D（Delete）: 行を消す

蔵書管理システムを例にしたCRUD図です。

この表をタテ・ヨコに眺めると、設計漏れが浮かび上がります。

• 列を見る: 会員テーブルのD（削除）がどこにもない→「退会機能」を忘れている
• 列を見る: あるテーブルにCしかない→作られるだけで誰にも読まれないテーブル。本当に必要？
• 行を見る: どのテーブルにも触らない機能→実体のない機能。定義が曖昧なサイン

健康診断に例えると、CRUD図は設計のレントゲン写真です。
外見（外部設計）が立派でも、撮ってみると骨（データ操作）が1本足りない、ということが本当によくあります。

• CRUD図の真価は「書くこと」ではなく「眺めて漏れを見つけること」
• チェックの定石: 全テーブルにC・R・U・Dが揃っているか。揃わない場合は「揃わなくてよい理由」を言えるか
• Dがない判断もあり得る（履歴は消さない等）。大事なのは「意図的にDなし」と「忘れてDなし」を区別すること
• 漏れが見つかったら、機能一覧（外部設計書）まで遡って修正する。設計書同士はつながっている

CRUDという略語を広めたのは、1983年のジェームズ・マーティンの著書と言われています。
英単語の crud は実は「汚れ・カス」という意味のスラング。
「システムの本質はデータの生成と消滅だ」という大真面目な概念が、汚れと同じ綴りなのは英語圏ではちょっとした笑い話です。
なお、派生形に CRUDS（Searchを追加）や BREAD（Browse, Read, Edit, Add, Delete）もあります。
BREADは「パン」。エンジニアは略語に食べ物を選びがちです。

CRUD図で「どの機能が何をするか」の全体像が固まったら、機能1つひとつの中身を機能設計書に書きます。
本研修で必ず書くのは次の3点です。

• 項目の入力チェック

  • 必須チェック: 空のまま登録ボタンを押されたら？
  • 形式チェック: メール欄に「あいうえお」と入れられたら？
  • 範囲チェック: 予約人数に「-5」や「99999」を入れられたら？
• ボタンの動作

  • 押すと何が起きるか: どのテーブルに何をして（CRUD）、どの画面に遷移し、何のメッセージを出すか
  • 失敗時はどうなるか: エラーメッセージの内容と表示位置、入力値は保持するか
• 初期設定

  • 画面を開いた瞬間の状態: 入力欄の初期値、日付欄は今日の日付か空か、一覧の並び順は何順か

良い仕様と悪い仕様を対比します。
「日付を正しくチェックする」は悪い仕様です。「正しく」の解釈が実装者任せだからです。
「予約日は今日以降90日以内。違反時は『予約日は今日から90日以内で指定してください』と赤字表示し、入力値は保持する」は良い仕様です。実装者が迷う余地がありません。

ここで少し考えてみてください。
あなたが実装担当だとして、仕様書に「いい感じにエラーを出す」と書いてあったらどう感じますか？
機能設計書は、来週の実装フェーズの自分たちへの指示書です。
未来の自分を迷わせない解像度で書きましょう。

• 機能設計書の3点セット: 入力チェック・ボタンの動作・初期設定
• 正常系（うまくいく流れ）だけでなく異常系（不正な入力・空入力）を必ず書く。バグの多くは異常系の考慮漏れから生まれる
• 判断基準は「実装者がこの文章だけで迷わず作れるか」
• エラーメッセージの文言まで書く。「エラーを表示」だけでは実装者ごとにバラバラになる

1996年、欧州の大型ロケット「アリアン5」は発射37秒後に爆発しました。
原因は、速度データの変換処理での数値あふれ——いわば入力チェックの考慮漏れ1件です。
損失は数百億円。「異常系の設計」の重要さを語るとき、世界中の講師がこの事故を引用します。
皆さんのシステムはロケットほど高価ではありませんが、「変な値が来たらどうする？」を考える習慣は、今日から同じです。

ここまでの内容で疑問があれば、AIに質問してみましょう。たとえば：

• 「CRUD図とDay 5でやった状態遷移のCRUDはどう関係しているの？」
• 「入力チェックには他にどんな種類がある？一覧で教えて」
• 「『論理削除』って聞いたことがあるけど、Dの設計とどう関係する？」
• 「エラーメッセージの良い書き方の例を5つ見せて」

今回学んだことを一言でまとめると「CRUD図は機能×テーブルのレントゲン写真、機能設計書は実装者を迷わせないための指示書」です。

• CRUD図＝機能とテーブルの対応表。C・R・U・Dの欠けから設計漏れを発見する
• 漏れを見つけたら外部設計書まで遡って直す
• 機能設計書＝入力チェック・ボタンの動作・初期設定の3点セット。異常系を必ず書く

次のセッションでは、実際に自チームのCRUD図を作り、設計漏れを検出・修正します。

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

• CRUD図の縦軸と横軸には何を並べますか？
• 「あるテーブルの列にDがない」とき、確認すべきことは何ですか？
• 機能設計書に書くべき3つの項目を挙げられますか？
• 「正しくチェックする」という仕様の何が問題か説明できますか？

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

• 参考リンク: 自チームの機能一覧とテーブル定義書（次セッションですぐ使うので手元に開いておく）
• 発展課題: 普段使っているWebサービスの会員登録画面で、わざと変な値を入れてみましょう。どんな入力チェックとエラーメッセージが実装されているか観察すると、機能設計の生きた教材になります

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