現場でも「最初のDB設計が足りなかった」「要件が増えて構造が限界」──再設計・再構築は日常茶飯事です。
「システムを作っていたら、途中でSQLが複雑になりすぎてよく分からなくなった…」
「処理をPHPで無理やり書いているけど、これでいいのかな？」
そんな経験はありませんか？
実はこれ、現場でもよくあることなんです。
むしろ、データベースを扱うプロでも「最初の設計を途中で見直す」ことは普通にあります。
この記事では、データベース設計を見直すタイミングや、再設計が発生する理由、そして現場のエンジニアがどのように設計を進化させていくのかを解説します。
1. よくある現場の流れ
実際のプロジェクトでは、多くがこのような経緯をたどります：
- 初期フェーズ(プロジェクトの立ち上げ期)
- 機能要件が固まっていない
- 「まず動くものを作ろう」とシンプルな設計でスタート
- スピード重視（プロトタイプ・PoC）
- 運用・拡張フェーズ
- 新しい機能（キャンセル機能、祝日設定、権限分岐など）が追加される
- 「このテーブルに列を足せば動く」と場当たり的対応が増える
- JOINが複雑化、ロジックが肥大化
- 限界フェーズ
- バグ修正や新機能追加のたびに影響範囲が広くなる
- 同じSQLを直す箇所が複数存在
- 「もう作り直した方が早い」と判断
実務でも、この3番目の段階で「設計の作り直し（リファクタリング or 再構築）」が発生します。
リファクタリングとは？
リファクタリングとは、「動作を変えずに、コードや設計の中身を整理・改善すること」 を指します。つまり、結果（出力や機能）はそのままに、中の書き方・構造をきれいにする作業です。
- コードを読みやすくする → 他の人が見ても理解しやすい構造にする。
- 保守・修正をしやすくする → バグを直したり機能を追加する時に混乱しない。
- 重複や無駄を減らす → 同じ処理をまとめて関数化したり、ロジックを整理する。
- バグを減らす → 構造が明確になることで、エラーの原因を特定しやすくなる。
データベース設計のリファクタリング
プログラムコードだけでなく、データベースにもリファクタリングがあります。
- 重複していたカラムを整理して別テーブルに分ける
- 不要になったテーブルを削除する
- JOINのための中間テーブルを追加する
- カラム名を意味のある名前に変更する
こうした作業も、「動作を変えずに構造を整理する」＝リファクタリングの一種です。
再設計との違い
| 用語 | 内容 | 規模 |
|---|---|---|
| リファクタリング | 構造の整理・改善（動作は変えない） | 小〜中規模 |
| 再設計（リデザイン） | テーブルや仕様そのものを変える（機能変更あり） | 中〜大規模 |
つまり、リファクタリングは「片付け」、再設計は「リフォーム」 のようなイメージです。
2. 作り直しが発生する典型的な理由
| 原因 | 内容 | 対応策 |
|---|---|---|
| 要件の変化 | 例：当初「個人予約」だけ → 「団体予約」に対応する必要が出た | エンティティ分割・リレーション再定義 |
| 正規化不足 | 同じデータが複数テーブルに存在して整合性が崩れる | 第2〜3正規化を再確認 |
| 正規化しすぎ | JOINが多くなりすぎて遅い・複雑 | 再デノーマライズ（テーブル統合） |
| 命名・用途が曖昧 | data1, data2 のようなテーブルやカラム名 | 意味のあるスキーマに再設計 |
| 設計段階で考慮不足 | 「祝日・キャンセル・複数店舗」など拡張性不足 | 新しい中間テーブル・補助テーブルを追加 |
3. 「最初の設計をやり直す」ことの価値
再設計は一見コストがかかるように見えますが、結果的に保守コストを大幅に減らします。
| 状況 | 修正時間 | バグ発生リスク |
|---|---|---|
| 設計を放置して継ぎ足し対応 | 1機能あたり3〜5時間 | 高い（影響範囲不明） |
| 設計を見直して再構築 | 初期に10〜20時間 | 低い（整合性が取れる） |
設計を放置して継ぎ足し対応をすると、1機能を直すたびに3〜5時間かかり、影響範囲も読めずバグも発生しやすくなります。
一方で、設計を見直して再構築した場合、初期に10〜20時間かけても、その後の修正リスクは大幅に減ります。
よくあるシステムでは、「日付・時間・ユーザー・ステータス・在庫」が絡む構造では、テーブル設計が整理されていないとすぐに破綻します。
4. 現場での対応パターン
現場では、完全に作り直すケースと、部分的に見直すケースがあります。
| 方法 | 内容 | 向いている状況 |
|---|---|---|
| フルリファクタリング (システム全体の設計や構造を根本から見直すこと) | スキーマ(設計図)を新規設計し、既存データを移行 | データ構造全体が複雑化している場合 |
| 段階的リファクタリング | 祝日やスタッフなど「周辺テーブル」だけ追加・改善 | 既存構造が概ね妥当な場合 |
| ビュー（VIEW）導入 | 複雑なSELECTをDB内にラップ | SQLロジックの整理・再利用性UP |
| 中間テーブル追加 | 多対多関係を正規化 | 機能拡張が原因のとき |
5. 現場エンジニアの共通認識
「最初の設計は仮説。運用してみて見直すのが本番。」
実務では、「最初から完璧な設計」は存在しません。
むしろ、運用中に改善を重ねる前提で設計します。
たとえば、
holidaysテーブルを後から追加reservation_status（キャンセル・変更）を別テーブル化staff_shiftを追加して勤務と予約を分離
こうした追加・分割は「よくある改善」であり、「失敗」ではなく成熟の過程です。
「リライト」「リビルド」「リプレイス」の違い
現場では似た言葉がいくつもありますが、ニュアンスが少しずつ違います。
| 用語 | 意味 | 規模感・特徴 |
|---|---|---|
| リファクタリング | 動作を変えずにコードを整理 | 小〜中規模（既存構造を維持） |
| リライト（rewrite） | コードを書き直す（部分的または全面的） | 中〜大規模（処理ロジックを変更） |
| リビルド（rebuild） | システム全体を再構築 | 大規模（構造・設計レベルで再開発） |
| リプレイス（replace） | 他の技術・システムに置き換える | 技術移行（例：PHP→Laravel、MySQL→PostgreSQL） |
| スクラッチ開発 | ゼロから完全に作り直す | “再設計＋再開発”の最上位 |
現場でよく出る「限界フレーズ」集
- 「これ、リビルド案件だね…」 → コードが限界、再構築決定。
- 「もうスクラッチでやった方が早い。」 → 修正より新規開発が効率的。
- 「この構成、積み木みたいで触れない。」 → 構造が崩壊していて手を出すと壊れる。
- 「いっそ焼き直そう（焼き直し案件）。」 → 設計は残してコードだけ刷新する。
- 「アーキテクチャごと見直しだね。」 → 根本の設計思想（MVCやAPI設計）から変える。
まとめ：設計を「変えられる」ことが強さ
現場でもデータベースの再設計は普通にあります。
該当テーブルがなかった、日付の扱いが複雑になった──そんな理由で見直されることは珍しくありません。
構造を整理すれば、SELECT文もJOINもシンプルになり、ロジックが明快になります。
最初に完璧を目指す必要はありません。
大切なのは、「見直す勇気」と「変化を恐れない姿勢」と「体力」です。
最初の設計は仮説にすぎません。運用して、使って、問題を見つけて、直していく。
このサイクルを繰り返すことが、本当の成長につながります。。。。。(白髪が増えます）