はじめに

とある企業の二次面接（エンジニア面接）にて、技術課題として ER図の作成 に取り組む機会がありました。
この課題は「正解を出す」ことよりも、

何を考えて設計したのか
間違いに気づいたあと、どう改善しようとしたのか
どんな情報を参考にして取り組んだのか

といった 思考プロセスそのもの を見たいという意図で用意されたものだったそうです。

本記事では、人生で初めて本格的にER図を書いたときの試行錯誤や学びをまとめます。

課題内容

課題は 在庫管理システムを想定したデータベース設計 でした。
ER図の作成自体も明確に求められていました。

最初に課題のPDFを見たときの正直な感想はこれです。

「なんだこれ…こんな複雑なの作れるかな…」

不安しかなかったのを覚えています。

どうやって書き始めたか

いきなりテーブル定義をするのではなく、まず以下のような流れを考えました。

業務フローの洗い出し
（入荷 → 保管 → 出庫など）

そこから少しずつエンティティを定義していきました。

ただ、正直に言うとこの段階で完全に詰まりました。

どこまでテーブルを分けるべきか分からない
どんなテーブルが必要なのか分からない
属性の切り方が分からない
カラム数の正解が分からない
階層構造ってどう設計するんだ…？

「要件に対して、どうアプローチするのが正解なのか」が全く見えず、かなりしんどかったです（笑）

詰まったときにやったこと

完全に迷子になったので、以下の記事を読み漁りました。

Qiita 記事（ER図の書き方・設計の考え方）
企業の採用ブログ系の記事

ある程度の流れや基本的な書き方は、これらの記事で理解できました。

それでも限界がきたので、最終的には Gemini（生成AI） に相談しました。

やったことは以下の通りです。

課題PDFの内容
自分が現在どこまでできているか
どんな点で詰まっているか

これらをかなり細かく伝えた上で、

エンティティ設計の考え方
正規化の方向性

についてアシストしてもらいました。

「自分の頭で考える」＋「AIを補助輪として使う」
このバランスがかなり良かったと思っています。

ER図を書き終えたときの感想

一通り完成はしましたが、正直な感想はこれです。

全然足りないし、まだまだ甘い。

実際に振り返ってみると、いくつも問題点がありました。

気づいた問題点

JSON形式のカラムを安易に作ってしまった
→ 後々受け取り側で問題が起きやすい
将来変更される可能性が高い属性を1つのテーブルにまとめすぎていた
→ 本来は別エンティティに分けるべきだった
「削除」の扱いを軽く考えすぎていた
- is_deleted
- deleted_at
これらを雑に inventory に持たせてしまい、
誤操作やバグが起きたときのことを想像できていなかった

本来は、

削除権限を持つユーザーの管理
削除ログ専用のエンティティ

こういった設計も必要だったと思います。

この経験で一番学んだこと

一番大きかった学びはこれです。

「設計は、常に変化することを前提に考えなければいけない」

今までは「とりあえず動くものを作る」意識が強かったですが、

アンチパターンを意識する
将来の仕様変更を前提に考える
障害やデータ不整合を想像する

こういった視点の重要性に気づくことができました。

ER図は いい意味で“出戻り”を防いでくれる設計図 であり、
だからこそ設計の質が本当に大事なんだと実感しました。

これから読む予定の本

今回の経験をきっかけに、以下の本を購入しました。

『ゼロからはじめるデータベース操作（第2版）』
『SQLアンチパターン』

理由はシンプルで、

メンターの方におすすめしてもらった
DB設計そのものに興味を持った
バックエンドエンジニアとしてやっていく上で必要だと感じた

からです。

まだ読み始めたばかりですが、
この経験を無駄にしないように、設計力をしっかり伸ばしていきたいと思っています。

おわりに

今回の技術課題はめちゃくちゃ大変でしたが、
それ以上に学びが大きい経験でした。

もしこれからER図を書く人がいたら伝えたいのは一つだけです。

完璧じゃなくていいから、とにかく一度最後まで書いてみる。

そこから見える景色が全く変わります。