【C#/Blazor】実務Webアプリ開発編 (14)画面/UI設計 ～画面一覧・遷移図・アクセス制御を設計する～
この記事は、実務Webアプリ開発編の一記事です。前回の「データモデルを設計する」では、User / Mentorship / Topic / Message の4つのエンティティと関連を整理しました。
今回はその続きとして、画面一覧・画面遷移・アクセス制御をどう設計するかを見ていきます。
以下のような方に役立つ内容となっています。
- 要件定義やデータモデルから画面設計へつなげる流れをつかみたい
- 画面設計で何を決めればよいか整理できていない
- ロールごとの表示差分やアクセス制御をどう設計に落とすか知りたい
- 一覧画面と詳細画面の分け方を実例で学びたい
MentorAppを題材として進めます。
GitHubにドキュメント・コードの一式があります。
今回、spec.md における画面設計をみていきます。グローバルメニュー構成、画面遷移、アクセス制御を一緒に整理していきましょう。
画面設計は、見た目を描くだけではありません。誰がどの情報にたどり着き、どこで何を操作するかを整理する作業です。
ここを整理できると、アプリの具体的なイメージがだいぶ固まりますね。一緒に見ていきましょう！
画面設計でやること
画面設計では、どんな画面が必要かと、画面どうしをどうつなぐかを整理します。
あわせて、各画面で何を表示し、誰にどこまで操作を許可するかも決めます。つまり、画面設計は見た目だけではなく、操作の流れと権限の整理でもあります。
前回のデータモデル設計で、MentorApp は User / Mentorship / Topic を中心に情報を扱うことを決めました。
今回の画面設計は、その構造をそのままユーザー操作へつなげる作業です。情報のまとまりが見えていると、どの一覧が必要で、どの詳細画面が必要かを決めやすくなります。
また、要件定義で整理したロールごとの権限も、ここで具体的な画面の見せ方に落とし込みます。
- どんな画面があるか：ログイン・ホーム・一覧・詳細・プロフィールなど、必要な画面を列挙して整理する
- どう移動するか：グローバルメニューや一覧→詳細の流れを決める
- 誰が見られるか：Admin / Mentor / Mentee のアクセス範囲を画面ごとに定義する
画面設計で先に整理しておくと、あとで Blazor コンポーネントで実装を行うとき、ページ分割や認可の方針まで自然に決めやすくなります。
MentorAppのspec.mdを読む
要件定義では、Admin / Mentor / Mentee のロールと、各機能で何ができるかを整理しました。
データモデルでは、User / Mentorship / Topic / Message の関係を整理しました。画面設計は、それらをユーザーがどうたどるかを定義する段階です。
ここでは、spec.md に「何が書かれているか」をまず確認し、そのあとで設計上の判断ポイントを見ていきます。
spec.md の UI設計セクションは、まず全体の設計方針とレイアウトイメージから始まり、グローバルメニュー構成、画面遷移、画面一覧と順に記述されています。
全体の考え方から個別の画面へ、トップダウンの構成になっています。
UI設計方針
spec.md「6. 画面設計 / UI設計方針」に対応します。以下が記載されています。
- ユーザーが「対象（User / Mentorship / Topic）」を起点に操作できるようにする
- 何に対する操作かを先に明確にし、その後で閲覧や編集を行う構成にする（spec.md の補足として記載されている考え方です）
この方針は、画面全体の考え方を一文で表したものです。まず対象を選び、その対象に対して何をするかを決める構成になっています。
MentorApp でいう対象とは、人、メンタリング関係、トピックといった情報のまとまりです。画面の並びもこの考え方に沿って組み立てられます。
画面レイアウトイメージ
spec.md「画面レイアウトイメージ」には、ヘッダ・サイドメニュー・メインコンテンツエリアで構成されたレイアウトのサンプルイメージが示されています。
グローバルメニュー構成
spec.md「6. 画面設計 / グローバルメニュー構成」に対応します。以下が記載されています。
- User メニューは Admin のみ表示する
- Mentorship と Topic は全ロールに表示する
- 各メニューから対応する一覧画面へ移動する
メニューは、ユーザーが最初にどの対象へ進むかを決める入口です。表示条件そのものが、ロールに応じた画面設計の一部になっています。
| メニュー項目 | 表示条件 | 選択時の表示 |
|---|---|---|
| User | Admin のみ | ユーザー一覧 |
| Mentorship | 全ロール | メンタリング一覧 |
| Topic | 全ロール | トピック一覧 |
画面遷移
spec.md「6. 画面設計 / 画面遷移」に対応します。以下が記載されています。
- ログイン成功後にホームへ移動する
- ホームから各一覧画面へ入り、一覧から詳細へ進む
- プロフィール画面にはヘッダーから移動する
画面遷移図では、アプリ全体をどう回遊するかが整理されています。特に、一覧画面を経由して詳細画面へ進む流れが基本になっています。
なお、画面遷移図では Admin 限定の画面に目印がついています。どの経路が Admin のみ入れるかが一目でわかる構成です。
（各画面のアクセス権限の詳細は、次の画面一覧で確認します）
この画面遷移図は主要な遷移を整理した概略図です。実装レベルではログアウト処理やエラー時のリダイレクトなど、さらに細かい遷移も存在します。
画面一覧とアクセス権限
spec.md「6. 画面設計 / 画面一覧」に対応します。以下が記載されています。
- ログイン、ホーム、ユーザー一覧、ユーザー詳細、メンタリング一覧、メンタリング詳細、トピック一覧、トピック詳細、プロフィールを定義している
- 各画面に「種別」「表示内容」「アクセス権限」をセットで定義している
- 認証済みなら見られる画面と、Admin 限定画面を明確に分けている
前回のデータモデルで整理した User / Mentorship / Topic が、そのまま一覧画面と詳細画面の単位になっています。
一方で Message は単独の一覧画面にはせず、Topic 詳細の中で表示する構成です。以下の表は spec.md の画面一覧をもとに整理したものです。
| 画面 | 種別 | 表示内容 | アクセス権限 |
|---|---|---|---|
| ホーム | ダッシュボード | 統計とクイックアクション | 認証済み |
| ユーザー一覧 / 詳細 | 一覧 / 詳細 | User 情報とロール編集 | Admin |
| メンタリング一覧 / 詳細 | 一覧 / 詳細 | Mentorship 情報と状態変更 | 認証済み（Admin は全件表示） |
| トピック一覧 / 詳細 | 一覧 / 詳細 | Topic 一覧、Message 一覧、投稿フォーム | 認証済み（Admin は全件表示） |
| プロフィール | 詳細 | 自分の DisplayName 編集 | 認証済み |
設計上の判断ポイント
ここからは、MentorApp の画面設計で「なぜこの形にしたのか」を整理します。別の選択肢を取った場合に何が起きるかもあわせて見ていきましょう。
ポイント①：対象起点のメニューにして操作の文脈を揃える
MentorApp では、User / Mentorship / Topic という対象そのものをメニュー項目にしています。
この形にすると、ユーザーは「何をしたいか」より先に「何に対して操作したいか」を決められます。対象が先に決まるため、一覧・詳細・編集の流れが自然に組み立てられます。
もし「新規作成」「編集」「管理」のように操作を軸にメニューを並べると、同じ対象に関する機能が複数の場所へ散らばりやすくなります。
たとえば「Topicを編集したい」と思ったとき、「編集」メニューから入るのか「管理」メニューから入るのか迷いが生まれます。
対象起点であれば「Topic」メニューから入ると決まるため、迷いが起きません。
その結果、初心者には「どこから入ればよいか」が分かりにくくなり、ロールごとの差分も把握しづらくなります。
「ユーザー管理」「トピック管理」みたいに対象が見えていると、今どのまとまりを触っているか分かりやすいんだね。
その通りです。対象起点にすると、画面構成とデータ構造の対応関係も崩れにくくなります。
この考え方はオブジェクト指向UI（OOUI）と呼ばれるUI設計の原則に通じています。
「何をしたいか」より先に「何に対して操作するか」を起点にする設計アプローチで、ユーザーが直感的に操作できるUIを実現しやすくなります。
ポイント②：一覧→詳細を基本にして迷いにくくする
各対象について、まず一覧画面があり、そのあとに詳細画面へ進む構成を採用しています。
一覧画面は「どんなデータがあるか」を把握する場所で、詳細画面は「その1件に対して何をするか」を扱う場所です。この役割分担が明確だと、情報量を整理しやすくなります。
もし一覧画面に編集や詳細情報を詰め込みすぎると、画面の責務が曖昧になります。表示項目が増え、操作ボタンも増え、ロールごとの差分も複雑になりやすいです。
MentorApp のように学習用でも実務寄りでもあるアプリでは、一覧と詳細を分けておくほうが、後の実装や保守でも扱いやすくなります。
もちろん、状況に応じて一覧と詳細を1つの画面にまとめるなど、様々な見せ方があります。
実際にユーザーの立場にたったときに、どのように見え・操作できるとわかりやすく・快適であるかを考えながら設計するとよいでしょう。
ポイント③：アクセス制御を画面設計の段階で見える化する
MentorApp では、画面一覧の表にアクセス権限を最初から書いています。
これは重要で、画面設計の時点で「誰に見せるか」を決めておくと、あとで認可の抜け漏れを起こしにくくなります。
もし画面だけ先に作って、権限を後から考えると、「この一覧は誰まで見えてよいか」「この詳細画面の操作ボタンは誰に出すか」が後追いになり、修正コストが増えます。
特に MentorApp は Admin と Mentor / Mentee で見える範囲が違います。だからこそ、アクセス制御は実装の詳細ではなく、画面設計そのものの一部として扱うのが自然です。
画面設計ってレイアウト中心かと思っていたけど、誰に見せるかまで決めるんだね。
はい。どの情報を誰に見せるかは、UI と認可の両方にまたがる重要な設計判断です。
ポイント④：Message を独立画面にせず Topic 詳細へ含める
前回のデータモデル設計では、Message は Topic に属するデータとして整理しました。その構造を踏まえ、Message 一覧と投稿フォームは Topic 詳細画面の中に置いています。
MentorApp はトピック単位のシンプルな会話が目的なので、Topic 詳細の中に収める構成で十分です。
これは、このようなチャットアプリでは標準的な構成ですね。
実際の設計では、データモデルと画面設計は行き来しながら調整することがよくあります。
これは、画面を具体的に考えるほど「このデータが足りない」「この関連が必要」といった気づきが生まれ、データモデルに影響するからです。
逆に、データを整理し直すと「この画面の役割を分けたほうがよい」と気づくこともあります。
まとめ
画面設計では、必要な画面を並べるだけでなく、対象(User / Mentorship / Topic)・遷移・権限をセットで整理することが重要です。
MentorApp では、データモデルで整理した対象をそのまま画面の単位にし、ロールごとの違いをアクセス制御として定義しています。
- 対象起点でUIを組み立てる：User / Mentorship / Topic を入口にすると操作の文脈が分かりやすい
- 一覧→詳細の流れを基本にする：画面ごとの責務が明確になり、情報量を整理しやすい
- アクセス制御を画面設計に含める：誰に何を見せるかを先に決めると、実装時の迷いが減る
- 会話はTopicの文脈で扱う：Message を Topic 詳細へ含めることで、相談のまとまりが見えやすい
次回は、ここまでで整理した要件・システム構成・データモデル・画面設計を踏まえて、クリーンアーキテクチャの考え方を見ていきます。
画面設計は、見た目を整える作業ではなく、操作の流れとアクセス制御を設計に落とし込む作業です。
引き続き、クリーンアーキテクチャについて一緒に学んでいきましょう！
