Day30 前半のゴール
「“頭の中の設計”を、他人と共有できる形に書き出せるようになる」
いよいよ Day30。
ここまでで、MySQL を使って「それなりにちゃんとしたシステム」を作れるところまで来ました。
でも、実務では「動くコード」だけでは足りません。
他の人に伝わる形で設計を残し、SQLをレビューし合い、チームで育てていく必要があります。
前半のゴールはこうです。
設計書とは何を書くものかを、具体的にイメージできる。
ER図が「ただの絵」ではなく、「テーブル間の関係を一瞬で伝える道具」だと理解できる。
SQLレビューで見るべきポイントを、言葉で説明できる。
ここでは、まだツールの使い方ではなく、「何をどう表現するか」という考え方に集中します。
設計書作成とは何か
「“自分の頭の中の前提”を、紙の上に引きずり出す作業」
設計書と聞くと、「なんか堅苦しいWordファイル」を想像するかもしれません。
でも本質はもっとシンプルで、「自分の頭の中の前提を、他人が読める形にすること」です。
設計書には、最低限こんなことが書かれていてほしいです。
このシステムは何をするためのものか（目的・概要）。
どんなテーブルがあって、それぞれ何を表しているか（テーブル一覧と説明）。
テーブル同士がどうつながっているか（ER図とリレーションの説明）。
代表的な処理の流れ（例：注文処理、売上集計のフロー）。
ここで大事なのは、「SQLの細かい文法を書くこと」ではありません。
むしろ、「なぜこういう設計にしたのか」「どんな前提でこのカラムを持たせたのか」を言葉にすることです。
例えば、order_items.unit_price について、設計書にはこう書けます。
「unit_price は、注文時点の商品の価格を保持する。
過去の価格変更の影響を受けず、当時の売上を正しく再現するため。」
この一文があるだけで、後から読む人は「なるほど、だから products.price を参照しないんだな」と理解できます。
設計書は、「未来の自分」と「まだこのシステムを知らない誰か」に向けたラブレターみたいなものです。
雑に書くと、未来の自分が一番困ります。
設計書に最低限書いてほしい構成
「“何を作るか → どう分解したか → どうテーブルに落としたか”の順で」
構成は色々ありますが、初心者がまず押さえておくと良い流れは、次のようなものです。
システム概要
機能一覧
テーブル設計（テーブルごとの説明）
ER図
代表的な処理フロー
システム概要では、「小さなECサイトのバックエンドで、ユーザー管理・商品管理・注文処理・売上集計を行う」といった全体像を書きます。
機能一覧では、「ユーザー登録・ログイン」「商品登録・更新・非公開」「注文作成・ステータス変更」「日別・商品別・ユーザー別売上集計」などを箇条書きで整理します（実際の文書では箇条書きでOKです）。
テーブル設計では、テーブルごとにこういう説明を書きます。
users
システムを利用するユーザーを管理する。
主なカラム：id（主キー）、name、email（ログインID）、password_hash、created_at、updated_at。
orders
ユーザーによる1回の注文を表す。
主なカラム：id、user_id（users.id への外部キー）、total_amount、status、created_at、updated_at。
このとき、「このテーブルは何の“事実”を表しているのか」を一言で言えると、設計が強くなります。
ER図作成とは何か
「“テーブル同士の関係を、一瞬で理解できるようにする図”」
ER図（Entity-Relationship 図）は、テーブル（エンティティ）と、その間の関係（リレーション）を図で表したものです。
例えば、ECの例だと、こんな関係があります。
users 1 —— n orders
orders 1 —— n order_items
products 1 —— n order_items
これを図にすると、
users と orders が線でつながり、「1 対 多」と書かれる。
orders と order_items が線でつながり、「1 対 多」と書かれる。
products と order_items が線でつながり、「1 対 多」と書かれる。
ER図の良さは、「テーブル名と線を見るだけで、全体の構造が一瞬で分かる」ことです。
テーブル定義だけを文字で眺めていると、「どれがどれにぶら下がっているのか」が頭の中で迷子になりがちですが、ER図にすると、「ああ、orders は users にぶら下がっていて、その下に order_items がぶら下がっているんだな」と視覚的に理解できます。
ER図で意識してほしいポイント
「“主役はどれか”“ぶら下がるのはどれか”をはっきりさせる」
ER図を描くときに、特に意識してほしいのは次の2つです。
どのテーブルが“主役”で、どのテーブルが“それにぶら下がる明細”なのか。
外部キーの向き（どのテーブルがどれを参照しているか）。
ECの例で言えば、
users と products は「マスタ的な主役」。
orders は「ユーザーの行動（注文）」を表す“イベント”。
order_items は「注文の中身」という“明細”。
という役割分担です。
ER図上でも、users と products を少し上の方に置き、その下に orders、そのさらに下に order_items を置くと、「世界観」が伝わりやすくなります。
外部キーの向きも大事です。
orders.user_id → users.id
order_items.order_id → orders.id
order_items.product_id → products.id
この矢印の向きが、「どっちが親でどっちが子か」を表します。
ER図は、「親子関係を目で見て確認するためのツール」として使うと、設計のミスに気づきやすくなります。
SQLレビューとは何か
「“動くかどうか”ではなく“設計として健全かどうか”を見る時間」
SQLレビューは、「文法エラーがないかチェックする時間」ではありません。
それはコンパイラや実行時エラーが教えてくれます。
SQLレビューで見るべきなのは、もっと設計寄りのポイントです。
このクエリは、意図した行だけを対象にしているか（WHERE 条件は適切か）。
インデックスを使える書き方になっているか（不要な全件スキャンになっていないか）。
トランザクションの境界は適切か（まとめるべき処理が一緒にコミットされているか）。
削除や更新が「取り返しのつかない操作」になっていないか（誤爆しないか）。
例えば、次のようなSQLがレビューに出てきたとします。
UPDATE orders
SET status = 'canceled'
WHERE created_at < NOW() - INTERVAL 30 DAY;
レビューで考えることは、こうです。
本当に「30日より前の全ての注文」をキャンセルしていいのか。
status が ‘paid’ のものもキャンセルされてしまわないか。
インデックスは張ってあるか（created_at にインデックスがないと全件ロックになる）。
ここで、「WHERE status = ‘new’ AND created_at < …」にした方が安全だね、という話が出てきます。
これが SQLレビューの価値です。
初心者がSQLレビューで特に意識すると良い観点
「“もしこれが本番データだったら”と想像してみる」
最初のうちは、インデックスや実行計画まで完璧に見るのは難しいです。
それでも、初心者でも今日からできるレビューの観点があります。
それは、「もしこれが本番データだったら、自分はこのSQLを安心して流せるか？」と自問することです。
DELETE や UPDATE を書いたときに、「本当にこの WHERE 条件で、消したい／変えたい行だけに当たるか？」と、声に出して説明してみる。
JOIN を書いたときに、「このJOINで、意図しない重複や欠落が起きていないか？」を、簡単な例データで頭の中シミュレーションしてみる。
SQLレビューは、「怖がりであること」がむしろ強みになります。
「これ、ちょっと怖いな」と感じたら、その感覚はだいたい正しいです。
Day30 前半では、「設計書・ER図・SQLレビューは、全部“他人と未来の自分のためにやるもの”なんだ」という視点を持てれば十分です。
後半で、もう少し具体的な設計書の書き方例や、ER図の読み書きのコツ、SQLレビューのチェックポイントを整理していきます。
Day30 前半のまとめ
Day30 のアウトプットフェーズでは、設計書は「システムの目的・機能一覧・テーブルごとの役割・代表的な処理フロー」を言葉で残し、とくに「なぜこのカラムを持たせたのか」「なぜこの設計にしたのか」という“前提”を書き出すことで、未来の自分や他人が迷わないようにする文書だと捉える。
ER図は、users・products・orders・order_items のようなテーブル同士の「1対多」関係や親子関係を一目で伝えるための図であり、「どれが主役でどれがぶら下がるのか」「外部キーがどちらを向いているか」を視覚的に確認する道具として使い、SQLレビューは「文法チェック」ではなく「WHERE 条件は安全か」「インデックスを活かせるか」「トランザクションの境界は妥当か」「本番データに対して流しても怖くないか」を考える時間だと理解することで、コードだけでなく“説明できる設計”まで含めてアウトプットできるエンジニアへの一歩を踏み出す。
