中身より先に手段を選ばせる

典型例では、メニューを見る前に「受け取り方法」と「店舗」を専用画面で選ばせる。再設計では、メニュー画面で店舗も選び、受け取り方法は注文確認時に選ばせる。

典型例

典型パターン：中身より先に手段を選ばせる別タブで開く ↗

典型の画面遷移

流れ: ホーム → 受け取り方法を選ぶ（専用画面・店内/持ち帰り）→ 店舗を選ぶ（専用画面・一覧 or 地図）→ メニューを選ぶ → 注文確認（別画面）→ 注文する（確認ドロワー）→ 完了。ナビはホーム・注文・アカウント。初期表示は注文タブ（受け取り方法を選ぶ画面）。

GET    /                        ホーム
GET    /receive                  受け取り方法を選ぶ（店内/持ち帰り・専用画面）
GET    /stores                   店舗を選ぶ（一覧・地図・専用画面）
GET    /stores/:id/products      メニューを選ぶ（その店舗の商品）
GET    /cart                     注文確認（カート・受け取り店舗・支払方法）
GET    /account                  アカウント（設定・注文履歴など）
POST   /cart/checkout            注文実行（確認モーダル後）

利用者の視点から

注文までに画面が多く感じる - 受け取り方法 → 店舗 → メニュー → 注文確認と、タスクごとに画面が切り替わる
「何を食べたいか」より先に手段を選ばされる - まず店内/持ち帰りと店舗を決めないとメニューに進めない
店舗を変えると受け取り方法からやり直し - 別の店舗で注文したくなったとき、店舗選択や受け取り方法の画面に戻る
見出しがタスク名で、今どこにいるかは分かりやすい - 「受け取り方法を選ぶ」「店舗を選ぶ」など流れは明確

開発・運用の視点から

ルートが多く、画面ごとにロジックが分散する - 受け取り方法・店舗・メニュー・カートと画面が分かれるため、状態の受け渡しやテストが増える
「まず店舗を選ばせたい」運用には向く - FC の店舗誘導など、受け取り方法・店舗を先に決めさせる運用と相性がよい
持ち帰り専用店舗は受け取り方法画面と整合を取る必要がある - 店舗によっては持ち帰りのみのため、先に選んだ受け取り方法と店舗の組み合わせを考慮する必要がある

再設計

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

再設計パターン：見たいものを先に別タブで開く ↗

再設計の画面遷移

流れ: ホーム → メニュー（店舗は同一画面内でドロップダウン or 地図で選ぶ。持ち帰りのみの店舗は選択時に表示）→ 商品をカートに追加 → 画面下部のカートバー「注文する」→ 確認ドロワー（受け取り方法・支払方法を選択）→ 注文実行 → 完了。ナビはホーム・メニュー・アカウント。初期表示はメニュータブ。

GET    /                        ホーム
GET    /products                 メニュー（店舗は同一画面内で一覧・地図で選ぶ）
GET    /account                  アカウント（設定・注文履歴など）
POST   /cart/checkout            注文実行（カートは下部固定バー、確認はドロワー）

設計のポイント

画面はメニュー画面 — 画面名は「何を見ているか」で決める。注文フロー用の画面ではなく、メニュー（商品・店舗・カート）を扱うメニュー画面。店舗は同一画面内のドロップダウンや地図で選ぶ
店舗選択時に持ち帰りのみが分かる — 店舗によっては持ち帰りのみのため、ドロップダウンや地図ピンで「（持ち帰りのみ）」を表示する。確認ドロワーでは持ち帰り専用店舗のとき受け取り方法の選択を出さず「この店舗は持ち帰りのみです」と表示する
カートは画面下部の固定バー — カート内容は別画面にせず、メニュー画面下部に固定バー（N点 ¥XXX・「注文する」）で表示する。タップで注文ドロワーを開き、内容確認・受け取り方法・支払方法を選んで注文する
受け取り方法は確認時に選ぶ — 店内/持ち帰りは注文確認ドロワー内で選ばせる。注文直前の意思確認になり、持ち帰り専用店舗の場合は選択肢を出さない
確認は操作の一部 — 確認用の別画面やルートは設けず、注文ボタン押下時にドロワーで確認する

比較

画面遷移の比較

観点	典型	再設計
画面数	5画面（受け取り方法・店舗・メニュー・確認・完了）	2画面（ホーム・メニュー）
ルート数	7	4
ナビ	ホーム・注文・アカウント	ホーム・メニュー・アカウント
初期表示	注文タブ（受け取り方法選択）	メニュータブ（商品一覧）
店舗の選び方	専用画面で先に選ぶ	メニュー画面内で選ぶ
カートの見せ方	注文確認画面（別画面）	画面下部の固定バー
受け取り方法の選択	先に選ぶ（専用画面）	後に選ぶ（確認ドロワー内）
見出しの傾向	タスク（受け取り方法を選ぶ・店舗を選ぶ…）	オブジェクト（メニュー）
テストケース	多い（画面ごとに状態管理）	少ない（1画面内で完結）
起きやすい不具合	店舗変更で状態リセット	構造的に発生しにくい

共通していること：ホームに「現在の注文」を表示、確認はモーダル（ドロワー）、注文完了後はホームへ。

改修に向けて

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

変更	内容	効果
1	店舗選択をメニュー画面に統合する（専用画面をやめる）	画面がオブジェクト中心になり、メニューを見ながら店舗を切り替えられる
2	受け取り方法を確認ドロワーで選ばせる（先に選ぶ専用画面をやめる）	ルートが減り、注文直前の意思確認になる。持ち帰り専用店舗は確認時に選択を出さない

変更1だけでも「何を食べたいか」を先に示せる。変更2で受け取り方法の専用画面をやめると、典型例との差がよりはっきりする。

変更1: 店舗選択をメニュー画面に統合する

やること

「受け取り方法を選ぶ」「店舗を選ぶ」の専用ルート（/receive, /stores）を廃止する
メニュー画面（例: GET /products）を1つ用意する。メニュー画面では店舗をドロップダウンや地図で選び、その店舗の商品一覧を表示する
カートはメニュー画面下部の固定バーで表示し、タップで注文ドロワーを開く

効果

画面名が「何を見ているか」（メニュー）になり、一貫性が出る
ユーザーはメニュー画面でいきなり商品を見て、店舗は同じ画面で切り替えられる
店舗を変えても、メニュー画面内で完結する

懸念への対応

懸念	対応
「まず店舗を選ばせたい」運用がある	ホームやメニュー画面の上部に「店舗から選ぶ」の入口を残す。または典型例のまま専用画面を維持する
持ち帰り専用店舗がある	店舗選択時（ドロップダウン・地図）で「持ち帰りのみ」と表示する。確認ドロワーでは受け取り方法の選択を出さず「この店舗は持ち帰りのみです」と表示する

変更2: 受け取り方法を確認ドロワーで選ばせる

やること

「受け取り方法を選ぶ」専用ルート（/receive）を廃止する
注文確認ドロワー内で、受け取り方法（店内で食べる/持ち帰り）をラジオなどで選ばせる
持ち帰り専用店舗の場合は、受け取り方法の選択肢を出さず「この店舗は持ち帰りのみです」と表示する

効果

ルートが減り、受け取り方法は注文直前の意思確認になる
店舗ごとの制約（持ち帰りのみ）を確認時に自然に反映できる

進め方

自社プロダクトの場合

小さく試す: メニュー画面に店舗選択を統合する変更だけをステージングで試す
味方を作る: 利用者や店舗の声で「メニューが探しやすくなった」を確認する
横展開する: 受け取り方法を確認時に選ばせる変更を適用する

受託開発の場合

再設計を提案する: 「メニュー画面で店舗を選び、確認はドロワーで行う設計を推奨します」と伝える
例外要件を確認する: 「FC店舗誘導の必須要件はありますか？」「受け取り方法で価格やメニューが変わりますか？」と確認する
例外に該当すれば典型例を採用: 上記に該当する場合のみ、専用画面ありの設計を採用する

例外要件がなければ、再設計を採用する。

提案文書の例

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

# モバイルオーダーの画面設計について

## 弊社の推奨

**メニュー画面に統合する設計を推奨します。**

| 項目 | 推奨案 |
|------|--------|
| 画面構成 | メニュー（店舗選択・カート内蔵）→ 確認ドロワー |
| ルート数 | 4（従来比 -3） |
| 開発工数 | 小 |

理由:
- 「何を食べたいか」を先に見せられる
- 店舗を変えてもメニュー画面内で完結する
- ルート数・テストケースが削減でき、開発・保守コストが下がる

## 例外要件の確認

以下に該当する場合は、専用画面ありの設計を検討します。

| 要件 | 該当しますか？ |
|------|----------------|
| FC店舗への誘導が必須（本部指示など） | はい / いいえ |
| 受け取り方法で価格・メニューが大きく変わる | はい / いいえ |
| 既存システムとの操作統一が必須 | はい / いいえ |

上記すべて「いいえ」の場合、推奨案を採用します。

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

# モバイルオーダーの改善提案

## 現状の課題

モバイルオーダー機能で以下の課題が発生している。

- 「何を食べたいか」より先に受け取り方法・店舗を選ばせている
- 店舗を変えると受け取り方法からやり直しになる
- 画面が多く、離脱率が高い

## 提案

メニュー画面に店舗選択を統合し、確認はドロワーで行う設計に変更する。

| 項目 | 現状 | 改善後 |
|------|------|--------|
| ルート数 | 7 | 4 |
| 注文までの画面数 | 5画面 | 2画面 |
| 店舗変更 | 受け取り方法からやり直し | メニュー画面内で切り替え |

## 進め方

1. ステージング環境で動作確認（1週間）
2. 一部店舗で限定公開（2週間）
3. 問題なければ全店舗公開

## リスクと対策

| リスク | 対策 |
|--------|------|
| 操作が変わり戸惑う | 変更前に告知、ヘルプを更新 |
| 店舗誘導ができなくなる | ホームに「店舗から選ぶ」入口を残す |

## 確認したいこと

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

基本方針

再設計（専用画面なし）を基本とする。

メニュー画面で店舗を選び、確認はドロワーで行う設計を採用する。「何を食べたいか」を先に示し、手段（店舗・受け取り方法）は後で選ばせる。

例外: 専用画面ありを選ぶケース

以下の要件がある場合は、典型例（専用画面あり）を検討する。

要件	理由
FC店舗への誘導が必須	本部が特定店舗への集客を優先するため、店舗選択を先に強制したい
受け取り方法で価格・メニューが大きく変わる	店内/持ち帰りで税率や提供メニューが異なり、先に確定させたい
既存システムとの操作統一が必須	利用者が既存の操作に慣れており、変更コストが高い

上記に該当しない場合は、再設計を採用する。