独立した状態を1軸に統合する
典型パターン：統合ステータス
別タブで開く ↗
受注ステータス（入金と出荷を1つに統合）:受付 → 入金待ち → 入金済 → 出荷準備 → 出荷済 → 完了利用者の視点から
Section titled “利用者の視点から”- 実態と合わないステータスを選ばされる - 「入金済みだけど未出荷」「未入金だけど出荷済（先出し）」という状態を表現できない
- 見たいデータにたどり着けない - 「未入金の受注だけ」「未出荷の受注だけ」をフィルタしにくい
- 順序が固定されて柔軟に動けない - 入金より先に出荷したい場合でも、ステータス遷移が固定されている
開発・運用の視点から
Section titled “開発・運用の視点から”- 遷移ルールが複雑になる - 入金と出荷の順序が業務によって異なる場合、例外的な遷移を個別に実装することになる
- マッピングロジックが必要になる - 2つの状態を1つに変換する処理が必要で、バグの温床になる
- テストケースが増える - 本来独立している状態の組み合わせを1軸で表現するため、遷移パターンのテストが複雑化する
- 状態追加時の影響が大きい - 新しい状態（例：部分入金）を追加すると、既存の遷移ルールすべてに影響する
適用する原則: 状態と操作を分離する
再設計パターン：独立したステータス
別タブで開く ↗
入金ステータス: 未入金 / 入金済 / 返金済出荷ステータス: 未出荷 / 出荷済 / 配達完了設計のポイント
Section titled “設計のポイント”- 独立した軸: 入金と出荷は別々のステータスとして管理
- 組み合わせ自由: 入金と出荷の順序に制約がない
- 個別フィルタ: 「未入金」「未出荷」でそれぞれ絞り込める
- 状態が明確: 現在の状況が一目で分かる
| 観点 | 典型（統合） | 再設計（独立） |
|---|---|---|
| ステータス | 1つに統合（6状態） | 2軸で独立（各3状態） |
| 表現できる状態 | 6通り | 9通り（3×3） |
| フィルタ | 複数ステータスをOR条件 | 軸ごとに指定 |
| 遷移の自由度 | 順序固定 | 独立して遷移 |
| 実装 | マッピングロジック必要 | シンプル |
| テストケース | 遷移パターンごとに検証が必要 | 軸ごとに独立してテスト可能 |
| 起きやすい不具合 | 状態不整合、想定外の遷移 | 構造的に発生しにくい |
改修に向けて
Section titled “改修に向けて”再設計には2つの変更がある。一度にやる必要はない。
| 変更 | 内容 | 効果 |
|---|---|---|
| 1 | ステータスを分離する | 状態表現の自由度が上がる |
| 2 | フィルタUIを軸ごとに分ける | 検索が直感的になる |
変更1がメイン。変更2は変更1に伴って自然に実現できることが多い。
変更1: ステータスを分離する
Section titled “変更1: ステータスを分離する”- 統合ステータスカラムを廃止し、入金・出荷それぞれのカラムを追加する
- 既存データを新しいカラムにマイグレーションする
- 各ステータスの更新処理を独立させる
- 状態の組み合わせを自由に表現できる
- マッピングロジックが不要になる
- 状態追加時の影響範囲が限定される
懸念への対応
Section titled “懸念への対応”| 懸念 | 対応 |
|---|---|
| データ移行が不安 | 既存データの統合ステータスから入金・出荷を推測してマイグレーションする |
| 一覧のカラムが増える | 表示項目を選択可能にする、またはアイコンで省スペース化する |
| 既存の帳票に影響 | 帳票側で複合ステータスを表示するロジックを入れる（DBは分離） |
変更2: フィルタUIを軸ごとに分ける
Section titled “変更2: フィルタUIを軸ごとに分ける”- 「ステータス」ドロップダウンを「入金状況」「出荷状況」に分割する
- それぞれ独立してフィルタ条件を指定できるようにする
- 「未入金の受注」「未出荷の受注」を簡単に抽出できる
- 複合条件（未入金かつ未出荷）も直感的に指定できる
自社プロダクトの場合
Section titled “自社プロダクトの場合”- データを先に分離する: まずDBスキーマを変更し、既存データをマイグレーションする
- 表示を変更する: 一覧・詳細画面に両方のステータスを表示する
- フィルタを追加する: 軸ごとのフィルタを追加する
スキーマ変更が先。UIは段階的に対応できる。
受託開発の場合
Section titled “受託開発の場合”- 業務フローを確認する: 入金と出荷の順序に柔軟性が必要か確認する
- 現行データを分析する: 統合ステータスのどの値が入金済み/出荷済みに対応するか整理する
- 移行計画を提示する: データ移行とUI変更のスケジュールを分けて説明する
「ステータスを分けると集計が複雑になるのでは？」という懸念には、「軸ごとに集計できるので、むしろシンプルになります」と説明する。
統合ステータスを使いたくなる理由
- 一覧のカラム数を減らしたい
- 「全体の進捗」を1つで見せたい
- 既存システムがそうなっている
独立ステータスにすべき判断基準
- 2つの状態が「独立して変化する」なら分離する
- 「Aが完了しないとBに進めない」なら統合でもよい
- フィルタや集計で「軸ごとに見たい」なら分離する
よくある統合ステータスの例
- 受注: 入金 × 出荷
- 見積: 社内承認 × 顧客送付 × 受注可否
- 申請: 申請 × 承認 × 実施
- プロジェクト: 承認 × 進捗 × 請求