どこから始めるか

すべてを一度に直そうとせず、1つ選んで、小さく始めることをおすすめします。

まず現状を確認する

改善の前に、使われていないものがないか確認すると、無駄な作業を避けられます。

確認対象	チェック観点
画面	アクセスログがほぼない画面はないか
ステータス	実際には使われていない状態値はないか
カラム	1種類の値しか入っていない区分はないか
ボタン	クリックされていない機能はないか
権限	使われていない権限、分ける意味がない権限はないか

使われていないものは、削除か統合の候補になります。

改善より先に「そもそも不要」を見つける方が、効果が大きいことがあります。

---

優先順位の考え方

	改善コスト：低	改善コスト：高
影響度：高	ここから始める	計画的に進める
影響度：低	余裕があれば	後回し

影響度が高く、改善コストが低いものから手をつけると、効果が出やすいです。

影響度の判断基準

• 使用頻度が高い画面か
• ユーザーからの不満が多いか
• 操作ミスや問い合わせが多いか

改善コストの判断基準

• UI変更だけで済むか（DB変更が不要か）
• 影響範囲が限定的か
• テストが容易か

---

原則別の難易度

第2部で紹介した原則には、実装の難易度に差があります。

原則	変更範囲	難易度	最初の一歩として
画面名の見直し	命名	★☆☆	◎ おすすめ
登録のインライン化	UI	★★☆	○ 良い
編集のインライン化	UI	★★☆	○ 良い
確認画面の削除	UI + Undo	★★☆	○ 良い
モードレス化	UI	★★☆	○ 良い
状態と操作の分離	DB + API	★★★	△ 計画的に
ステップ→不足条件	DB + UI	★★★	△ 計画的に

難易度の目安

• ★☆☆: 命名変更や軽微なUI調整。すぐに着手できる
• ★★☆: UIの変更が必要。フロントエンドの改修で対応可能
• ★★★: DB設計やAPI設計の見直しが必要。計画的に進める

最初は★☆☆〜★★☆の原則から始めて、成功体験を積むことをおすすめします。

---

小さく始める

最初の改善は、小さく、目に見える効果を出すことが大切です。

良い最初の一歩（★☆☆〜★★☆）

• 画面名を「操作」から「オブジェクト」に変える（★☆☆）
• 編集画面を詳細画面に統合する（★★☆）
• 確認画面を1つ削除し、取り消し機能を追加する（★★☆）
• モーダルをインライン編集に変える（★★☆）

避けた方がよい最初の一歩（★★★）

• 「状態と操作の分離」から始める（DB変更が必要）
• 「ステップ→不足条件」から始める（DB+UI両方の変更が必要）
• 全画面のリニューアル
• 複数の改善を同時に行う

1つ改善して、効果を見せる。それが次の改善につながります。