シンプルにできない領域

このガイドの設計方針は、すべてのケースに適用できるわけではありません。

「画面を減らす」「確認画面をなくす」というアプローチが、うまく機能しない領域もあります。

---

CSVインポート

なぜ難しいか

CSVインポートは本質的に「バッチ処理」であり、このガイドが前提とする「インタラクティブなCRUD」とは性質が異なります。

通常のCRUD	CSVインポート
1件ずつ処理	数百〜数万件を一括
即時フィードバック	結果は処理後
簡単にUndoできる	ロールバックが困難
失敗しても影響は1件	失敗すると大量データに影響

確認画面が必要な理由

• 処理対象が多い → 「何が起きるか」の事前確認が重要
• 処理時間が長い → 途中キャンセルが難しい
• 影響が大きい → 「本当に実行していいか」の最終確認

改善できること

完全にシンプルにはできませんが、以下は改善の余地があります。

• エラー修正: ファイル再アップロードではなく、画面上で修正
• 差分表示: 「何件追加/更新されるか」を明確に
• 非同期処理: 「待つ画面」をなくし、完了通知で知らせる
• ロールバック: インポート単位で取り消せる仕組み

根本的な問い

「そもそもCSVインポートが必要か？」を問い直す価値はあります。

• API連携で自動同期できないか
• 一覧画面で直接編集できないか
• 個別登録を楽にすれば一括不要では

---

その他の「シンプルにできない」ケース

法的要件がある場合

• 電子契約の確認画面（法的に必要）
• 金融取引の確認（規制要件）
• 個人情報の同意取得

→ 確認画面を「なくす」のではなく「意味のあるものにする」

不可逆な操作

• データの完全削除
• 外部システムへの送信（取り消し不可）
• 本番環境への反映

→ 確認の「質」を上げる（差分表示、影響範囲の明示）

複雑なワークフロー

• 複数人が関わる承認フロー
• 条件分岐が多い申請プロセス
• 外部システムとの連携

→ 画面数よりも「状態の可視化」に注力

---

このガイドのスタンス

このガイドは「すべての確認画面をなくせ」とは言っていません。

「本当に必要な確認か？」を問い直すことを勧めています。

• 必要な確認は残す
• 不要な確認は減らす
• 確認するなら、意味のある確認にする

その判断は、システムの性質と業務の要件によります。