編集に確認画面を挟む

典型例

典型パターン：詳細→編集→確認別タブで開く ↗

典型の画面遷移

GET    /customers              一覧
GET    /customers/:id          詳細（参照のみ）
GET    /customers/:id/edit     編集画面
POST   /customers/:id/confirm  編集確認画面へ → セッション保存
GET    /customers/:id/confirm  編集確認画面   ← セッションから表示
POST   /customers/:id/back     修正する       → 編集画面へ戻る
PUT    /customers/:id          更新実行       → DB保存

利用者の視点から

自分の入力を疑わされる - 確認画面は「本当にいいですか？」と問いかける。正しく入力したはずなのに、不安にさせられる
操作が終わるまで拘束される - 保存かキャンセルをするまで、別の顧客を見たり、他の作業に移れない
小さな修正にも手間がかかる - 電話番号を1桁直したいだけなのに、編集→確認→完了と進まないといけない
確認画面はたいてい読まれない - 内容を確認せず「OK」を押す傾向があり、ミス防止効果は限定的

開発・運用の視点から

確認画面のためだけにセッション管理が必要 - 即座にDBに保存すれば不要。セッション切れのエッジケースも消える
単純な更新なのにルートが7つある - ロジックが7箇所に散らばり、変更時にどこを直せばいいかわからなくなる
ブラウザの「戻る」を特別扱いしている - Webの自然な動きに逆らうと、必ず複雑になる
テストが多いのは設計の問題 - 画面が多いからテストが多い。画面を減らせばテストも減る

再設計

適用する原則: 編集はその場で行う、確認画面は最低限にする

再設計パターン：詳細画面内編集別タブで開く ↗

再設計の画面遷移

GET    /customers              一覧
GET    /customers/:id          詳細（編集モード含む）
PUT    /customers/:id          更新 → 確認モード表示後、DB保存

設計のポイント

詳細画面内に編集モードを持つ（画面遷移しない）
確認は「画面」ではなく「操作の一部」（モーダルやインライン確認）
セッション不要、常にDB保存

比較

画面遷移の比較

観点	典型	再設計
画面数	4画面	2画面
ルート数	7	3
編集	別画面	詳細画面内のモード
確認	別画面	操作の一部
保存	セッション + DB	DB のみ
テストケース	多い（7ルート × 状態）	少ない（3ルート × 状態）
起きやすい不具合	セッション切れ、戻るボタン問題	構造的に発生しない

改修に向けて

再設計には2つの変更がある。一度にやる必要はない。

変更	内容	効果
1	確認画面を削除	セッション不要、テスト減
2	編集画面を詳細に統合	画面遷移が減る

変更1だけでも効果がある。変更2は後からでもできる。

変更1: 確認画面を削除する

やること

/confirm ルートを削除する
編集画面から直接 PUT でDB保存する
確認が必要なら、保存ボタン押下時にモーダルで確認する

効果

セッション管理が不要になる
ルートが減り、テストケースが減る
「セッション切れ」「戻るボタン問題」が構造的に消える

懸念への対応

懸念	対応
入力ミスが心配	入力時バリデーションで対応する
監査対応が必要	操作ログで代替可能か確認する
取り消したい	必要になったら検討する（下記参照）

変更2: 編集画面を詳細に統合する

やること

/edit ルートを削除する
詳細画面内に「編集モード」を持たせる
表示と編集を同一URLで切り替える

効果

画面遷移がさらに減る
「詳細を見ながら編集」ができる
URLがシンプルになる（/customers/:id だけで完結）

実装パターン

パターン	説明
インライン編集	各フィールドをクリックで編集可能にする
モード切り替え	「編集」ボタンで画面全体を編集モードにする
常時編集可能	最初から全フィールドが編集可能（自動保存と組み合わせる）

どのパターンを選ぶかは、データの性質と編集頻度による。

なお、変更2は変更1より実装コストが高くなる場合がある。フロントエンドの状態管理が複雑になるため、フレームワークの選定やコンポーネント設計に注意が必要。

進め方

自社プロダクトの場合

小さく試す: ステージング環境や一部機能で試す
味方を作る: 効果を実感した人を増やす
横展開する: 成功事例をもとに他の機能に適用

「問題が起きたら戻す」前提ではなく、「問題が起きない範囲で試す」形にする。

受託開発の場合

懸念を先に聞く: 「確認画面についてどうお考えですか？」
選択肢を示す: 顧客が判断できる材料を提供する
推奨を添える: 「弊社としてはB案を推奨します。理由は〜」

いきなり「こうします」ではなく、相手の立場を理解してから提案する。

顧客が従来の設計を求めた場合は、理由を確認する。理由によっては従来の設計を採用する。

提案文書の例

受託開発向け: 顧客への提案書

# 編集機能の画面設計について

## 背景

現在検討中の編集機能について、画面設計の選択肢をご説明します。

## 選択肢

| 項目 | A案: 従来型 | B案: 統合型 |
|------|-------------|-------------|
| 画面構成 | 詳細→編集→確認→完了 | 詳細（編集モード内蔵） |
| 画面数 | 4画面 | 2画面 |
| 開発工数 | 大 | 小 |
| テスト工数 | 大（画面遷移のテストが多い） | 小 |
| 運用 | セッション管理が必要 | シンプル |

## 弊社の推奨

**B案を推奨します。**

理由:
- 開発・テスト工数が削減できる
- セッション切れによる入力消失が発生しない
- ユーザーの操作ステップが減り、業務効率が向上する

入力ミス対策については、確認画面ではなく入力時バリデーションで対応します。

## ご確認事項

以下の点についてご意見をお聞かせください。

- 確認画面が必要な業務上の理由はありますか？
- 監査や内部統制の観点で必要な記録はありますか？
- 現行システムとの操作性の統一は必要ですか？

ご懸念があれば、対応策を検討します。

自社プロダクト向け: 社内検討資料

# 編集画面の改善提案

## 現状の課題

顧客編集機能で以下の課題が発生している。

- 編集完了まで4画面遷移が必要（詳細→編集→確認→完了）
- セッション切れで入力が消えるという問い合わせが月に数件発生
- 確認画面のためだけにセッション管理が必要

## 提案

確認画面を削除し、詳細画面内で編集を完結させる。

| 項目 | 現状 | 改善後 |
|------|------|--------|
| 画面数 | 4 | 2 |
| ルート数 | 7 | 3 |
| テストケース | 約24件 | 約9件 |

## 進め方

1. ステージング環境で動作確認（1週間）
2. 社内ユーザーに限定公開（2週間）
3. 問題なければ全体公開

## リスクと対策

| リスク | 対策 |
|--------|------|
| ユーザーが戸惑う | 変更前に告知、ヘルプを更新 |
| 不具合が出る | 限定公開で検証、切り戻し手順を準備 |

## 確認したいこと

- この方針で進めてよいか
- 限定公開の対象ユーザー
- 公開時期の制約

補足: 同時編集について

「即DB保存」にすると、同時編集時は後勝ちになる。

状況	対応
同時編集がほぼ起きない	後勝ちで問題ない
たまに起きる	楽観的ロックを入れる
頻繁に起きる	リアルタイム共同編集を検討（別の設計）

多くの業務システムでは「後勝ち」か「楽観的ロック」で十分。

補足: 取り消し機能について

「確認画面がないと不安」という懸念には、取り消し機能を提案できる。

ただし、最初から作り込む必要はない。必要になってから検討する。

パターン	複雑さ	適用場面
論理削除 + 時限復元	低	削除の取り消し
履歴テーブル	中	更新前の値に戻したい
Event Sourcing	高	複数データの整合性が必要

まずは「論理削除 + 時限復元」で十分なケースがほとんど。