Issue #4 から始まった管理者の注文編集まわりの検討は、キャンセル、後工程済み注文の変更制御、注文の作り直し、入金済みキャンセルの扱いへ広がった。
ここで重要なことは、遠回りをしないで、最終的に管理者が実運用で迷わず使える高品質なUIを最短距離で実装することである。
そのため、このドキュメントでは、#4 / #11 / #12 / #14 / #15 を横断して、最終的にどの状態を目指すのか、何を確認し、何を実装し、どこで完了と判断するのかを明確にする。
#15 の実作業では、Issue 本文だけでなくこのドキュメントの統合UX方針を正とする。
つまり #15 は、管理者向け注文作成画面だけの使い勝手確認ではなく、注文編集画面を起点にした以下の一連の導線を対象にする。
- 宛先変更
- 後工程済み注文の変更不可理由表示
- キャンセル
- キャンセルして作り直す
- 作り直し後の追跡
Issue 本文が「注文作成・作り直し画面」を中心に読める場合は、本文側もこの統合UX方針に合わせて更新する。
管理者が注文編集画面を起点に、注文の状態に応じて次の操作を迷わず実行できる。
- 宛先変更できる注文では、そのまま宛先を変更できる
- 宛先変更してはいけない注文では、変更できない理由と次に取るべき操作が分かる
- キャンセルが必要な注文では、箱・袋・引当・在庫・伝票・入金の状態を確認したうえでキャンセルできる
- 内容や宛先を変えて継続したい場合は、キャンセル後に新しい注文を作り直せる
- 作り直し時に、元注文から何が引き継がれ、何を選び直す必要があるか分かる
- 入金済み注文をキャンセルした場合、返金・繰越・寄付の扱いが記録され、新注文の入金状態とは混ざらない
- 処理後に、元注文・新注文・入金・在庫・箱の状態を管理者が追える
言い換えると、管理者が内部データ構造を理解していなくても、画面の案内に従えば整合性を壊さず処理を完了できる状態を目指す。
未引当の注文だけ、管理者が注文編集画面で宛先を直接変更できるようにする。
後工程に入った注文の宛先変更は、箱詰め・送料・伝票・同梱注文への影響があるため、直接変更ではなくキャンセルして作り直す運用へ寄せる。
どんな状態の注文でも、管理者がキャンセル可否と必要な確認事項を理解できるようにする。
実行可能な場合は、箱から袋を外す、引当を解除する、在庫へ戻す、空箱を削除する、入金済みなら返金・繰越・寄付を記録する、という処理を安全な順序で行う。
引当・袋詰め・箱詰め済みの注文について、数量や商品変更によって在庫・袋・箱との整合性が壊れないように制御する。
変更してよい状態と、キャンセルして作り直すべき状態を画面上で分ける。
管理者が新規注文を作成できるようにする。
また、キャンセル済み注文から購入者・商品明細・注文時単価を引き継ぎ、新しい宛先や内容で注文を作り直せるようにする。新注文は UNPAID とし、元注文とは recreated_from で関連付ける。
#4 / #11 / #12 / #14 で作った機能を、管理者の実際の作業導線としてつなげて確認する。
単なる見た目の調整ではなく、管理者が注文状態を判断し、次の操作を選び、処理完了まで迷わず進めるかを確認し、必要な最小改善を行う。
なお #15 に入る前提として、#14 は「管理者向け注文作成と作り直しの機能土台」として完了扱いにする。#14 が未クローズの場合は、#15 の実作業に入る前に #14 をクローズするか、少なくとも #14 側に「統合UX確認は #15 で扱う」とコメントして役割を分ける。
新しい不便や改善案が見つかったときは、すぐに別Issue化したり、逆に握りつぶしたりせず、次の基準で判断する。
- 管理者が誤操作しやすく、データ整合性を壊す可能性がある
- 管理者が次に何をすればよいか分からず、業務が止まる
- キャンセル、作り直し、宛先変更の完了状態が画面から判断できない
- 元注文と新注文、または入金状態の関係を誤解しやすい
- 既存設計を大きく変えず、画面表示や導線の追加で解決できる
- あると便利だが、なくても手順は成立する
- 管理者以外の画面改善である
- 会計、請求、繰越残高など #13 の責務に踏み込む
- 箱詰め、引当、発送ラベルの業務設計を作り替える
- 注文作成画面の全面刷新や大規模なウィザード化が必要になる
- #15 の小改善では収まらない業務仕様が新たに見つかった
- 複数画面・複数モデルにまたがる新しい機能が必要
- 会計上の判断や運用ルールの追加確認が必要
- 顧客向け画面や本番運用フロー全体に影響する
確認すること:
- 注文編集画面で宛先を直接変更できる
- 変更できる理由が状態と矛盾していない
- 保存後に新しい宛先が反映される
確認すること:
- 直接宛先変更できないことが分かる
- なぜ変更できないかが表示される
- 必要ならキャンセルして作り直す導線へ進める
確認すること:
- キャンセル前に、注文・袋・箱・伝票・入金の確認項目が見える
- 実行可能な状態ではキャンセルできる
- 実行不可の状態では、理由と次の対応が分かる
確認すること:
- その注文の商品がどの箱に入っているか分かる
- キャンセルすると、その注文分の商品だけ箱から外れることが分かる
- 残った箱は送料・発送準備の再確認が必要であることが分かる
確認すること:
- 未キャンセルの注文から直接新注文を作れず、必ずキャンセル処理を通る
- キャンセル成功後、作り直し画面へ遷移する
- 元注文番号、購入者、引き継がれた商品明細、注文時単価が分かる
- 宛先や内容は新しく選び直す必要があることが分かる
- 新注文は
UNPAID で作成されることが分かる
確認すること:
- 元注文の入金について、返金・繰越・寄付のいずれかを記録できる
- 新注文には入金状態が引き継がれない
- 管理者が、元注文のお金の処理と新注文の支払いを混同しない
- 画面上で「ここでは元注文のお金の扱いを記録するだけで、繰越残高の次回支払いへの自動充当は #13 の範囲である」と誤解なく分かる
確認すること:
- 新注文から元注文を辿れる
- 元注文から新注文を辿れる
- キャンセル済み元注文と新注文の状態がそれぞれ分かる
最低ライン:
- 新注文側には、作り直し元注文へのリンクを表示する
- 元注文側には、作り直し後の新注文へのリンクを表示する
- 一覧検索だけで関係を確認できる状態は、暫定確認としては許容できるが、#15 の完了条件としては不足とする
実画面確認の結果にもよるが、現時点で優先度が高いのは以下である。
- 注文編集画面に、現在の注文状態と可能な操作をまとめて表示する
- 作り直し画面上部に、元注文・引き継ぎ済み項目・選び直し項目を表示する
- 入金済み元注文から作り直す場合、新注文は未入金であることを明示する
- 注文一覧・編集画面の
recreated_from 表示をリンク化し、元注文を辿りやすくする
- 元注文側からも、作り直し後の新注文を確認できる表示を追加する
- 入力エラー時に、選択済みの購入者・宛先・明細をできるだけ保持する
以下は、使いやすさのために気になっても #15 では原則扱わない。
- 顧客向け注文画面の改善
- 繰越残高の自動充当
- 請求書、入金消込、会計処理の本格対応
- 箱詰めアルゴリズムの変更
- 発送ラベルの取消・再発行フローの自動化
- 注文作成画面の全面的なウィザード化
- 現場確認で出た別業務の要望の積み増し
#15 の完了判断に使うため、実画面確認の結果は Issue #15 のコメントにチェックリストとして残す。
確認コメントには、少なくとも以下を含める。
- 確認日時
- 確認環境
- 確認したデータ条件
- 7ユースケースごとの OK / NG / 要改善
- 見つかった迷いやすい点
- すぐ対応する改善
- 後回しにする改善
- 別Issue化を検討する課題
スクリーンショットは必須ではないが、表示文言や導線の判断に迷う箇所は添付またはコメントで具体的に残す。
Issue #15 には、実装前に確認用チェックリストコメントを1本作成し、以後の確認結果はその形式に沿って追記する。
#15 は、以下を満たしたら完了と判断する。
- 管理者が注文編集画面から、注文の状態に応じて可能な操作と不可理由を理解できる
- 宛先変更、キャンセル、作り直しのどれを選ぶべきか、画面上の導線で判断できる
- キャンセル時に、箱・袋・引当・在庫・伝票・入金の確認事項が見える
- 作り直し時に、元注文、引き継ぎ項目、選び直し項目、新注文の未入金扱いが分かる
- 処理後に、元注文・新注文・入金・在庫・箱の状態を管理者が追える
- 新注文から元注文、元注文から新注文の両方向を画面上のリンクで辿れる
- 一覧検索だけで元注文・新注文の関係を確認する状態は、#15 の完了条件としては不足とする
- Docker compose 上で関連テストが通っている
- 実画面確認の結果、残課題があれば「今対応するもの」「後回しにするもの」「別Issueにするもの」に整理されている
- Issue #15 に、7ユースケースの実画面確認結果がチェックリスト形式で残っている
- #14 を機能土台として完了扱いにし、必要ならクローズまたは役割分離コメントを残す
- #15 で実画面を使い、上記ユースケースを順番に確認する
- 迷いやすい点を、画面・操作・データ状態のどこで起きているかに分けて整理する
- 最短距離で効くUI改善だけを実装する
- Docker compose 上でテストし、実画面で再確認する
- 残った課題を判断基準に沿って整理する
- 管理者の注文変更・キャンセル・作り直し導線として完了判断する
この進め方により、Issue を単に増やすのではなく、実運用で使える状態へ最短距離で近づける。