画面遷移図の作り方：発注前に描いておくと手戻りが減る理由と手順

画面遷移図は、システムの画面を四角で並べ、どの画面からどの画面へ移るのかを矢印でつないだ図です。発注前に描いておく価値は、きれいな図そのものではなく、描く過程で「この画面に戻る道がない」「権限のない人がここに来たらどうなるのか」「エラーのときはどこへ行くのか」といった抜けに発注者自身が気づけることにあります。紙とペンで描いた手書きの図でも、その効果は十分に得られます。

画面遷移図があると、開発会社は画面数と画面間のつながりを正確につかめるため、見積もりのブレが小さくなります。そして開発が始まってから「こんな画面が必要だとは聞いていない」「この操作の後はどこに戻るのか」という確認や作り直しが減ります。手戻りの多くは、作る前に誰も考えていなかった画面や分岐から生まれるからです。

この記事は、システムやアプリの開発を発注しようとしている事業責任者・担当者に向けて、画面遷移図がなぜ効くのか、何をどの順番で描けばよいのか、描いた後に何を確認すればよいのかを、手順とチェック項目で説明します。デザインツールの使い方の話はしません。

画面遷移図とは：画面一覧・ワイヤーフレームとの違い

画面遷移図は、画面の「つながり」を表す図です。用語としての説明は画面遷移図の用語ページにまとめていますが、発注者の立場では、よく似た三つの資料との違いを押さえておくと迷いません。

画面一覧は「部屋の一覧」、画面遷移図は「部屋と廊下の間取り図」、ワイヤーフレームは「部屋の中の家具配置」とたとえると分かりやすいでしょう。発注前の段階で最も費用対効果が高いのは、間取り図にあたる画面遷移図です。部屋の数と動線が決まれば、家の規模と工事の大きさはおおよそ見積もれるからです。画面ごとの詳細を詰める画面設計書は、発注後の設計工程で開発会社と一緒に作るものと考えて構いません。

発注前に描くと手戻りが減る理由

画面遷移図が手戻りを減らすのは、文章だけの要件では見えにくいものが、図にすると目に見えるからです。具体的には次の四つです。

1. 画面の数が確定し、見積もりの前提がそろう

文章で「会員が予約できる」と書くだけでは、予約に何画面かかるのかは読み手によって解釈が分かれます。日付を選ぶ画面、時間を選ぶ画面、内容を確認する画面、完了画面と分けるのか、一画面で済ませるのかで工数は変わります。図にすれば、それが一目で共有できます。

2. 行き止まりと戻り道の抜けが見つかる

矢印を引いていくと、「この画面から先に進む道しかなく、前の画面に戻れない」「完了画面の後にどこへ行けばよいか決まっていない」といった行き止まりが見つかります。これは文章ではまず気づけません。

3. 利用者の種別ごとの違いが見える

ゲスト、会員、スタッフ、管理者で見える画面が違う場合、図を利用者ごとに分けるか、色分けすると、権限の設計に必要な情報が自然に整理されます。権限の考え方はRBAC（ロールベースアクセス制御）の用語ページも参考になります。

4. 例外の流れに目が向く

入力エラー、ログイン切れ、在庫切れ、支払い失敗など、うまくいかなかったときの流れは、正常な流れを描き終えた後に「では失敗したら？」と問うことで初めて出てきます。例外の流れは開発の後半で発覚すると作り直しが大きくなるため、早めに洗い出す価値があります。

画面遷移図の作り方：準備と7つの手順

描く前に準備するもの

いきなり描き始めるより、次の三つを用意しておくと迷わずに進められます。

• 利用者の種別の一覧：誰が使うのか。権限が違う人は別の種別として扱います。
• 機能一覧表：何ができるのか。画面遷移図と機能一覧表は対になる資料なので、先に機能一覧を作っておくと画面の漏れを照合できます。作り方は機能一覧表の作り方で解説しています。
• 代表的な利用シナリオ：「初めて来た人が会員登録して最初の予約をするまで」「スタッフが朝出勤して当日の予約を確認するまで」のように、典型的な流れを3〜5本、文章で書いておきます。

道具は、紙とペン、ホワイトボード、表計算ソフトの図形機能、オンラインのホワイトボードツールなど、使い慣れたもので構いません。大事なのは、描き直しが簡単なことです。最初から清書しようとすると、修正をためらうようになり、抜けを見つけても直さなくなります。

描き方の手順

ここからは実際の描き方です。記号は最小限に絞ります。

1. 記号を決める：画面は四角、画面ではない処理（メール送信や決済サービスへの移動など）は角丸や点線の四角、画面間の移動は矢印とします。矢印の横には「保存ボタン」「一覧の行をクリック」など、移動のきっかけを短く書きます。
2. 入口を置く：利用者が最初に来る画面を左上に置きます。トップページ、ログイン画面、メールのリンクから開く画面など、入口が複数あれば全部置きます。
3. 代表シナリオを一本ずつなぞる：用意したシナリオの一本目を、入口から完了まで画面を並べて矢印でつなぎます。二本目以降は、既存の画面を再利用しながら足していきます。
4. 戻り道を描く：各画面について「ここからどこへ戻れるか」を確認し、戻る矢印を足します。全画面共通のメニューから行ける画面は、毎回矢印を引かずに「共通メニューから遷移可」と注記すると図が見やすくなります。
5. 例外の流れを描く：入力エラー、権限がない、データがない、期限切れ、外部サービスの失敗など、正常でない場合の行き先を足します。
6. 利用者の種別ごとに色分けする：ゲストだけが見る画面、管理者だけが見る画面を色や枠線で区別します。同じ画面でも種別によって表示が変わる場合は、注記で残します。
7. 画面に番号と名前を付ける：S-01、S-02のように番号を振り、画面一覧と対応させます。番号があると、打ち合わせで「S-07の後の遷移ですが」と正確に話せるようになります。

どこまで細かく描くかは、発注前の段階では「画面」の単位で十分です。モーダル（画面の上に重なって出る小窓）や画面内のタブの切り替えは、操作上重要なものだけ注記で残し、細部は設計工程で開発会社と詰めます。

全体が大きくなりすぎる場合は、一枚に収めようとせず、「会員側」「管理側」「決済まわり」のように領域ごとに分けて描きます。そのうえで、領域同士のつながりだけを示した全体図を一枚用意すると、全体と詳細の両方が伝わります。

画面遷移図を見積もりと打ち合わせに活かす方法

描いた図は、開発会社に渡して終わりではありません。見積もりの依頼から設計の打ち合わせまで、次のように使うと効果が大きくなります。

見積もり依頼では「画面番号ごとの難しさ」を聞く

見積もりを依頼するときは、図と画面一覧を添えたうえで、「画面番号ごとに、簡単・普通・難しいのどれに当たるか」「難しいと判断した理由は何か」を教えてもらうと、費用の内訳が読みやすくなります。同じ画面数でも、外部サービスとの連携がある画面、複雑な条件で表示が変わる画面、大量のデータを扱う一覧画面は工数が大きくなりがちです。会社ごとに難しいと判断する画面が違えば、そこが前提の食い違いである可能性が高く、質問して確かめるべき箇所になります。

打ち合わせでは図の上で「シナリオを声に出してなぞる」

設計の打ち合わせでは、画面遷移図を画面に映しながら、代表シナリオを一つずつ声に出してなぞるのが効果的です。「新規の会員がトップから来て、S-02で登録し、確認メールのリンクからS-05に入り……」と発注者と開発会社が一緒に追うと、どちらか一方だけでは気づかなかった分岐や、言葉の解釈のずれが見つかります。一回の打ち合わせで全シナリオを追う必要はなく、利用頻度の高いものから順に進めれば十分です。

削る判断にも図を使う

予算や期間が合わないとき、図の上で「この画面を次の段階に回したら、どの矢印が切れるか」を確認すると、削っても利用者の流れが壊れないかを判断しやすくなります。画面を一つ削ったせいで、別の画面から先へ進めなくなる、管理側で確認する手段がなくなる、といった副作用を事前に見つけられます。削った画面は図の上で灰色にしておくと、次の段階の検討材料としてそのまま残せます。

具体例：架空の工務店の見積もり依頼サイト

架空の例として、地域の工務店が「Webから見積もり依頼を受け付け、社内で案件を管理したい」という場面を考えます。担当者が最初に描いた図は、次のような一本道でした。

• トップ → 依頼フォーム → 確認 → 完了

ここで手順4と5を当てはめると、次のような問いが出てきました。

• 確認画面から内容を直したいとき、入力済みの内容を残したままフォームに戻れるか。
• 写真を添付したいという要望が多いが、添付に失敗したときはどこに戻るのか。
• 完了後、依頼者には何が届くのか（受付メール）。そのメールから状況を確認できる画面は必要か。
• 社内側では、新しい依頼をどの画面で知り、担当者をどこで割り当てるのか。
• 依頼者が後から写真を追加したいと言ってきたら、どの画面で受け取るのか。

この結果、依頼者側は「依頼フォーム（写真添付つき）→ 確認 → 完了 → 受付メール」に加えて、「メールのリンクから開く依頼状況の確認画面」が必要かどうかが論点になりました。社内側は「依頼一覧 → 依頼詳細 → 担当者の割り当て → 見積もり送付の記録」という管理側の流れがまるごと抜けていたことが分かりました。

さらに、社内側の流れを描いてみると、「担当者が現場に出ていてパソコンを開けない」という事情から、依頼詳細と担当者の割り当てはスマートフォンでも操作できる必要があることが分かりました。画面の数は同じでも、スマートフォンでの見やすさを前提にするかどうかで設計とテストの範囲は変わります。図の該当画面に「スマートフォン操作必須」と注記したことで、開発会社はこれを見積もりの前提に含めることができました。また、見積もり送付の記録については、最初は依頼詳細の画面にメモ欄を設けるだけにし、正式な見積書の作成機能は既存の表計算ソフトで続けることにしました。

最初の一本道だけで見積もりを依頼していれば、管理側の画面は見積もりに含まれず、開発が始まってから追加費用として表面化していたはずです。画面遷移図は、このような「見えていなかった半分」を発注前に表に出すための道具だと言えます。なお、依頼状況の確認画面は、最初は受付メールに担当者の連絡先を載せることで代用できると判断し、次の段階に回しました。図があると、こうした「作らない判断」も根拠を持って行えます。

描いた後の確認：抜け漏れチェックリスト

図ができたら、開発会社に渡す前に次の項目を確認してください。

• すべての画面に、少なくとも一つの入口（来る矢印）がある
• 完了画面やエラー画面を含め、すべての画面から次にどこへ行くかが決まっている
• 確認画面から入力画面へ、入力内容を保ったまま戻れるかが決まっている
• ログインが必要な画面に、ログインしていない人が来たときの行き先が決まっている
• 権限のない人が来たときの扱い（非表示にする、エラーを出す）が決まっている
• 一覧画面で「データが0件」のときの表示を考えている
• 外部サービス（決済、地図、カレンダーなど）へ移動して戻ってくる流れが描かれている
• メールや通知のリンクから直接開く画面が入口として描かれている
• 利用者の種別ごとに見える画面が区別されている
• 画面番号が振られ、機能一覧表のどの行がどの画面に載るかを照合した

最後の照合は特に大事です。機能一覧表にはあるのにどの画面にも載っていない機能、逆に画面はあるのに機能一覧にない操作が見つかったら、どちらかが漏れています。要件全体のまとめ方は要件定義書の書き方も参考にしてください。

画面と一緒に「データの状態」も書き出す

画面遷移図を描いていると、「同じ画面でも、データの状態によって表示やできることが変わる」場面に必ず出会います。たとえば見積もり依頼なら「受付済み・対応中・見積もり送付済み・成約・見送り」、予約なら「仮予約・確定・キャンセル・来店済み」のような状態です。状態によって、ボタンを出すか隠すか、編集を許すか、どの一覧に表示するかが変わります。

この状態の変化は、画面遷移図とは別に、状態の名前を横に並べて「どの操作で次の状態に進むか」「誰がその操作をできるか」を矢印で書いた小さな図にしておくと整理しやすくなります。画面ごとに「この画面はどの状態のデータを扱うか」を注記しておけば、開発会社は表示条件の分岐を見積もりに織り込めます。状態の種類が多いほど条件分岐とテストの量が増えるため、ここで「この状態は本当に必要か」を見直すことも、費用を抑える有効な手段です。

よくある失敗とその避け方

画面遷移図づくりで起こりがちな失敗を挙げます。

• 最初からデザインを作り込む：色やレイアウトにこだわると時間がかかり、描き直しをためらうようになります。発注前は四角と矢印だけで十分です。見た目はプロに任せる部分です。
• 正常な流れしか描かない：成功したときの一本道だけでは、例外処理の工数が見積もりから漏れます。手順5を必ず通ります。
• 管理側を描かない：利用者側の画面だけを描いて、運営する側の画面を忘れるのは非常によくある失敗です。「この情報は誰がどこで登録・確認・修正するのか」を問い、管理側の流れも描きます。管理機能の範囲については管理画面開発の進め方も参考になります。
• 一枚に全部詰め込む：矢印が交差して読めなくなると、確認の役に立ちません。領域ごとに分け、全体図を別に作ります。
• 既存サービスの画面を真似しただけ：参考サービスの画面構成をそのまま写すと、自社の業務にない画面まで作ることになります。自社のシナリオに沿って必要な画面だけを残します。
• 描いた図を更新しない：開発中に画面が増減したら図も直します。古い図が残っていると、テストや受け入れの段階で「どれが正しいのか」が分からなくなります。

よくある質問

Q. 手書きの画面遷移図を開発会社に渡しても失礼になりませんか？

失礼にはなりません。むしろ、文章だけの要件よりはるかに伝わりやすく、歓迎されることがほとんどです。スマートフォンで撮影して画像で渡せば十分です。清書は、内容が固まってから開発会社に任せれば構いません。

Q. 画面遷移図があれば、要件定義はいらなくなりますか？

いりません。画面遷移図は画面のつながりを示すものであり、入力項目のルール、計算の方法、データの持ち方、速度やセキュリティの条件などは表せません。要件定義の一部として、文章の要件や機能一覧表と組み合わせて使うものです。

Q. スマートフォンアプリでも同じ描き方でよいですか？

基本は同じです。ただしアプリでは、下部のタブで常に切り替えられる画面、プッシュ通知から直接開く画面、オフライン時の表示など、アプリ特有の入口や状態があります。それらを入口として描き足してください。

Q. 開発会社からワイヤーフレームやデザインの試作を先に見せてもらうべきですか？

主要な画面だけでも、開発の早い段階で見せてもらうことをおすすめします。画面遷移図でつながりが合意できていても、実際の画面を見ると「この項目は一覧に出ていてほしい」「ボタンの位置が業務の順番と合わない」といった気づきが出るためです。試作を見る時期と回数は、見積もりや契約の段階で確認しておくと安心です。

Otsumuに相談できること

利用者の種別が少なく、業務の流れが固まっているシステムであれば、この記事の手順とチェックリストで画面遷移図を描き、機能一覧表と合わせて開発会社に見積もりを依頼するところまでは、自社で十分に進められます。手書きの図でも、渡すと渡さないとでは見積もりの精度と開発中のやり取りが大きく変わります。

一方で、新規事業で利用者の行動がまだ想像の段階にある場合や、利用者側と管理側、取引先側など複数の立場が絡んで流れが複雑な場合、描いてみたものの画面数が膨らみすぎて最初の版で何を作るべきか判断できない場合は、外部の視点を入れると整理が早く進みます。画面を減らす判断は、事業の目的と検証したいことから逆算して行うものだからです。

Otsumuは、構想段階のシナリオ整理から画面遷移図・機能一覧のたたき台づくり、AIを活用した少人数・短期間の開発、公開後の改善までを一気通貫で支援しています。業務システムや事業向けのWebサービスはシステム開発、新規事業の最初の版を短期間で形にしたい場合は新規事業の爆速MVPシステム開発をご覧ください。

描きかけの手書きの図があれば、それを見ながら「どの画面が本当に必要か」を一緒に整理できます。30分の無料相談からお気軽にご相談ください。

この記事について

Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。

執筆：Otsumu株式会社 ／ 編集日 2026.10.01