保存ボタンが複数ある

典型例

典型パターン：下書き保存と保存が分離別タブで開く ↗

典型の画面遷移

GET    /petitions                  稟議一覧
GET    /petitions/:id              稟議詳細（編集モード含む）
PUT    /petitions/:id/draft        下書き保存（status = 下書き）
PUT    /petitions/:id/confirm      確定保存（status = 確定）
POST   /petitions/:id/submit       申請

典型のテーブル構造

利用者の視点から

ボタンを間違えると意図しない状態になる - 下書きのつもりで「確定保存」を押すと、そのまま申請に進めてしまう状態になる
状態を変えるために編集モードに入る必要がある - 内容を変えずに「下書き→確定」にしたいだけなのに、編集画面を開かないといけない
2つのボタンの違いがわかりにくい - 「下書き保存」と「確定保存」の違いは何か、どちらを押せばいいのか迷う

開発・運用の視点から

PUTエンドポイントが2つ必要 - 「保存」という同じ操作なのに、状態によってエンドポイントが分かれる
保存と状態変更が密結合している - 状態だけ変えたい場合でも保存処理全体が走る
テストケースが増える - 「下書き保存」「確定保存」それぞれの正常系・異常系が必要

再設計

適用する原則: 状態と操作を分離する

再設計パターン：保存と状態変更を分離別タブで開く ↗

再設計の画面遷移

GET    /petitions               稟議一覧
GET    /petitions/:id           稟議詳細（編集モード含む）
PUT    /petitions/:id           更新（状態は変えない）
PATCH  /petitions/:id/status    状態変更（下書き ↔ 確定）
POST   /petitions/:id/submit    申請

再設計のテーブル構造

設計のポイント

保存ボタンは1つだけ
「下書き/確定」は状態として稟議詳細で切り替え可能（ステータスバッジをクリック）
保存と状態変更を分離する

比較

画面遷移の比較

観点	典型	再設計
保存ボタン	2つ（下書き保存/確定保存）	1つ（保存）
状態切替	編集モードで保存が必要	ステータスバッジから直接
PUT	2つ（/draft, /confirm）	1つ
status	保存操作に依存	状態として独立
テストケース	多い（2つの保存 × 状態遷移）	少ない（保存と状態変更が独立）
起きやすい不具合	ボタン押し間違い、状態の不整合	構造的に発生しない

改修に向けて

この再設計は1つの変更で実現できる。

変更	内容	効果
1	保存と状態変更を分離	ボタン削減、操作が明確に

やること

「下書き保存」「確定保存」を1つの「保存」ボタンに統合する
状態変更は詳細画面のステータスバッジから行えるようにする
/draft /confirm エンドポイントを /status に統合する

効果

保存ボタンの押し間違いがなくなる
内容変更なしで状態だけ変えられる
エンドポイントが減り、テストケースが減る

進め方

自社プロダクトの場合

影響範囲を確認: 下書き保存/確定保存を呼び出している箇所を洗い出す
小さく試す: 1つの申請種別だけで試す
横展開する: 成功事例をもとに他の申請種別に適用

受託開発の場合

現状の操作を確認: 利用者が2つのボタンをどう使い分けているか聞く
選択肢を示す: 統合案と現状維持の比較を提示
推奨を添える: 「保存ボタンを1つにすることで操作ミスが減ります」

補足: 状態遷移の制御

「下書き→確定」は自由に切り替えられるが、「確定→申請済み」は一方向にする。

遷移	許可	備考
下書き → 確定	可	いつでも切り替え可能
確定 → 下書き	可	申請前なら戻せる
確定 → 申請済み	可	申請ボタンで遷移
申請済み → 確定	不可	取り下げは別操作

状態遷移のルールはビジネスロジック層で制御する。UIの問題ではない。