説得テンプレート

「良い設計」と「提案が通る」は別の話です。改善を実現するには、相手に伝わる形で説明する必要があります。

基本テンプレート

【現状】この機能は○画面で構成されています
【問題】ユーザーは△△で困っています
【提案】□□にすることで、画面を減らせます
【効果】○○が改善される見込みです
【リスク】影響範囲は○○のみです

記入例：確認画面の削除

【現状】申請機能は「入力 → 確認 → 完了」の3画面構成です
【問題】確認画面で入力内容を修正する際、最初からやり直しになります
【提案】確認画面を削除し、申請後の取り消し機能を追加します
【効果】画面遷移が減り、修正時の手間がなくなります
【リスク】申請一覧画面のみの改修で、他機能への影響はありません

相手別のポイント

上司・決裁者向け

関心: コスト、リスク、スケジュール

【現状】この機能の問い合わせが月○件あります
【問題】操作が複雑で、ユーザーが迷っています
【提案】画面を3→1に統合します
【効果】問い合わせの削減が期待できます
【リスク】改修範囲は限定的で、○日で対応可能です

避けるべき言い方:

「UXが悪い」→ 抽象的すぎる
「モダンな設計にしたい」→ 目的が不明確
「技術的負債」→ ビジネス価値が見えない

開発チーム向け

関心: 実装の妥当性、保守性

【現状】確認画面のためにセッション管理をしています
【問題】セッション切れでデータが消え、テストも複雑です
【提案】常にDB保存に変更し、セッションを廃止します
【効果】状態管理がシンプルになり、テストが書きやすくなります
【リスク】マイグレーションが必要ですが、段階的に移行可能です

現場ユーザー向け

関心: 自分の作業が楽になるか

【現状】登録に3画面の操作が必要です
【変更後】1画面で完結します
【メリット】画面の行き来がなくなります
【変わらないこと】入力する項目は同じです

よくある反論への返し方

「確認画面がないと不安」

確認画面があっても、ユーザーは流し読みしがちです。間違いを防ぐには、「実行前に確認させる」より「実行後に取り消せる」方が効果的です。実際、Gmail の送信取り消しや Slack の編集機能も同じ考え方です。

「今まで問題なかった」

問題が顕在化していないだけかもしれません。ユーザーは「面倒だな」と思っても、問い合わせまではしないことが多いです。実際に操作を観察すると、無駄な遷移で時間を使っている場面が見つかることがあります。

「影響範囲が心配」

段階的に進めることも可能です。まず1機能で試して、問題なければ横展開する形ではいかがでしょうか。切り戻しができる形で進めます。

「工数がかかる」

短期的には工数がかかりますが、長期的には保守コストが下がります。セッション管理やフラグ管理が減ることで、バグの温床も減ります。まずは新規機能から適用し、既存機能は優先度をつけて対応する形も可能です。

提案書の構成例

# ○○機能の改善提案

## 概要
- 対象: ○○機能
- 提案: 確認画面の削除と取り消し機能の追加
- 効果: 操作ステップの削減

## 現状の課題
- 3画面の遷移が必要
- 確認画面で修正すると最初からやり直し
- セッション切れでデータが消える

## 提案内容
- 確認画面を削除
- 申請後に「取り消し」ボタンを表示（30秒間）
- 一覧から再編集可能に

## 画面遷移の比較
| 現状 | 提案後 |
|------|--------|
| 入力 → 確認 → 完了 | 入力 → 完了 |
| 3画面 | 2画面 |

## 影響範囲
- 改修対象: 申請画面、申請一覧画面
- 影響なし: 承認機能、レポート機能

## スケジュール
- 設計: ○日
- 実装: ○日
- テスト: ○日

## リスクと対策
- リスク: ユーザーが慣れるまで戸惑う可能性
- 対策: リリース時に操作ガイドを表示

最後に

提案が通らない理由の多くは、「内容が悪い」ではなく「伝え方が合っていない」ことです。

相手の関心事に合わせて説明する
抽象的な言葉を避け、具体的に伝える
リスクを隠さず、対策とセットで示す

良い設計を実現するには、技術力だけでなく「通す力」も必要です。