画面移行の優先順位は「列」ではなく「操作」 — 危ない順に手を入れる

なぜ書いたか

UIレビューだと、つい「列が足りない」「ラベルが違う」のような 見た目の差分 に目が行きます。でも本当に怖いのは、見た目が完璧なのに 削除ボタンが違うテーブルを消している とか、決定ボタンが古いステータスで保存している ような、業務破壊系の差分です。今回は優先順位を変えた話です。

やったこと

レビュー観点を「列より操作を先に見る」順に並べ替えました。

1. 破壊的操作（Destructive Actions）: 削除、決定、確定、取消。元実装と同じテーブル・条件・権限で動くか
2. 業務状態を変える操作: ステータス変更、コピー、クローン
3. 読み取り操作と表示: 検索結果、一覧表示
4. 見た目（列、ラベル、文言）: 最後にチェック

順序が大事です。1〜2で差分があれば、3〜4のレビューに進む前に直します。

なぜ列から見たくなるか

UIレビューを「列・ラベルの差分」から始めたくなるのには理由があって、それは 目に見えるから です。並べて比較できる。一方で操作の差分は、ボタンを押した結果としてSQLやAPIが走って初めて見えます。レビューしにくい。

そのレビューしにくさを補うために、コードを読む観点を先に置く ようにしました。具体的には：

• 元実装の *_Click ハンドラの一覧を抽出
• それぞれの呼び出し先（モジュール、SQL、関数）まで辿る
• 移行先の同名メソッドが、同じテーブル・同じ条件で動いているか比較する

わかったこと

• AIに画面を作らせると、見た目の再現は得意、操作の再現は苦手。優先順位を変えないと、見た目が完璧で業務が崩れる完成品ができます
• 「破壊的操作の同等性」をReviewerの固定観点に入れると、UIレビューだけで止まる事故が減ります
• 列の差分は 後で足せる。操作の差分は 本番でデータが壊れるまで気づけない

業務同等性の話（裏では違うテーブルを消していた話） と合わせて読んでもらえると、なぜ操作優先かが伝わるかもしれません。

次にやること / 未解決の問題

• 「破壊的操作の一覧」を画面ごとに自動抽出できないかは継続課題。今は手で書いている
• 「操作シナリオ」のテストを単体テストレベルで持ちたいが、UIを絡めるとコスト高でまだ着手できていない