同じ操作に入口が複数ある

ケース：モバイル向けポイント送受信サービス

ユーザー同士でポイントを送り合うコンシューマー向けのモバイルアプリ。

システム要件

• 送信先の指定方法が複数ある（ID検索・連絡先・QRコード・履歴から）
• 金額を入力して送信する
• メッセージを添えられる（任意）
• 送信前に内容を確認したい

典型例

典型パターン：同じ操作に入口が複数ある 別タブで開く ↗

GET    /                            ホーム（残高・送る入口が4つ）
GET    /points/send/by-id            IDで送る（検索画面）
GET    /points/send/by-id/select     送信先選択
GET    /points/send/by-contact       連絡先で送る（選択画面）
GET    /points/send/by-qr            QRで送る（カメラ画面）
GET    /points/send/by-history      履歴から送る（送信履歴一覧）
GET    /points/send/amount           金額入力（送信先はセッションで保持）
POST   /points/send/confirm          確認画面へ
GET    /points/send/confirm          確認画面
POST   /points/send/complete         送信実行 → 完了

利用者の視点から

• どこから送ればいいか迷う - 「IDで送る」「連絡先で送る」「QRで送る」「履歴から送る」と入口が4つあり、毎回どれを押すか考える
• 送信先を変えると最初から - 金額入力画面で送信先を間違えたら、送信先選択の画面に戻り、方法（ID/連絡先/QR/履歴）まで戻る場合がある
• 前回送った人にまた送りたいが手間 - 履歴と「送る」が別画面で、履歴から送る入口を見つけにくい
• 画面名が手段で、今何をしているか分かりにくい - 「IDで送る」「連絡先で送る」は手段の名前。目的は「ポイントを送る」なのに、手段ごとに画面が分かれている

開発・運用の視点から

• 送信先指定のロジックが4系統に分散 - ID検索・連絡先取得・QR読み取り・履歴取得が別ルートにあり、共通化しにくい
• 金額入力・確認・完了が重複 - 4つの入口のあとで同じような金額入力・確認・完了画面を持つため、ルートやコンポーネントが増える
• セッションで送信先を保持 - 送信先指定画面と金額入力画面が別のため、送信先をセッションに載せがちで、タイムアウトやタブ切り替えで不整合が起きやすい
• テストが増える - 入口ごとに同じ後続フローをテストするため、パターン数が膨らむ

---

再設計

再設計パターン：入口を1つにまとめる 別タブで開く ↗

適用する原則: 見たいものを先に見せる、モードレスを優先する、画面名は「何を見ているか」で名付ける

画面はポイント画面（何を見ているか＝ポイント）。「送る」を選ぶと送信フォームが開き、フォーム内でポイント数 → 方法（ラジオ）→ 方法に応じたUI の順で進める。

GET    /                        ホーム（残高・「ポイント」へ）
GET    /points                  ポイント画面（残高・履歴・送る など）
                                「送る」を選ぶ → 送信フォームが選択で開く
POST   /points/transfers            送信実行（非同期。完了はモーダル閉じる or トースト）

（内部API・フォーム用）
GET    /api/points/recipients?q=...   送信先検索（ID・ニックネーム）
GET    /api/points/contacts           連絡先一覧（送信先候補）
GET    /api/points/transfers          送信履歴（直近・「履歴から」用）

設計のポイント

• 画面はポイント画面 — 画面名は「何を見ているか」で決める。送信画面ではなくポイント（残高・履歴・送る）を扱うポイント画面。送信フォームは「送る」を選んだときに開く
• ポイント数 → 方法 → 方法に応じたUI — フォーム内では、まずポイント数を決める。そのあと送信先の指定方法（ID・連絡先・QR・履歴）をラジオボタン的に選ぶと、選んだ方法に応じたUI（ID検索欄・連絡先一覧・QR読取・履歴一覧）が出てくる。メッセージ（任意）もフォーム内で入力できる
• 見たいものを先に — ポイント数（いくら送るか）を先に決め、送信先の指定方法はそのあとで選ばせる。手段を先に選ばせない
• 確認は操作の一部 — 確認画面を挟まず、送信ボタン押下時にモーダルやインラインで「〇〇に〇〇pt送ります。よろしいですか？」と出す
• 送信先は内部APIで取得 — フォーム内の「ID検索」「連絡先」「履歴から」は、画面遷移せず内部APIで取得する
• 送信実行は非同期 — 送信は POST /points/transfers で非同期に実行する。完了はモーダルを閉じる・トースト表示などで伝え、画面遷移しない

---

比較

観点	典型	再設計
画面数	送信先指定4種 + 金額 + 確認 + 完了	ポイント1画面（送信フォームは選択で開く）
ルート数	10以上（ページのみ）	3（ページ＋送信）+ 3（内部API）
送信の入口	4つ（ID・連絡先・QR・履歴）	1つ（ポイント画面で「送る」を選ぶ）
送信先の変更	指定画面に戻る	フォーム内で方法を切り替え
確認	別画面	モーダル or インライン
テストケース	多い（入口×後続フロー）	少ない（1フロー）
起きやすい不具合	セッション切れ、入口の取り違え	構造的に発生しにくい

---

改修に向けて

再設計には2つの変更がある。一度にやる必要はない。

変更	内容	効果
1	ポイント画面にし、送信フォームを選択で開く	画面がオブジェクト中心になり、送信先の変更がフォーム内でできる
2	確認を別画面からモーダルなどに変える	画面遷移が減り、セッション不要になる

変更1だけでも迷いが減り、変更2でルートとセッションを削減できる。

変更1: ポイント画面にし、送信フォームを選択で開く

やること

• 「IDで送る」「連絡先で送る」「QRで送る」「履歴から送る」の4ルートを廃止する
• ポイント画面（例: GET /points）を1つ用意する。ポイント画面では残高・履歴・「送る」などが並ぶ
• 「送る」を選んだときだけ送信フォームが開く（インライン展開やモーダルなど）。フォーム内の流れは「ポイント数を決める → 方法をラジオで選ぶ → 選んだ方法に応じたUIが出る」

効果

• 画面名が「何を見ているか」（ポイント）になり、一貫性が出る
• ユーザーはポイント画面で「送る」を選べばよく、手段（ID・連絡先・QR・履歴）はフォーム内のラジオで選べる
• 送信先を変えても、フォーム内で別の方法に切り替えられる

懸念への対応

懸念	対応
QRはカメラが必要で1画面に収まらない	「QR」を選んだときだけ、カメラUIをモーダルやインラインで開く。ポイント画面／送信フォームというコンテキストは維持する
履歴は一覧が長くなる	フォーム内の「履歴から選ぶ」では直近の送信先だけ表示する。全履歴はポイント画面の別セクションや別画面でよい

変更2: 確認を別画面からモーダルなどに変える

やること

• 確認用のルート（例: GET /points/send/confirm）を廃止する
• 送信ボタン押下時に、モーダルやインラインで「〇〇に〇〇pt送ります。よろしいですか？」を表示する
• 送信先・金額はすでに画面に出ているため、確認は「実行の最終確認」だけに絞る

効果

• セッションで送信先・金額を保持する必要がなくなる
• ルート数が減り、テスト対象が減る

進め方

自社プロダクトの場合

1. 小さく試す: ポイント画面にして送信フォームを選択で開く変更だけをステージングで試す
2. 味方を作る: 利用者や社内の声で「迷わなくなった」を確認する
3. 横展開する: 確認のモーダル化など、残りの変更を適用する

受託開発の場合

1. 懸念を先に聞く: 「ポイント画面にして送信フォームを選択で開く案について、どうお考えですか？」と確認する
2. 選択肢を示す: 現状（手段ごと画面）と再設計（ポイント画面＋フォーム内で方法をラジオで選ぶ）の画面数・ルート数・効果を表で示す
3. 推奨を添える: 「弊社としてはポイント画面にし、送信フォームを選択で開く案を推奨します。理由は〜」と理由を添える

顧客が従来の「手段ごと画面」を求めた場合は、理由（運用・既存画面の流用など）を聞き、必要なら従来型を採用する。

提案文書の例

受託開発向け: 顧客への提案書

# ポイント送信機能の画面設計について

## 背景

現在検討中のポイント送信機能について、画面設計の選択肢をご説明します。

## 選択肢

| 項目 | A案: 手段ごと画面 | B案: ポイント画面＋送信フォーム |
|------|-------------------|-------------------------------|
| 画面構成 | IDで送る・連絡先で送る・QRで送る・履歴から送る + 金額入力 + 確認 + 完了 | ポイント画面（送信フォームは選択で開く） |
| 画面数 | 7画面以上 | 1画面（＋フォーム） |
| 開発工数 | 大 | 小 |
| テスト工数 | 大（入口ごとに後続フローをテスト） | 小（1フローのみ） |
| 運用 | セッションで送信先を保持 | セッション不要 |

## 弊社の推奨

**B案を推奨します。**

理由:
- 画面が「何を見ているか」（ポイント）で統一され、ユーザーが迷わない
- 送信先の指定方法はフォーム内で切り替えられ、変更時に画面遷移しない
- ルート数・テストケースが削減でき、開発・保守コストが下がる

## ご確認事項

以下の点についてご意見をお聞かせください。

- 送信先の指定方法（ID・連絡先・QR・履歴）に優先順位はありますか？
- QR読み取りの頻度はどの程度ですか？
- 現行システムとの操作性の統一は必要ですか？

ご懸念があれば、対応策を検討します。

自社プロダクト向け: 社内検討資料

# ポイント送信機能の改善提案

## 現状の課題

ポイント送信機能で以下の課題が発生している。

- 「どこから送ればいいか分からない」という問い合わせが多い
- 送信先指定→金額入力→確認→完了と4画面以上遷移する
- 入口が4つ（ID・連絡先・QR・履歴）あり、テストパターンが膨らんでいる

## 提案

ポイント画面にし、送信フォームを選択で開く設計に変更する。

| 項目 | 現状 | 改善後 |
|------|------|--------|
| 画面数 | 7以上 | 1（＋フォーム） |
| ルート数 | 10以上 | 3（ページ）+ 3（API） |
| テストケース | 入口×後続フロー | 1フロー |

## 進め方

1. ステージング環境で動作確認（1週間）
2. 社内ユーザーに限定公開（2週間）
3. 問題なければ全体公開

## リスクと対策

| リスク | 対策 |
|--------|------|
| 操作が変わり戸惑う | 変更前に告知、ヘルプを更新 |
| QRの動作が不安定 | QR部分は段階的に移行、問題あれば切り戻し |

## 確認したいこと

- この方針で進めてよいか
- 限定公開の対象ユーザー
- 公開時期の制約