ステータス統合パターン
例：注文・受注管理システム
注文を管理し、入金・出荷などの状況を追跡する。
適用する原則: 状態と操作を分離する
- 受注の入金状況を管理したい
- 受注の出荷状況を管理したい
- 「未入金の受注」「未出荷の受注」をそれぞれ抽出したい
典型パターン：統合ステータス
別タブで開く ↗
受注ステータス（入金と出荷を1つに統合）:受付 → 入金待ち → 入金済 → 出荷準備 → 出荷済 → 完了- 表現できない状態がある: 「入金済みだけど未出荷」「未入金だけど出荷済（先出し）」
- フィルタできない: 「未入金の受注だけ」「未出荷の受注だけ」が抽出しにくい
- 遷移が複雑: 入金と出荷の順序が固定されてしまう
- マッピングが必要: 2つの状態を1つに変換するロジックが必要
再設計パターン：独立したステータス
別タブで開く ↗
入金ステータス: 未入金 / 入金済 / 返金済出荷ステータス: 未出荷 / 出荷済 / 配達完了設計のポイント
Section titled “設計のポイント”- 独立した軸: 入金と出荷は別々のステータスとして管理
- 組み合わせ自由: 入金と出荷の順序に制約がない
- 個別フィルタ: 「未入金」「未出荷」でそれぞれ絞り込める
- 状態が明確: 現在の状況が一目で分かる
| 観点 | 典型（統合） | 再設計（独立） |
|---|---|---|
| ステータス | 1つに統合（6状態） | 2軸で独立（各3状態） |
| 表現できる状態 | 6通り | 9通り（3×3） |
| フィルタ | 複数ステータスをOR条件 | 軸ごとに指定 |
| 遷移の自由度 | 順序固定 | 独立して遷移 |
| 実装 | マッピングロジック必要 | シンプル |
統合ステータスを使いたくなる理由
- 一覧のカラム数を減らしたい
- 「全体の進捗」を1つで見せたい
- 既存システムがそうなっている
独立ステータスにすべき判断基準
- 2つの状態が「独立して変化する」なら分離する
- 「Aが完了しないとBに進めない」なら統合でもよい
- フィルタや集計で「軸ごとに見たい」なら分離する
よくある統合ステータスの例
- 受注: 入金 × 出荷
- 見積: 社内承認 × 顧客送付 × 受注可否
- 申請: 申請 × 承認 × 実施
- プロジェクト: 承認 × 進捗 × 請求