Day30 後半のゴール
「“人に見せられるアウトプット”として仕上げる具体的な型を身につける」
前半で、「設計書・ER図・SQLレビューの意味」はだいぶつかめました。
後半では、それを実際にどう書くか・どうレビューするかを、もう一段具体的にかみ砕きます。
ここでのゴールはこうです。
最低限の設計書テンプレートを、自分で埋められるイメージを持つ。
ER図を「読む」だけでなく、「描くときに意識するコツ」を理解する。
SQLレビューのチェックポイントを、チェックリストとして頭に持てる。
設計書の“最低限テンプレート”を具体化する
「EC総合課題を題材に、章立てをそのまま真似できる形にする」
まずは、「これを真似して書けば、とりあえず実務でも通用する」レベルの設計書構成を、EC総合課題に当てはめてみます。
1. システム概要
ここでは、1〜2段落で「何をするシステムか」を書きます。
例：
「本システムは、小規模ECサイトのバックエンドとして、ユーザー管理・商品管理・注文処理・売上集計を提供する。
ユーザーは会員登録・ログインを行い、商品を閲覧・購入できる。管理者は商品登録・更新、注文状況の確認、売上集計の閲覧を行う。」
ポイントは、「誰が」「何のために」「何をするシステムか」が一読で分かることです。
2. 機能一覧
ここは、前半で整理した機能を、もう少しだけ具体化して書きます。
例：
ユーザー管理：ユーザー登録、ログイン、ユーザー一覧表示。
商品管理：商品登録・更新・非公開化、商品一覧表示。
注文処理：カート内容を元にした注文作成、注文ステータス変更。
売上集計：日別売上、商品別売上、ユーザー別売上の集計表示。
ここまで書くと、「このシステムに何を期待できるか」が明確になります。
3. テーブル設計
ここが設計書の中核です。
テーブルごとに、次のようなフォーマットで書くと分かりやすくなります。
テーブル名：users
役割：システムを利用するユーザーを管理する。
主なカラム：
id：ユーザーを一意に識別する主キー。
email：ログインIDとして利用するメールアドレス。ユニーク制約を付与。
password_hash：パスワードのハッシュ値。平文は保持しない。
created_at / updated_at：作成日時・更新日時。監査・調査に利用する。
テーブル名：orders
役割：ユーザーによる1回の注文を表す。
主なカラム：
id：注文を一意に識別する主キー。
user_id：注文を行ったユーザー（users.id）への外部キー。
total_amount：注文の合計金額。order_items の合計から算出し保持する。
status：注文の状態（’new’ / ‘paid’ / ‘canceled’ など）。売上集計の対象を判定する。
ここでの重要ポイントは、「カラムの説明に“なぜそうしているか”を一言入れる」ことです。
それがあるだけで、設計書の価値が一気に上がります。
ER図を“描くとき”の具体的なコツ
「線を引く前に、“親子関係の物語”を言葉で言えるか確認する」
ER図を描くとき、いきなりツールを開くのではなく、まず口頭でこう言えるかを確認します。
「ユーザーは複数の注文を持つ。注文は複数の明細を持つ。商品は複数の明細に登場する。」
これをそのまま図に落とします。
親テーブルを上に、子テーブルを下に置く
例えば、次のようなレイアウトを意識します。
一番上の段：users、products
その下の段：orders
一番下の段：order_items
こうすると、「世界の中心にユーザーと商品がいて、その間を注文がつなぎ、その詳細が明細に落ちる」という構造が視覚的に伝わります。
関係線には“意味のあるラベル”を付ける
ER図ツールによっては、線にラベルを付けられます。
付けられる場合は、単に「1:n」と書くだけでなく、意味を添えると親切です。
例：
users 1 —— n orders（ユーザーは複数の注文を持つ）
orders 1 —— n order_items（注文は複数の明細を持つ）
products 1 —— n order_items（商品は複数の明細に登場する）
この一言があるだけで、「この線は何を表しているのか」が一瞬で分かります。
ER図を“レビューする”視点
自分で描いたER図を見直すとき、次の問いを投げてみてください。
この図だけ見て、「どのテーブルが主役で、どれが明細か」が分かるか。
外部キーの向き（どっちが親か）が直感的に伝わるか。
「このテーブル、役割がかぶってない？」と感じるものはないか。
もし「役割がかぶっているテーブル」があれば、設計を見直すサインです。
ER図は、「設計の違和感をあぶり出す鏡」としても使えます。
SQLレビューの“実務寄りチェックリスト”
「4つの軸で見る：正しさ・性能・安全性・読みやすさ」
SQLレビューをするとき、頭の中にこの4つの軸を置いておくと、抜け漏れが減ります。
1. 正しさ（ロジックが意図通りか）
WHERE 条件は、本当に対象にしたい行だけを選んでいるか。
JOIN 条件は正しいか（JOIN し忘れや、間違ったカラムでJOINしていないか）。
GROUP BY と集計関数の組み合わせは妥当か（意図しない集約になっていないか）。
例：
売上集計で、WHERE status = 'paid' を入れ忘れていないか。
ユーザー別売上で、JOIN users u ON o.user_id = u.id を書き忘れていないか。
2. 性能（無駄に重くないか）
WHERE や JOIN に使っているカラムに、インデックスはあるか。
不要な SELECT * になっていないか（必要なカラムだけ取る方が良い）。
大量データに対して、LIMIT やバッチ処理の工夫が必要ではないか。
例：
管理画面の一覧で、100万件あるテーブルに対して SELECT * FROM orders だけを投げていないか。
日別売上集計で、created_at にインデックスがないのに毎回全件スキャンしていないか。
3. 安全性（壊しやすくないか）
UPDATE / DELETE に WHERE が付いているか（付いていないなら本当に全件対象でいいのか）。
本番で流す前に、必ず SELECT で対象件数を確認できる書き方になっているか。
トランザクションが必要な処理を、バラバラのクエリで実行していないか。
例：DELETE FROM users WHERE id = ? のつもりが、WHERE を書き忘れていないか。
注文処理で、orders INSERT と order_items INSERT と在庫UPDATEを別々にコミットしていないか。
4. 読みやすさ（未来の自分が理解しやすいか）
テーブルやカラムに、意味の分かるエイリアスを付けているか（o, u, p など）。
長いクエリは、適度に改行・インデントされているか。
ビジネスロジック的に重要な条件には、コメントを添えてもよい。
例：-- キャンセルされた注文は売上集計から除外する
というコメントを、WHERE status = ‘paid’ の上に書いておく。
総仕上げとしての“自分のSQLを自分でレビューする”練習
「Day29で書いたクエリを、Day30の目で見直してみる」
ここまで来たあなたに、最後の練習としておすすめしたいのはこれです。
Day29 で考えた、
日別売上集計
商品別売上集計
ユーザー別売上集計
のSQLを、自分で書き直し、それを Day30 のチェックリストでレビューしてみることです。
例えば、日別売上集計のSQLを見て、こう自問します。
正しさ：キャンセルされた注文は除外できているか？
性能：created_at にインデックスがあれば、このクエリは素直に効きそうか？
安全性：これはSELECTだけなので壊す心配はないが、WHERE を変えたときに危険にならないか？
読みやすさ：sale_date / order_count / total_sales というカラム名は、意味が伝わるか？
この「自分で書いて、自分でレビューする」サイクルを回せるようになると、成長スピードが一気に上がります。
Day30 後半のまとめ
アウトプットフェーズの仕上げとして、設計書は「システム概要 → 機能一覧 → テーブル設計 → ER図 → 代表的な処理フロー」という流れで、テーブルごとに“何を表すか”と“なぜそのカラムを持つか（例：unit_price は注文時点の価格を保持するため）”を言葉で残し、ER図は users・products を上段、orders を中段、order_items を下段に配置して親子関係を視覚化し、「ユーザーは複数の注文を持つ」など意味のあるラベル付きの線で関係を表すことで、構造を一瞬で伝えられる図にする。
SQLレビューでは、「正しさ（WHERE・JOIN・GROUP BYが意図通りか）」「性能（インデックスを活かせるか、無駄な全件スキャンをしていないか）」「安全性（UPDATE/DELETEの誤爆を防げているか、トランザクション境界は妥当か）」「読みやすさ（エイリアス・インデント・必要ならコメント）」の4軸で、自分や他人のSQLをチェックし、Day29で書いた集計クエリなどをこの目線で見直すことで、「動くSQL」から「説明できて、安心して本番に流せるSQL」へとレベルアップした状態で、30日間のMySQL学習を締めくくる。
