システム開発の要件定義や基本設計を進めていると、

「画面一覧には何を書けばよいのか」

「一覧画面と詳細画面は別々に数えるのか」

「画面一覧と画面遷移図は何が違うのか」

と迷うことがあります。

画面一覧とは、システムに存在する画面を一覧化し、それぞれの役割や利用者、関連機能などを整理した資料です。

例えば顧客管理システムなら、

• ログイン画面
• ダッシュボード
• 顧客一覧
• 顧客詳細
• 顧客登録
• 顧客編集
• 案件一覧
• 案件詳細
• ユーザー管理

などを一覧にします。

画面一覧を作ることで、

システム全体にどのような画面が必要なのか

を開発前に把握できます。

また、単に画面数を確認するだけでなく、

• 必要機能の抜け漏れ確認
• 権限整理
• UI設計
• 見積
• 開発タスク分解
• テスト計画

にも利用できます。

この記事では、業務システム・管理画面を想定して、画面一覧の作り方、必要な項目、具体例、テンプレートまで解説します。

画面一覧とは

画面一覧とは、システムに必要な画面を一覧表として整理したものです。

例えば顧客管理システムなら、次のようになります。

画面ID	画面名	概要
SCR-001	ログイン	ユーザー認証
SCR-002	ダッシュボード	案件状況を表示
SCR-003	顧客一覧	顧客を一覧・検索
SCR-004	顧客詳細	顧客情報・履歴を表示
SCR-005	顧客登録	新規顧客を登録
SCR-006	顧客編集	顧客情報を変更
SCR-007	案件一覧	案件を一覧表示
SCR-008	案件詳細	案件情報を表示
SCR-009	ユーザー管理	利用者・権限を管理

画面数が少ないシステムなら、この程度でも十分です。

規模が大きくなれば、

• 利用者
• 権限
• URL
• 関連機能
• 遷移元
• 遷移先
• 備考

なども追加します。

画面一覧を作る目的

画面一覧を作る主な目的は、システム全体像を可視化することです。

要件定義で、

「顧客を管理する」

「案件を管理する」

という機能要件だけがあっても、具体的に何画面必要なのかは分かりません。

例えば「顧客管理」という一つの機能でも、

• 顧客一覧
• 顧客検索
• 顧客詳細
• 顧客登録
• 顧客編集

が必要になる可能性があります。

画面一覧へ落とすことで、抽象的だった機能要件を、実際に利用者が操作する単位まで具体化できます。

画面一覧を作るメリット

1．画面の抜け漏れを発見できる

例えば機能一覧に、

「商品管理」

しか記載していなくても、画面を考えると、

• 商品一覧
• 商品詳細
• 商品登録
• 商品編集
• CSV取込

などが必要だと気づくことがあります。

2．システム規模を把握できる

画面数は、開発規模を把握する一つの材料になります。

例えば、

「小規模な管理システム」

と考えていたものでも、画面一覧にすると40画面必要だと分かる場合があります。

3．利用者・権限を整理できる

例えば、

• 一般ユーザー
• 店舗管理者
• 本部管理者

によって表示できる画面が違うシステムがあります。

画面一覧に利用者・権限を記載すると整理しやすくなります。

4．画面遷移図を作りやすくなる

画面一覧で必要画面を洗い出した後、それぞれの画面を線でつなげれば画面遷移を整理できます。

そのため、画面遷移図より先に画面一覧を作る方法もあります。

画面一覧に必要な項目

一般的には次の項目を使います。

項目	内容
画面ID	画面を識別する番号
画面名	画面の名称
カテゴリ	顧客・案件・設定など
概要	画面で何をするか
利用者	誰が使うか
権限	閲覧・編集可能なロール
関連機能	対応する機能要件
URL	必要に応じて記載
備考	補足事項

小規模システムなら、

画面ID・画面名・概要・利用者

程度から始めても構いません。

画面IDの付け方

画面にはIDを付けておくと管理しやすくなります。

例えば、

• SCR-001
• SCR-002
• SCR-003

とします。

「SCR」はScreenの略です。

別の付け方として、

• CUS-001：顧客
• ORD-001：注文
• ADM-001：管理

のように業務領域ごとに分類することもできます。

重要なのは命名規則そのものではなく、プロジェクト内で一意に識別できることです。

例えば打ち合わせで、

「顧客詳細画面を変更してください」

より、

「SCR-004の顧客詳細画面を変更してください」

とした方が認識を合わせやすくなります。

画面一覧の作り方7ステップ

画面一覧は、いきなり思いつく画面名を書き出すより、業務・機能から順番に整理すると抜け漏れを減らせます。

STEP1｜利用者を整理する

まず、誰がシステムを使うのか確認します。

例えば在庫管理システムなら、

• 一般担当者
• 拠点管理者
• 本部管理者

などです。

利用者によって必要画面が変わります。

例えば一般担当者には在庫一覧だけ必要でも、本部管理者には、

• ユーザー管理
• 拠点管理
• マスタ管理

も必要になる可能性があります。

STEP2｜業務フローを整理する

次に、利用者がどのような業務を行うのか確認します。

例えば在庫管理なら、

入庫する
↓
商品を確認する
↓
在庫を更新する
↓
別拠点へ移動する
↓
履歴を確認する

という流れがあります。

この業務をシステム化するために、必要な画面を考えます。

STEP3｜機能一覧を確認する

例えば機能一覧が、

• 商品管理
• 入庫管理
• 出庫管理
• 在庫管理
• 拠点管理
• ユーザー管理

となっているなら、それぞれを画面へ落とします。

例えば「商品管理」なら、

• 商品一覧
• 商品詳細
• 商品登録
• 商品編集

が候補になります。

STEP4｜画面を洗い出す

この段階では漏れを気にしすぎず、必要そうな画面を書き出します。

例えば顧客管理なら、

• ログイン
• ダッシュボード
• 顧客一覧
• 顧客詳細
• 顧客登録
• 顧客編集
• 案件一覧
• 案件詳細
• 案件登録
• 案件編集
• ユーザー一覧
• ユーザー登録
• 設定

などです。

STEP5｜カテゴリ分けする

画面数が増えたら、カテゴリで整理します。

例えば、

共通

• ログイン
• パスワード変更
• ダッシュボード

顧客

• 顧客一覧
• 顧客詳細
• 顧客登録
• 顧客編集

案件

• 案件一覧
• 案件詳細
• 案件登録
• 案件編集

管理

• ユーザー管理
• 権限管理
• マスタ管理

のようにします。

STEP6｜利用者・権限を付ける

例えば、

画面	一般	管理者
顧客一覧	○	○
顧客登録	○	○
顧客削除	×	○
ユーザー管理	×	○
システム設定	×	○

と整理します。

これによって、

「一般ユーザーから管理画面が見えてしまう」

といった設計漏れを減らせます。

STEP7｜業務・機能と照合する

最後に、

すべての機能要件を実現できる画面が存在するか

を確認します。

逆に、

何の要件にも紐付かない画面がないか

も確認します。

例えば画面一覧に、

「分析ダッシュボード」

があるのに、業務要件・機能要件のどこにも必要性が書かれていないなら、

「なぜこの画面が必要なのか」

を確認します。

管理画面の画面一覧例

例えばシンプルな顧客・案件管理システムなら、次のように整理できます。

ID	カテゴリ	画面名	概要	利用者
SCR-001	共通	ログイン	認証	全員
SCR-002	共通	ダッシュボード	件数・進捗表示	全員
SCR-003	顧客	顧客一覧	検索・一覧表示	全員
SCR-004	顧客	顧客詳細	基本情報・履歴	全員
SCR-005	顧客	顧客登録	新規登録	全員
SCR-006	顧客	顧客編集	情報変更	全員
SCR-007	案件	案件一覧	案件検索	全員
SCR-008	案件	案件詳細	案件内容表示	全員
SCR-009	案件	案件登録	新規案件登録	全員
SCR-010	案件	案件編集	案件変更	全員
SCR-011	管理	ユーザー一覧	ユーザー管理	管理者
SCR-012	管理	ユーザー登録	ユーザー追加	管理者
SCR-013	管理	マスタ管理	各種マスタ変更	管理者

この一覧を基準に、

• ワイヤーフレーム
• 画面遷移
• API
• 権限
• テスト

へ展開できます。

在庫管理システムの画面一覧例

在庫管理なら、例えば次の構成です。

共通

• ログイン
• ダッシュボード

商品

• 商品一覧
• 商品詳細
• 商品登録
• 商品編集

在庫

• 在庫一覧
• 在庫詳細
• 在庫調整

入出庫

• 入庫登録
• 出庫登録
• 入出庫履歴

拠点

• 拠点一覧
• 拠点詳細
• 拠点登録

管理

• ユーザー管理
• 権限管理
• マスタ管理

このように、業務領域ごとに整理すると抜け漏れを確認しやすくなります。

一覧・詳細・登録・編集は別画面にする？

設計方式によります。

例えば、

顧客一覧

からモーダルを開いてそのまま登録するUIなら、「顧客登録画面」が独立しない場合もあります。

一方、

顧客一覧
↓
顧客登録

とURLやページが変わるなら、別画面として管理した方が分かりやすいでしょう。

重要なのは、画面数を多く見せる・少なく見せることではなく、設計・見積・テストで同じ粒度を使うことです。

プロジェクト開始時に、

「モーダルは画面数に含めるか」

「タブ違いは別画面とするか」

などのルールを決めておくと管理しやすくなります。

モーダルは画面一覧に入れる？

重要な操作であれば、一覧に含める方法があります。

例えば、

• 顧客削除確認
• CSVアップロード
• パスワード変更
• 権限設定

などです。

ただし、小さな確認ダイアログまで全部一覧化すると管理が煩雑になります。

例えば、

独立した入力・処理があるモーダルは管理する

単純な「削除しますか？」だけなら管理しない

などのルールを作ります。

タブは別画面にする？

例えば顧客詳細画面に、

• 基本情報
• 案件
• 対応履歴
• 添付ファイル

というタブがある場合です。

すべて同じURL・同じ画面内で切り替えるなら、一つの画面として扱う方法があります。

一方、それぞれが独立した大きな機能を持つ場合は、

• SCR-004-1 顧客基本情報
• SCR-004-2 顧客案件
• SCR-004-3 顧客対応履歴

のように子画面として管理してもよいでしょう。

画面一覧は、開発チームが認識を合わせやすい粒度にすることが重要です。

画面一覧と画面遷移図の違い

混同されやすい資料です。

画面一覧

「どの画面が存在するか」を整理します。

例えば、

• ログイン
• 顧客一覧
• 顧客詳細
• 顧客登録

です。

画面遷移図

「どの画面からどの画面へ移動するか」を整理します。

例えば、

ログイン
↓
ダッシュボード
↓
顧客一覧
↓
顧客詳細
↓
顧客編集

という関係です。

つまり、

画面一覧＝画面の棚卸し

画面遷移図＝画面同士のつながり

です。

通常は、画面一覧で必要画面を整理してから画面遷移図を作ると進めやすくなります。

画面一覧と機能一覧の違い

機能一覧は、

システムで何ができるか

を整理します。

画面一覧は、

利用者がどの画面からその機能を利用するか

を整理します。

例えば、

機能要件

「顧客を検索できる」

に対して、

画面

「顧客一覧画面」

が対応します。

しかし、一つの画面に複数機能が存在することもあります。

例えば顧客一覧では、

• 検索
• 並び替え
• CSV出力
• 顧客登録への遷移

などを実行できます。

そのため、機能一覧と画面一覧は1対1とは限りません。

画面一覧を要件定義で作るか基本設計で作るか

プロジェクトによって異なりますが、要件定義段階では、

どのような画面が必要になるか

を整理し、基本設計で詳細化する方法があります。

要件定義

例えば、

• 顧客一覧
• 顧客詳細
• 顧客登録
• 案件一覧

まで整理します。

基本設計

さらに、

• 項目
• ボタン
• 入力制御
• 検索条件
• エラーメッセージ
• 画面遷移

などを具体化します。

つまり、

要件定義＝必要画面を決める

基本設計＝その画面の具体的な振る舞いを決める

と整理すると分かりやすいでしょう。

画面一覧からワイヤーフレームへ落とす

画面一覧ができたら、重要画面からワイヤーフレームを作ります。

例えば、

「SCR-003 顧客一覧」

なら、

• ページタイトル
• 検索条件
• 検索ボタン
• 新規登録ボタン
• 顧客一覧テーブル
• ページネーション

などを配置します。

画面一覧 → ワイヤーフレームと段階的に具体化すると、いきなりすべてのUIを細かく設計する必要がありません。

画面一覧から機能漏れを発見する方法

画面一覧を作ったら、実際の業務シナリオを通してみます。

例えば顧客管理なら、

1. 新しい顧客から問い合わせ
2. 顧客を登録
3. 案件を作成
4. 対応内容を記録
5. 案件ステータスを変更
6. 管理者が進捗を確認

と操作します。

その際、

「対応履歴を入力する画面がない」

「案件を完了にする操作がない」

などが見つかれば画面・機能を追加します。

実際の業務を最初から最後まで画面上で再現できるか

を見るのが有効です。

権限ごとに画面一覧を確認する

業務システムでは権限漏れにも注意します。

例えば、

一般ユーザー

• 顧客一覧
• 顧客詳細
• 案件登録

管理者

上記に加えて、

• ユーザー管理
• マスタ管理
• 操作ログ
• システム設定

が必要かもしれません。

一覧表へ権限を入れておけば、

「管理者専用機能を一般ユーザーも利用できる」

といった問題を設計段階で発見しやすくなります。

【コピペ用】画面一覧テンプレート

Excel・Google Sheetsなどへ貼り付けて使える項目です。

画面ID：
画面カテゴリ：
画面名：
画面概要：
利用者：
利用可能な権限：
関連機能ID：
遷移元：
遷移先：
URL：
新規／既存：
優先度：
備考：

表にするなら、次の列がおすすめです。

画面ID	カテゴリ	画面名	概要	利用者	権限	関連機能	備考
SCR-001	共通	ログイン	ユーザー認証	全員	全員	F-001
SCR-002	顧客	顧客一覧	顧客検索・一覧	営業	営業以上	F-010
SCR-003	顧客	顧客詳細	顧客情報表示	営業	営業以上	F-011

画面一覧を作るときのチェックリスト

完成後、次を確認します。

業務

• 主要業務を最初から最後まで操作できるか
• 例外業務を考慮しているか
• 管理者業務を忘れていないか

画面

• 一覧画面はあるか
• 詳細画面は必要か
• 登録・編集画面は必要か
• 削除・確認処理は整理したか
• エラー・完了時の動きを考えたか

権限

• 各画面の利用者を決めたか
• 管理者専用画面を整理したか
• 閲覧のみ・編集可能を区別したか

要件

• すべての機能要件に対応する画面があるか
• 不要な画面がないか
• 対象外機能の画面が混ざっていないか

設計

• 画面IDが一意か
• 命名ルールが統一されているか
• 画面遷移と矛盾していないか

画面一覧でよくある失敗

失敗1｜思いついた画面から書き始める

業務・機能を確認せずに画面名だけ並べると漏れが発生します。

業務 → 機能 → 画面

の順で考えます。

失敗2｜管理画面を忘れる

利用者向け画面だけ考え、

• ユーザー管理
• マスタ管理
• 権限管理
• 操作ログ

などが後から追加されるケースがあります。

失敗3｜一覧・詳細・編集の粒度がバラバラ

一部では登録・編集を別画面にし、別機能では一画面として扱うと見積・設計が分かりにくくなります。

管理ルールを統一します。

失敗4｜権限を書かない

画面は存在するものの、誰が利用できるか決まっていない状態です。

業務システムでは権限を早めに整理します。

失敗5｜画面一覧だけで設計が完了したと思う

画面一覧はあくまで全体像です。

その後、

• ワイヤーフレーム
• 画面項目
• 入力制御
• エラー
• API
• 権限
• データ

などを設計します。

失敗6｜機能一覧との整合性を確認しない

画面はあるのに必要機能が実装できない、あるいは要件に存在しない画面が作られている状態になります。

機能IDと画面IDを紐付けると管理しやすくなります。

画面数が多すぎる場合は統合できないか確認する

例えば、

• 顧客登録
• 顧客編集

を完全に別画面にせず、同じフォームコンポーネントで実装できる場合があります。

また、

• 顧客基本情報
• 顧客案件
• 顧客履歴

をタブ構成にまとめることもできます。

ただし、画面数を減らすこと自体を目的にする必要はありません。

重要なのは、

利用者にとって業務を進めやすい構成か

です。

画面一覧から開発見積にもつなげられる

開発会社へ、

「顧客管理システムを作りたい」

と伝えるだけでは、規模を判断しにくいでしょう。

一方、

• 画面一覧
• 機能一覧
• 権限
• データ量
• 非機能要件

などが整理されていれば、見積精度を高めやすくなります。

例えば、

「管理画面10画面程度」

と、

「一般ユーザー30画面＋管理者20画面」

では開発規模が大きく異なります。

ただし、画面数だけで開発費を算出することはできません。

同じ1画面でも、

• 単純な情報表示
• 複雑な検索
• 大量データ集計
• ファイルアップロード
• AI処理

では開発工数が異なるためです。

画面一覧に関するよくある質問

画面一覧はExcelで作ってもよいですか？

問題ありません。

ExcelやGoogle Sheetsは、フィルタ・並び替え・権限管理などがしやすく、画面一覧との相性がよいツールです。

画面一覧は要件定義書に入れますか？

案件によりますが、要件定義書に画面一覧を含めたり、別紙として管理したりする方法があります。

大規模システムでは別ファイルとして管理した方が更新しやすい場合があります。

画面一覧とサイトマップは同じですか？

似ていますが目的が異なります。

サイトマップはWebサイトのページ構造を整理する用途が中心です。

画面一覧は業務システムにおいて、画面名・利用者・権限・機能など、システム設計に必要な情報を管理する目的で利用されます。

APIしかない機能は画面一覧に入れますか？

画面一覧には通常入れません。

API・バッチ・外部連携などは、機能一覧やインターフェース一覧など別資料で管理します。

そのため、

機能一覧に存在する項目が必ず画面一覧にも存在するわけではありません。

エラー画面も画面一覧に入れますか？

独立したエラー画面があるなら入れる方法があります。

例えば、

• 403 権限エラー
• 404 Not Found
• 500 システムエラー

などです。

一方、入力欄の下に表示するバリデーションエラーまで独立画面として管理する必要はありません。

hiro-dev-labの要件定義・業務システム開発支援

hiro-dev-labでは、Webシステム・業務システムについて、実装だけでなく要件整理・画面設計から対応しています。

例えば、

• 現状業務のヒアリング
• 業務フロー整理
• 業務要件・機能要件整理
• 画面一覧作成
• 画面遷移整理
• ワイヤーフレーム整理
• データ・権限設計
• 非機能要件整理
• 外部API連携
• Java・Python・TypeScriptによるWebシステム開発

などを検討できます。

例えば、

「現在Excelで管理している業務をWebシステム化したいが、どんな画面が必要か分からない」

という段階でも、

現状業務 → 課題 → 必要機能 → 画面一覧 → 画面設計 → 開発

という順番で整理できます。

画面一覧は「画面を数える資料」ではなく「システム全体を整理する資料」

画面一覧を作る目的は、単に、

「このシステムは20画面です」

と数えることではありません。

重要なのは、

• 誰が
• どの業務で
• どの機能を
• どの画面から利用するか

を整理することです。

そのため、画面一覧は、

業務要件 → 機能要件 → UI設計

をつなぐ役割を持ちます。

作成するときは、

1. 利用者を整理する
2. 業務フローを確認する
3. 機能一覧を確認する
4. 必要画面を洗い出す
5. カテゴリ分けする
6. 権限を整理する
7. 機能要件との対応を確認する

という順番がおすすめです。

そして画面一覧ができたら、

画面遷移図 → ワイヤーフレーム → 画面設計

へ具体化していきます。

「必要な機能は整理したが、画面構成が決まらない」

「管理画面の全体像を整理したい」

「Excel業務をどのようなWeb画面にすればよいか分からない」

「要件定義から設計・開発まで相談したい」

といった段階からでも、業務内容をもとに画面構成を整理できます。

要件定義・業務システム開発について相談する