はじめに
とある企業の二次面接（エンジニア面接）にて、技術課題として ER図の作成 に取り組む機会がありました。
この課題は「正解を出す」ことよりも、
- 何を考えて設計したのか
- 間違いに気づいたあと、どう改善しようとしたのか
- どんな情報を参考にして取り組んだのか
といった 思考プロセスそのもの を見たいという意図で用意されたものだったそうです。
本記事では、人生で初めて本格的にER図を書いたときの試行錯誤や学びをまとめます。
課題内容
課題は 在庫管理システムを想定したデータベース設計 でした。
ER図の作成自体も明確に求められていました。
最初に課題のPDFを見たときの正直な感想はこれです。
「なんだこれ…こんな複雑なの作れるかな…」
不安しかなかったのを覚えています。
どうやって書き始めたか
いきなりテーブル定義をするのではなく、まず以下のような流れを考えました。
- 業務フローの洗い出し
（入荷 → 保管 → 出庫 など）
そこから少しずつエンティティを定義していきました。
ただ、正直に言うとこの段階で完全に詰まりました。
- どこまでテーブルを分けるべきか分からない
- どんなテーブルが必要なのか分からない
- 属性の切り方が分からない
- カラム数の正解が分からない
- 階層構造ってどう設計するんだ…？
「要件に対して、どうアプローチするのが正解なのか」が全く見えず、かなりしんどかったです（笑）
詰まったときにやったこと
完全に迷子になったので、以下の記事を読み漁りました。
- Qiita 記事（ER図の書き方・設計の考え方）
- 企業の採用ブログ系の記事
ある程度の流れや基本的な書き方は、これらの記事で理解できました。
それでも限界がきたので、最終的には Gemini（生成AI） に相談しました。
やったことは以下の通りです。
- 課題PDFの内容
- 自分が現在どこまでできているか
- どんな点で詰まっているか
これらをかなり細かく伝えた上で、
- エンティティ設計の考え方
- 正規化の方向性
についてアシストしてもらいました。
「自分の頭で考える」＋「AIを補助輪として使う」
このバランスがかなり良かったと思っています。
ER図を書き終えたときの感想
一通り完成はしましたが、正直な感想はこれです。
全然足りないし、まだまだ甘い。
実際に振り返ってみると、いくつも問題点がありました。
気づいた問題点
-
JSON形式のカラムを安易に作ってしまった
→ 後々受け取り側で問題が起きやすい -
将来変更される可能性が高い属性を1つのテーブルにまとめすぎていた
→ 本来は別エンティティに分けるべきだった -
「削除」の扱いを軽く考えすぎていた
is_deleteddeleted_at
これらを雑に
inventoryに持たせてしまい、
誤操作やバグが起きたときのことを想像できていなかった
本来は、
- 削除権限を持つユーザーの管理
- 削除ログ専用のエンティティ
こういった設計も必要だったと思います。
この経験で一番学んだこと
一番大きかった学びはこれです。
「設計は、常に変化することを前提に考えなければいけない」
今までは「とりあえず動くものを作る」意識が強かったですが、
- アンチパターンを意識する
- 将来の仕様変更を前提に考える
- 障害やデータ不整合を想像する
こういった視点の重要性に気づくことができました。
ER図は いい意味で“出戻り”を防いでくれる設計図 であり、
だからこそ設計の質が本当に大事なんだと実感しました。
これから読む予定の本
今回の経験をきっかけに、以下の本を購入しました。
-
『ゼロからはじめるデータベース操作（第2版）』
-
『SQLアンチパターン』
理由はシンプルで、
- メンターの方におすすめしてもらった
- DB設計そのものに興味を持った
- バックエンドエンジニアとしてやっていく上で必要だと感じた
からです。
まだ読み始めたばかりですが、
この経験を無駄にしないように、設計力をしっかり伸ばしていきたいと思っています。
おわりに
今回の技術課題はめちゃくちゃ大変でしたが、
それ以上に学びが大きい経験でした。
もしこれからER図を書く人がいたら伝えたいのは一つだけです。
完璧じゃなくていいから、とにかく一度最後まで書いてみる。
そこから見える景色が全く変わります。