ステータス管理とテーブル分割

なぜ「ステータス管理」が業務システムの肝なのか

業務システムでの不具合や追加開発の8割は、ステータス設計のミスから生まれる。「未対応 / 対応中 / 完了」のような単純な分類で済むケースは少なく、現場では「保留」「差戻し」「再依頼」など複数の差戻しパターンが並走する。最初に状態を正しく洗い出せるかどうかで、システムの寿命が決まる。

テーブル分割の原則

1つのテーブルに混ぜてはいけないものを切り出すことが、テーブル設計の本質。

• ─履歴 vs 最新値 — 変化を残すべきデータと、最新だけ持てばよいデータ
• ─マスタ vs トランザクション — 滅多に変わらないデータと、毎日積み上がるデータ
• ─状態 vs 属性 — 時間と共に変わる「状態」と、原則変わらない「属性」
• ─1対1 vs 1対多 — 別テーブルに分けないと正規化が壊れる関係

状態遷移を「業務フロー」と揃える

システム設計者だけで状態遷移を決めると、現場の運用と食い違って炎上する。業務フロー上の「次に何が起きるか」を、状態遷移としてそのまま落とすのが鉄則。

壊れにくいスキーマの書き方

業務システムは、要件追加・運用変更で必ず後から手が入る。最初から「将来増える列」「将来増える状態」を想定した設計にしておくと、追加開発のコストが大きく下がる。

• ─状態列は文字列ではなく enum・コードマスタで管理
• ─「その他」「保留」など曖昧な状態は明示的に分岐させる
• ─削除フラグは active/inactive など意味の通る形に
• ─履歴テーブルは最初から分ける（後で分けるのは大変）