改善を提案する

既存システムの改善を提案して通すコツを紹介します。

「作り直し」ではなく「改善」

❌ 「このシステムはダメなので作り直しましょう」

✅ 「この画面の操作を1ステップ減らせます」

「作り直し」は大きな決断が必要です。「改善」は小さな許可で始められます。

言い換えの例

避ける表現	使う表現
設計がおかしい	この部分を改善できます
使いづらい	操作ステップを減らせます
古い	より効率的にできます
作り直す	段階的に改善する

問題を指摘するのではなく、改善の機会を提示することが大切です。

誰に提案するか

開発チーム内

まずは身近なメンバーに相談
「こうしたら良くなりそう」を共有
賛同者を1人作る

プロダクトオーナー / マネージャー

ユーザー視点のメリットを伝える
数字で効果を示す
工数と影響範囲を明確に

ユーザー / 業務担当者

「この操作、面倒ではないですか？」と聞く
ユーザーの声を味方につける
「ユーザーからの要望」として提案できる

数字で効果を示す

「良くなる」ではなく「これだけ減る」と伝えましょう。

定量的な指標

画面遷移が 3回 → 1回 に減る
操作ステップが 5 → 3 に減る
入力項目が 10 → 6 に減る

利用頻度との掛け算

この画面は 月に500回 使われている
1回あたり 30秒 短縮できる
月に 250分 = 約4時間 の削減

ビフォー/アフターを見せる

現状の画面遷移図
改善後の画面遷移図
差分を視覚的に示す

提案のタイミング

良いタイミング

バグ修正のついでに
機能追加の一環として
リファクタリング期間中
ユーザーから不満が出たとき

避けるタイミング

リリース直前
他の大きな変更と同時
チームが忙しいとき

「ついでに」が通りやすいです。単独で大きな提案は避けましょう。

味方を作る

開発チーム内で

1人でも賛同者がいると通りやすい
「○○さんも同意見です」と言える
レビューで味方になってもらう

ユーザーから

「ユーザーの△△さんも困っていました」
ユーザーの声を収集しておく
改善後にフィードバックをもらう

よくある反論への対応

「今のままで動いているから」

→ 「動いています。ただ、この操作を減らすとユーザーの負担が減ります」

→ 「現状維持でも大丈夫です。ただ、この機会に改善すると今後が楽になります」

「変更するとバグが出るかも」

→ 「影響範囲はこの画面だけです」

→ 「テストを用意します」

→ 「段階的にリリースできます」

「そんな時間はない」

→ 「この1画面だけなら○時間で対応できます」

→ 「次のスプリントで対応できます」

→ 「バグ修正のついでに対応できます」

「ユーザーが慣れているから」

→ 「慣れていても、減らせる操作は減らした方が良いです」

→ 「新しいユーザーの学習コストも下がります」

却下されたら

すぐに諦めない

「分かりました。また機会があれば」と伝える
タイミングを変えて再提案
別の切り口で提案

記録を残す

提案内容をドキュメントに残す
「あのとき提案した件ですが」と言える
状況が変わったときに再利用

小さく始める

許可不要な範囲で改善する
「こうなりました」と事後報告
効果が出たら「他もやりましょう」

成功したら

効果を報告する

「○○が△△になりました」と共有
数字で効果を示す
ユーザーの反応を伝える

次につなげる

「他の画面も同じようにできます」
成功事例として参照できるようにする
チーム内の知見として蓄積

まとめ

問題指摘ではなく、改善機会として提案
数字で効果を示す（「良くなる」ではなく「減る」）
味方を作る（チーム内、ユーザー）
タイミングを見る（「ついでに」が通りやすい）
却下されても記録を残し、再挑戦