画面一覧の作り方：画面遷移図とセットで使う項目・数え方・機能一覧との照合

画面一覧は、システムに必要な画面を、名前と目的つきで一覧にした表です。画面遷移図が「画面同士のつながり」を表すのに対して、画面一覧は「どんな画面があるか」を表します。発注前にこの表があると、画面の数がそろい、見積もりの前提が開発会社と食い違いにくくなります。

この記事は、システムやアプリの開発を発注しようとしている事業責任者・担当者に向けて、画面一覧に書く項目、画面の数え方、機能一覧との照合の仕方、優先度の付け方を説明します。つながりを描く方法は画面遷移図の作り方にまとめています。両方を一つのExcelで書けるテンプレート（画面遷移図・画面一覧シート）も用意しました。

画面一覧と画面遷移図の役割分担

画面一覧は部屋の名簿、画面遷移図は間取り図、とたとえられます。名簿だけでは部屋同士の行き来が分からず、間取り図だけでは各部屋が何のための部屋かが分かりません。二つは対で使います。

書く順番は、先に画面一覧で画面の候補を洗い出し、次に遷移図でつなぎ、つなぎながら足りない画面が見つかったら一覧に戻って足す、という往復になります。一度で完成させようとせず、行き来しながら固めるのが実際の進め方です。

画面一覧に書く8つの項目

発注前の画面一覧は、次の8項目があれば十分です。項目を増やしすぎると、書くこと自体が目的になってしまいます。

画面の数え方：どこまでを1画面とするか

発注前に迷いやすいのが、画面の数え方です。次の基準で揃えておくと、開発会社の数え方と大きくずれません。

• 利用者の目的が変わったら別の画面：「一覧を見る」と「1件の詳細を見る」は別の画面として数えます。
• 同じ画面の中の切り替えは、1画面のまま：タブや折りたたみで内容が切り替わるだけなら、1画面とし、備考に書きます。
• 登録と編集は、同じ入力画面を共通にできるか確認する：項目が同じなら1画面で済み、別の項目があるなら別の画面です。共通にするかどうかで画面数が変わるため、一覧の備考に「登録と編集は共通」と残します。
• 確認画面・完了画面も数える：入力の後に確認や完了の画面を挟む設計なら、それぞれ1画面です。
• エラー画面は、種類ごとに数えすぎない：入力エラーのように元の画面に戻って表示するものは、画面を増やさず、遷移図の例外の流れとして残します。

管理対象（たとえば「依頼」「顧客」「商品」）が一つ増えるごとに、一覧・詳細・登録・編集といった画面が増えるのが一般的です。管理対象を数えておくと、画面数のおおよその規模を、一覧を作る前に見当づけられます。ただし、共通化の仕方や、一覧と詳細を一つの画面にまとめるかどうかで変わるため、あくまで目安として扱ってください。

画面IDの付け方

画面IDは、S-01、S-02のように、必ず通し番号にします。内容を表す名前をIDにしてしまうと、画面名を変えたときに全資料を直すことになります。

利用者の種別や領域が複数あるなら、番号の桁で分けると便利です。たとえば、S-01〜S-09は利用者側、S-11〜S-19は管理側、S-21〜S-29は決済まわり、のようにします。後から画面が増えても、同じ領域の空き番号に足せば済みます。一度付けた番号は、画面を削っても詰め直さず、欠番のままにします。打ち合わせの記録や、開発会社との質問の履歴が、番号でたどれるからです。

機能一覧と照合して、漏れと余りを見つける

画面一覧ができたら、必ず機能一覧表と照合します。機能一覧の各機能が、どれかの画面に載っているか。逆に、画面一覧の各画面が、どれかの機能に対応しているか。この二方向の確認です。

機能はあるのに画面がなければ、その機能を使う手段が抜けています。画面はあるのに機能がなければ、その画面は不要か、機能一覧の書き漏れです。どちらも、発注前に見つかれば小さな修正で済みますが、開発中に見つかると追加の費用や作り直しにつながります。照合の結果は、「機能一覧との対応」の列に機能の番号を書いておくと、そのまま残せます。

優先度で、削る順番を決めておく

見積もりが予算を超えたとき、画面一覧に優先度が書いてあれば、何を削るかをすぐ検討できます。優先度は4段階で十分です。

優先度を付けるときは、「この画面がなくても、利用者は最初の目的を果たせるか」を問います。果たせるなら「必須」ではありません。判断に迷う画面は、備考に「何が決まれば判断できるか」を書いておきます。

具体例：架空の工務店の画面一覧

架空の例として、地域の工務店が「Webから見積もり依頼を受け付け、社内で案件を管理したい」場面の画面一覧を示します。数値や実績ではなく、書き方を示すための例です。

この例では、利用者側がS-01〜S-06、社内側がS-11以降と、桁で分けています。S-06は「次の段階」にして、図の上では灰色にしました。こうして書いておくと、あとから「依頼状況の確認画面は作らないのか」と聞かれても、理由と代替の手段が残っています。

テンプレートを使う

この記事の表と同じ構成のExcelを、画面遷移図・画面一覧シートとして用意しました。「画面一覧」シートに画面を書き、「遷移表」に矢印を1行ずつ書くと、「点検」シートが入口のない画面・行き止まりの画面を自動で見つけます。例外の洗い出し、状態の変化、開発会社に渡す前の確認リストも含みます。記入例は、この記事の工務店の例です。

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

• 画面名を、開発側の言葉で書く：「CRUD画面」「マスタ管理」のような言葉は、発注者側の誰も確認できません。利用者の言葉で書きます。
• 管理側の画面を書かない：利用者側だけを書いて、運営する人の画面が漏れるのは非常によくある失敗です。「この情報は誰がどこで登録・確認・修正するか」を問います。
• 全部を「必須」にする：優先度がすべて必須だと、削る判断ができません。「なくても最初の目的を果たせるか」で分けます。
• 一度書いて更新しない：打ち合わせで画面が増減したら、一覧も直します。古い一覧は、検収のときに「どれが正しいか」を分からなくします。
• 画面数だけで見積もりを比べる：同じ画面数でも、外部連携や条件分岐の多い画面は工数が違います。画面ごとに、簡単・普通・難しいのどれと見ているかを聞くと、前提のずれが見えます。

よくある質問

Q. 画面一覧は、画面遷移図より先に作るべきですか？

どちらが先でも構いません。実際には行き来します。画面の候補を一覧に書き出し、遷移図でつなぎ、足りない画面を見つけて一覧に戻る、という往復になります。

Q. 画面の数は、どのくらいが適切ですか？

適切な数は、事業の目的と、最初の版で確かめたいことで決まり、一般的な数はありません。数を絞ることが目的ではなく、「この画面がなくても最初の目的を果たせるか」を一つずつ問い、必要なものだけを残すことが目的です。

Q. 開発会社が作る画面一覧と、自分で作るものは別ですか？

発注前に自分で作るのは「たたき台」です。開発会社は、それを見て、足りない画面や共通化できる画面を指摘し、清書します。たたき台があると、開発会社が前提を確認する質問が具体的になり、見積もりのぶれが小さくなります。

Q. スマホアプリでも同じ書き方でよいですか？

基本は同じです。アプリでは、下部のタブから常に行ける画面、通知から直接開く画面、オフラインのときの表示などがあるため、備考や入口の欄に書き足してください。

Otsumuに相談できること

画面の種類が少なく、業務の流れが固まっているシステムであれば、この記事の項目とテンプレートで画面一覧を作り、機能一覧と照合して、開発会社に見積もりを依頼するところまでは、自社で進められます。

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

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

書きかけの画面一覧があれば、それを見ながら「どの画面が本当に必要か」を一緒に整理できます。AIツール診断からお気軽にご相談ください。

この記事のテーマに最も近い支援は、MVPの範囲設計・要件定義支援です。

• 仮説から逆算して、作らない範囲を決める
• 引き継げる軽量な仕様書にまとめる
• リリース前の確認と公開後の判断まで伴走

まずはAIツール診断で、状況をお聞かせください。

この記事のテーマに近い開発メニューは、要件定義・基本設計支援です。

• 目的から逆算して、作る範囲を決める
• 機能一覧・画面遷移図を、見積りに使える粒度に
• 開発会社へ伝わる文書にまとめる

この記事について

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

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