ER図を描いて気づいた拡張性の大切さ

最近、とあるアプリで「お気に入り」機能を設計することがありました。
ユーザーが店舗をお気に入りとして保存できる仕組みを考え、まずはシンプルなER図（エンティティ・リレーションシップ図）を描きました。

そもそもER図ってなに？

ER図とは Entity Relationship Diagram（エンティティ・リレーションシップ図） の略で、
「どんなデータを管理するか」「それぞれがどうつながっているか」を図で表したものです。

たとえば、

• ユーザー（USER）
• 店舗（STORE）
• お気に入りリスト（FAVORITE_LIST）
• お気に入りリストに入っている店舗（FAVORITE_LIST_ITEM）

といった単位（＝エンティティ）を四角で表し、矢印でつなげることで、関係性を整理します。

コードを書く前にこの図を描くと、データの全体像が理解しやすくなり、後からの修正もしやすくなります。

そもそも「拡張性」ってなに？

拡張性（スケーラビリティ） とは、システムや設計を「後から大きくしたり、新しい機能を追加したりしても破綻しない」性質のことです。

簡単な例で言うと：

• 拡張性が低い設計

  • 最初は「ユーザーがお気に入り店舗を1つだけ登録できる」仕組みにした。
  • 後から「お気に入りを複数持ちたい」と言われたら、データベースを作り直しになる。

• 拡張性が高い設計

  • 最初から「お気に入りリスト」という入れ物を用意しておく。
  • 後から「複数リストを作りたい」と言われても、構造を変えずに対応できる。

拡張性を考えないリスク

上図のER図をエンジニアの先輩に見せた時に、

「これ、お気に入り登録複数できるようにしたいっていう追加要求が来たら詰む設計やな」
「大体こういうの後々くるから拡張性持たせとき」

と言われました。

下図は実際に使用しているER図とは異なりますが、拡張性を持たせたものになります

本当に追加要求がきた

今回、「お気に入りを複数登録できるようにしてほしい」 という追加要求が本当に来ました。

もし当初の設計のまま進めていたら、この要望を実現するには大幅な設計変更が必要になっていたはずです。

リスクを整理すると：

• 開発コストが倍増する
  データベースの構造を変更し、既存のデータ移行やコード修正が必要になる。

• 不具合が発生しやすい
  設計を途中で変えると、思わぬバグや不整合が発生する。

• 納期が遅れる / 信頼を失う
  後からの要望に対応できず、開発チームや顧客に迷惑がかかる。

まとめ

• ER図はデータのつながりを整理する地図
• 拡張性とは、後からの変更に強い設計をすること
• 拡張性を考えないと、後で大きなコスト・リスクが発生する

データ設計における「拡張性の重要さ」を知れました。
これからも新しい機能を考えるときは、「今は要らないかもしれないけど、将来どうなるか」
を頭に置きながら設計していきたいと思います。