4. 「どうせ変わる」と割り切って設計したポイント
「どうせ変わるだろう」と最初から割り切ったところをいくつか挙げます。

4-1. トップページのカード構成
・カード1つ＝1機能ブロック
・表示有無・並び順は将来変更可能
・カード定義とロールの紐付けは別管理
ただし、
将来変更可能とするだけでなく、だれが／どこから設定するか、
というところまでイメージしておけば、実装で迷わなかったと反省しています。

4-2. 検索条件と一覧カラムは“定義”として持つ
業務システムあるあるですが、
「この一覧に、この項目も出したい」
「この条件でも検索したい」
という要望は、リリース後に必ず増えます。

そこで、最初から以下のように割り切りました。
・検索条件／カラムは業務オブジェクトごとに定義
・画面は定義に従って描画するだけ
・絞り込みロジックは共通化
このおかげで、
項目追加などの要望にコード修正なしで対応できる場面が増えました。

一方で、定義の自由度を上げすぎるとテストパターンが爆発するので、
・「型」や「入力形式」はある程度パターンを限定する
・「なんでも正規表現」は採用しない
といったバランス調整が必要でした。

4-3. 承認フローは完全抽象化を諦める
・ステータスと履歴は共通化
・「誰が承認するか」は別モジュールに隔離
・画面は状態と操作可能アクションだけを知る
実際、運用が始まってから、
・「一部部門だけ、承認経路を変えたい」
・「例外的に、このロールでも承認できるようにしたい」
といった要望が出てきましたが、
承認ロジックの変更が、画面にはほぼ影響しない構造になっていたため、
比較的安全に対応できました。