# 画面遷移図の作り方｜開発依頼前の準備

- 公開日: 2026-10-09
- 監修: 代表取締役 兼 StockSun創業メンバー 板橋 晟星
- URL: https://www.geek-bridge.com/public/column/screen-flow-diagram-guide

画面遷移図（＝利用者がどの画面からどの画面へ移動するかを示す図）は、見積もり漏れと認識違いを防ぐ重要な発注資料です。見た目を作り込むより、利用者、画面、移動条件、分岐、例外時の動きを整理することが重要です。

## 画面遷移図とは何か、なぜ発注前に必要なのか

画面遷移図は、Webサービスや業務システム、スマートフォンアプリにおける画面間のつながりを可視化した資料です。たとえば「ログイン画面からトップ画面へ移動する」「申請内容を確認して送信すると完了画面が表示される」といった流れを、画面を表す枠と矢印で示します。

画面遷移図を作る最大の目的は、画面のデザインを決めることではありません。**利用者が目的を達成するまでの操作と、システムが対応すべき範囲を明確にすること**です。

開発会社は、機能数だけでなく、画面数、分岐数、権限による表示の違い、入力エラー、外部サービスとの行き来などを踏まえて工数を見積もります。機能一覧に「申請機能」とだけ書かれていても、実際には入力、確認、完了、差し戻し、再申請、管理者承認など複数の画面や状態が必要になることがあります。

発注のご相談を受ける開発会社の立場では、初回相談で機能一覧は受け取れても、利用者がどの順番で操作するのかが決まっていないケースが少なくありません。その状態では開発範囲の解釈が会社ごとに変わり、見積金額にも大きな差が生まれます。

### 画面遷移図と似た資料の違い

画面遷移図は、機能一覧やワイヤーフレームと役割が異なります。どれか一つで代替するのではなく、必要に応じて組み合わせます。

| 資料 | 主に示す内容 | 発注時の役割 |
|---|---|---|
| 画面一覧 | 必要な画面の名称と概要 | 画面の数と開発範囲を確認する |
| 画面遷移図 | 画面同士のつながりと移動条件 | 操作の流れ、分岐、抜け漏れを確認する |
| ワイヤーフレーム | 各画面の項目や配置の骨組み | 入力項目、ボタン、情報の優先順位を確認する |
| 機能一覧 | システムが備える処理 | 見積もり対象となる機能を整理する |
| 業務フロー図 | 人や部署を含む業務全体の流れ | システム化する範囲と人が行う作業を分ける |

画面遷移図だけで要件定義（＝作るものを具体的に決める工程）が完了するわけではありません。データ、権限、性能、セキュリティ、運用方法などは別途整理が必要です。開発の目的や業務上の要求がまだ曖昧な場合は、先に[要求定義の進め方｜要件定義との違いと外注準備](https://www.geek-bridge.com/column/business-requirements-definition-guide)を確認してください。

### 特に画面遷移図が必要なシステム

次のような案件では、画面遷移図による整理が見積もり精度に直結します。

- 一般利用者、管理者、取引先など複数の利用者がいる
- 申請、承認、差し戻しなど業務上の状態変化がある
- 会員登録、本人確認、決済など複数段階の手続きがある
- 利用者の契約プランや権限によって使える画面が異なる
- 外部の決済画面や認証画面へ移動する
- Web版とスマートフォンアプリ版の両方を提供する
- 通知メールやプッシュ通知から特定の画面を開く

一方、数ページの情報サイトなど、利用者の操作や分岐がほとんどない場合は、サイトマップと簡単な画面一覧で足りることもあります。資料を増やすこと自体を目的にせず、判断や見積もりに必要な粒度を選ぶことが大切です。

## 画面遷移図の作り方を5ステップで解説

画面遷移図は、いきなり作図ツールを開くより、利用者と目的を整理してから作る方が効率的です。次の5ステップで進めます。

### 1．利用者と達成したい目的を分ける

最初に、誰が何をするシステムなのかを整理します。同じシステムでも、一般利用者と管理者では表示する画面や操作権限が異なります。

たとえば予約サービスであれば、次のように分けられます。

| 利用者 | 主な目的 | 代表的な操作 |
|---|---|---|
| 予約者 | 希望日時を予約する | 検索、予約、変更、キャンセル |
| 店舗担当者 | 予約を管理する | 予約確認、受付、枠の調整 |
| 運営管理者 | サービス全体を管理する | 店舗管理、権限設定、集計 |

利用者の区分を曖昧にすると、管理画面が見積もりから漏れたり、本来見せてはいけない情報が表示されたりする原因になります。

### 2．必要な画面を一覧にする

次に、利用者が目的を達成するために必要な画面を書き出します。各画面には「U-01」「A-01」のような画面IDを付けておくと、見積書や議事録で同じ画面を特定しやすくなります。

画面一覧には、最低限次の項目を含めます。

- 画面ID
- 画面名
- 利用者または利用権限
- 画面の目的
- 主な操作
- 関連する機能
- 備考や未決事項

ログイン画面、一覧画面、詳細画面など目立つ画面だけでなく、確認画面、完了画面、エラー画面、パスワード再設定画面なども確認します。

ただし、表示内容が少し変わるたびに別画面として数える必要はありません。同じ画面の中で表示だけが変わる場合は、「未申請」「申請中」「承認済み」といった状態として整理する方法もあります。画面数の数え方を開発会社と合わせることが重要です。

### 3．正常系の主要な流れを矢印でつなぐ

正常系とは、入力間違いや障害がなく、想定どおりに処理が進む基本的な流れです。まずは最も利用頻度の高い操作から整理します。

たとえば会員登録であれば、次のような流れです。

- 登録開始
- メールアドレス入力
- 認証メール送信
- メール内のリンクを開く
- 会員情報入力
- 入力内容確認
- 登録完了

矢印には「登録ボタンを押す」「承認する」など、何をきっかけに移動するのかを記載します。単に画面を線でつなぐだけでは、移動条件を判断できないためです。

また、ブラウザの戻る操作や画面内の戻るボタンを押した場合、入力内容を保持するのか、破棄するのかも検討します。発注時には見落とされやすいものの、利用者の使いやすさと実装工数に影響する項目です。

### 4．分岐・例外・権限別の流れを追加する

主要な流れを作った後に、正常系以外を追加します。すべての例外を最初から網羅するのは難しいため、事業への影響が大きいものから確認します。

代表的な確認事項は次のとおりです。

- 入力内容に誤りがある場合、どこにエラーを表示するか
- ログインに連続して失敗した場合、アカウントをロックするか
- セッション切れ（＝一定時間操作しなかった状態）ではどこへ戻すか
- 権限のない画面へアクセスした場合、何を表示するか
- 在庫切れや予約枠の重複が起きた場合、どう案内するか
- 決済が失敗または中断された場合、再実行できるか
- 承認者が差し戻した場合、申請者はどの画面から修正するか
- 退会済みの利用者がメール内のリンクを開いた場合、どうするか

特に注意したいのが、外部サービスを利用する場面です。決済、本人確認、SNSログインなどでは、一度外部画面へ移動し、成功または失敗の結果を受け取って自社システムへ戻ります。外部サービス側の画面を自社で開発する必要はありませんが、移動先、戻り先、失敗時の扱いは画面遷移図に含めます。

### 5．関係者でレビューし、未決事項を残す

作成した図は、実際の業務を知る担当者、決裁者、運用担当者、開発会社で確認します。作成者だけで完結させると、部署固有のルールや例外対応が抜けやすくなります。

レビューでは、次の順番で利用者になりきって操作をたどります。

1. どこから利用を開始するか
2. 目的の操作を完了できるか
3. 途中で中断した場合に再開できるか
4. 間違えた場合に修正できるか
5. 権限が異なる利用者から何が見えるか
6. 完了後に誰が何を確認するか

この段階ですべてを決定できなくても問題ありません。未決事項には担当者と決定期限を設定し、「未定」のまま放置しないことが重要です。事業責任者、現場担当者、開発窓口の役割分担については、[システム開発の発注者体制｜役割・工数・作り方](https://www.geek-bridge.com/column/system-development-client-team)も参考にしてください。

## 発注前に確認したい必須項目と失敗の回避策

画面遷移図は、図だけを開発会社へ渡せばよいわけではありません。前提条件と業務ルールを一緒に共有することで、初めて見積もりや要件定義に利用できます。

### 画面遷移図に記載する項目

発注前には、次の項目が読み取れる状態を目指します。

- [ ] システムの利用者と権限が区別されている
- [ ] 各画面に重複しない画面IDがある
- [ ] 各画面の目的が説明されている
- [ ] 操作の開始地点と終了地点がわかる
- [ ] 矢印に移動のきっかけが記載されている
- [ ] 条件によって移動先が変わる箇所が示されている
- [ ] 確認画面、完了画面、エラー画面が含まれている
- [ ] 戻る、中断、再開、キャンセル時の動きがわかる
- [ ] 権限がない場合の扱いが決まっている
- [ ] 外部サービスへ移動する箇所が区別されている
- [ ] メールや通知から直接開く画面が示されている
- [ ] 未決事項、担当者、決定期限が記録されている
- [ ] 作成日、更新日、版番号が記載されている

### 開発会社へ一緒に渡したい資料

画面遷移図は、次の資料とセットで共有すると理解されやすくなります。

| 資料 | 共有する理由 |
|---|---|
| 開発目的と解決したい課題 | 優先順位を判断するため |
| 利用者・権限一覧 | 表示範囲と操作範囲を判断するため |
| 機能一覧 | 画面と処理の対応関係を確認するため |
| 現在の業務フロー | システム外で行う作業を確認するため |
| 画面イメージや参考サービス | 発注者の期待する操作感を共有するため |
| 外部サービスの情報 | 決済や認証などの連携範囲を確認するため |
| 希望予算と希望公開日 | 実現範囲と優先順位を提案してもらうため |

参考サービスを共有する場合は、「このサービスと同じ」とだけ伝えないようにします。外から見える画面が似ていても、管理機能、業務ルール、外部連携、セキュリティ要件は異なるためです。「検索から予約完了までの流れを参考にしたい」など、参考にする箇所を具体的に示してください。

### よくある失敗と回避策

| よくある失敗 | 起きる問題 | 回避策 |
|---|---|---|
| 正常系だけを作る | エラーや差し戻しが追加開発になる | 重要な例外を業務担当者へ確認する |
| 一般利用者の画面だけを作る | 管理画面が見積もりから漏れる | 利用者と権限を最初に分ける |
| デザインを細かく作り込みすぎる | 業務要件の確認が後回しになる | 最初は箱と矢印で流れを確定する |
| 画面名だけで矢印をつなぐ | 移動条件を開発会社が判断できない | ボタンや条件を矢印に記載する |
| 開発会社へ丸投げする | 実際の業務と合わない図になる | 発注者が業務ルールを説明し承認する |
| 更新履歴を管理しない | 古い図を前提に開発が進む | 版番号と更新責任者を決める |

「きれいな図を完成させてから相談しなければならない」という考えもよくある誤解です。手書きや表形式でも、利用者と主要な流れが整理されていれば相談は可能です。開発会社には、不足情報を質問し、業務を構造化する役割も期待できます。

## 画面遷移図作成の費用・期間と外注先の選び方

画面遷移図の作成期間と費用は、画面数だけでは決まりません。利用者の種類、権限、業務上の分岐、既存資料の状態、ワイヤーフレームまで作るかによって変わります。

### 作成費用と期間の一般的な目安

| 依頼範囲 | 費用の目安 | 期間の目安 | 想定される内容 |
|---|---:|---:|---|
| 既存図のレビュー・修正支援 | 10万〜30万円程度 | 数日〜2週間 | 抜け漏れ確認、改善提案、修正 |
| 画面一覧と主要遷移の作成 | 30万〜80万円程度 | 2〜4週間 | ヒアリング、画面整理、正常系・主要分岐 |
| 詳細遷移とワイヤーフレーム作成 | 80万〜200万円以上 | 1〜2か月以上 | 権限別遷移、例外系、各画面の項目整理 |

上記は一般的な目安です。数画面の社内ツールなら小さく収まる一方、一般利用者、加盟店、運営者が存在するサービスや、申請・承認が多段階になる業務システムでは費用が増えます。

また、画面遷移図だけを単独で外注するより、要件定義の一部として依頼することも一般的です。その場合は、業務整理、機能一覧、権限整理、ワイヤーフレームなどの費用も含まれているかを確認してください。

### 見積もりで確認すべき項目

見積書では、総額だけでなく次の内容を確認します。

- ヒアリング回数と参加人数
- 対象とする利用者、業務、画面の範囲
- 正常系だけか、例外系や権限別の遷移も含むか
- 画面一覧やワイヤーフレームを作成するか
- レビューと修正の回数
- 業務ルールの整理や提案を含むか
- 納品形式が編集可能か
- 納品後の更新を誰が担当するか
- 開発へ進む場合に資料をそのまま引き継げるか

「画面遷移図作成一式」とだけ記載された見積もりでは、どこまで作るのか判断できません。成果物のサンプルや目次を見せてもらい、含まれる範囲を確認してください。

編集可能な元データを受け取れるかも重要です。画像やPDFだけでは、開発中に仕様が変わった際に自社で更新できません。使用ツール、アカウントの所有者、編集権限、納品形式を発注前に決めておきます。

### 外注先を選ぶポイント

画面遷移図の作成を依頼する場合は、図の見栄えではなく、業務を理解して抜け漏れを発見できるかを評価します。

確認したいポイントは次のとおりです。

- 利用者ごとの目的や業務を質問してくれるか
- 正常系だけでなく、差し戻しや失敗時の動きを確認するか
- 画面数を増やす前に、本当に必要かを検討してくれるか
- 未決事項と決定済み事項を区別して管理するか
- 予算に応じて優先順位や段階開発を提案できるか
- デザイン、要件定義、開発とのつながりを説明できるか
- 編集可能な形式で成果物を引き渡すか
- 作成担当者と実際の開発担当者が連携できるか

発注相談では、「画面遷移図を作ってほしい」という依頼の背景を確認すると、実際の課題が「社内で業務を決め切れていない」「複数社の見積もり条件をそろえたい」「開発会社の提案を社内で説明したい」と判明することがあります。目的によって必要な成果物は異なるため、外注先には図の作成だけでなく、その後の見積もりや開発にどう利用するかまで伝えましょう。

自社サービスの画面整理や要件定義から支援が必要な場合は、[開発のご相談はこちら](https://www.geek-bridge.com/#contact)からご相談ください。

## まとめ

- 画面遷移図は、利用者がどの画面からどの画面へ移動するかを示す資料です
- 見積もり漏れを防ぐには、画面数だけでなく、権限、分岐、例外、外部サービスとの行き来を整理します
- 作成時は、利用者の整理、画面一覧、正常系、例外系、関係者レビューの順に進めます
- デザインを作り込む前に、業務上の流れと移動条件を確定することが重要です
- 概算見積もりの段階では、主要な画面と代表的な流れまで整理できていれば相談できます
- 外注費用の目安は、レビュー支援で10万〜30万円程度、新規作成で30万〜80万円程度、詳細設計まで含む場合は80万〜200万円以上です
- 外注先は、図の見栄えではなく、業務理解、例外への質問、未決事項の管理、開発への引き継ぎで比較します
- 納品時には、画像だけでなく編集可能な元データを受け取れる条件にします

## よくある質問

### 画面遷移図は専用ツールで作る必要がありますか？

専用ツールは必須ではありません。Excel、PowerPoint、Googleスライド、Figmaなど、関係者が閲覧・更新できるツールで十分です。見た目の美しさよりも、画面名、移動条件、分岐、戻り先が明確であることを優先してください。

### 見積もり依頼前にすべての画面遷移を決める必要がありますか？

概算見積もりの段階では、主要な利用者、中心となる画面、代表的な正常系と例外系まで整理できていれば依頼できます。ただし、請負契約で金額と納期を確定する前には、権限別の違いやエラー時の動きも含めて詳細化する必要があります。

### 画面遷移図は発注者と開発会社のどちらが作るべきですか？

業務上の正しさに責任を持つのは発注者ですが、図の作成作業は開発会社へ依頼できます。発注者が利用者、業務ルール、承認条件、例外対応を説明し、開発会社が構造化して図に落とし込む進め方が現実的です。

### 画面遷移図の作成を外注すると費用はいくらかかりますか？

一般的な目安は、既存資料のレビューや修正支援で10万〜30万円程度、画面一覧と主要遷移の新規作成で30万〜80万円程度、ワイヤーフレームや詳細要件まで含める場合は80万〜200万円以上です。画面数、利用者の種類、業務ルール、既存資料の有無によって変動します。