【C#/Blazor】実務Webアプリ開発編 (11) 要件定義の書き方 ～ロール・機能・非機能・対象外をどう整理するか

実務Webアプリ開発編です。 前回の「ソフトウェア開発の全体像」では、要件定義からデプロイまでの流れを俯瞰しました。

今回から Part II「要件定義と設計」に入り、最初に「何を作るか」を言葉で定義する要件定義を扱います。

題材は MentorApp の spec.md です。この記事では、ユーザーロール・機能要件・対象外機能・非機能要件をどう切り分けるかを学びます。

以下のような方に役立つ内容となっています。

MentorAppのドキュメント・コード一式はGitHubに置いてあります。

要件定義でやること

要件定義とは、誰が使い、何ができて、今回は何をやらないかを決める活動です。

ざっくりでもここを整理しておくと、設計や実装の段階で「誰向けの機能か」を迷いにくくなります。

MentorApp では、要件定義の成果物を spec.md にまとめています。

箇条書きのメモで十分です。ただ、あとで「なぜこう決めたか」を見返せるようにしておくと、設計や実装の段階でかなり助かります。

小さな個人開発でも、これがあるだけで「あとで何を足すべきか」「今は何を切るべきか」が見えやすくなります。

MentorAppのspec.mdを読む

MentorApp のspec.mdにおける「1.目的・背景」、「2.システム概要」を見ていきます。

続いて、「3.要件定義」の中身を分解しながら読んでいきましょう。

なぜ作るのかを書いておく

spec.md「1. 目的・背景」に対応します。以下が記載されています。

機能一覧を書く前に、なぜこのアプリを作るのかを一言残しておくと、後の判断がブレにくくなります。

「この機能、本当に必要？」と迷ったとき、目的に立ち返れるからです。フォーマルな目的・背景セクションでなくても、一文メモしておくだけで十分です。

ユーザーロールを最初に決める

spec.md「2. システム概要」に対応します。

ユーザーロールと主要機能の概略として、以下が記載されています。

この定義で重要なのは、誰がどこまで操作できるかを最初に切り分けている点です。

たとえば Admin を「何でもできる参加者」としてしまうと、「どの画面を誰に見せるか」「誰がどの操作をしてよいか」が曖昧になりやすくなります。

MentorApp では、Admin はあくまで管理者です。Mentor と Mentee はどちらも対話の当事者ですが、Mentor は指導する側、Mentee は指導を受ける側という違いがあります。

この線引きが後の設計をシンプルにします。

ロール	主な責務	設計上の意味
Admin	ユーザー・関係性・全体状態の管理	運用ルールを担う
Mentor	指導・フィードバック、メンタリング終了の判断	業務の主体になる
Mentee	相談、振り返り	価値提供の受け手であり参加者

機能要件は「誰が・何を・どう操作できるか」で整理する

spec.md「3. 要件定義」に対応します。

機能要件の要点として、以下が記載されています。

MentorApp の要件定義は、単に「チャットができる」とは書いていません。誰が（ロール）・何を（対象）・どう操作できるのか（操作）を分けて書いています。

なかでもロールは「誰が何をしてよいか」を決める最も重要な条件で、この3つの軸が、あとで画面やAPIを考えるときの土台になります。

対象	主な操作	ポイント
ユーザー管理	一覧表示、表示名編集、ロール変更	Admin による管理と、本人による編集を分ける
メンタリング管理	登録、一覧表示、状態変更、削除	Admin が関係性のライフサイクルを管理する
トピック管理	作成、一覧表示、クローズ	Mentor / Mentee が相談をテーマ単位で整理する
メッセージ管理	投稿、閲覧	Mentor / Mentee が追記のみで履歴を保つ
認証・認可	ログイン、初回登録、アクセス制御	ロールに応じたアクセス制御で利用開始の入口を定義する
初期データ	Admin 自動作成、既存時スキップ	最初の管理者を安全に用意する

特に良いのは、「できること」だけでなく「条件付きでできること」も書いている点です。

たとえばトピック作成は「自分が関係する Active 状態のメンタリング」に限定されています。これだけで業務ルールがかなり明確になります。

また、メンタリング削除も無制限ではありません。Topic が存在しない場合のみと書かれているため、履歴の整合性を守る意図が読み取れます。

認証と初期データも要件に含める

spec.md「3. 要件定義」に対応します。

認証・認可と初期データの要点として、以下が記載されています。

要件定義というと、画面で見える機能だけを書きたくなります。

ですが実際には、誰がどうやって利用を始めるかも重要な要件です。ログイン方法や初回登録の流れが曖昧だと、実装の入口で迷います。

MentorApp では、一般ユーザーは初回ログイン時に Mentee として作られます。一方で Admin は設定ファイルから先に用意されます。

この分離により、最初の管理者を誰が作るのかという問題を避けつつ、通常ユーザーには最小権限で入ってもらえます。

対象外機能を書くとスコープが安定する

spec.md「3. 要件定義」に対応します。

対象外機能の要点として、以下が記載されています。

要件定義を最初に書いたときのよくある間違いとして、「やりたいこと」を全部入れてしまうということがあります。

しかし実際には、何を作るかと同じくらい、今回は何を作らないかを決めることが重要です。

MentorApp では、将来展望として AI 活用を見据えつつも、今回の開発（この学習シリーズの範囲）では扱わないと切っています。

この判断があるおかげで、現在の開発では「まずメンタリングの基本体験を成立させる」ことに集中できます。

非機能要件の扱いを明示する

spec.md「3.2 非機能要件」に対応します。以下が記載されています。

非機能要件とは、「何ができるか」ではなく、「どれくらいの品質で動くか」を定める要件です。性能・可用性・セキュリティ・保守性などが代表的な観点です。

実務では、非機能要件がシステム構成を大きく規定します。「レスポンスが○秒以内」「障害時に○分以内に復旧」といった要件が、インフラ選定やアーキテクチャに影響します。

また、後から気づいても手戻りが大きくなりやすく、場合によっては手遅れになるのが非機能要件の特徴です。

MentorApp では学習用途のため、今回は対象外と明示しています。これは今の目的にスコープを絞った判断です。

設計上の判断ポイント

ここからは、MentorApp の要件定義を読んだときに見えてくる設計上の意図を整理します。

Admin を「参加者」ではなく「管理者」に分けている

Admin が Mentorship に参加しない設計は、かなり重要です。

もし Admin も会話参加者にすると、管理権限と業務上の当事者権限が混ざり、アクセス制御が複雑になります。

役割を明確に分けることで、UI でもドメインでも「管理」と「対話」を別の責務として扱えます。

メッセージを追記のみとし、編集・削除を外している

メッセージ機能で「編集・削除は行わない」と明示しているのも、スコープを安定させる良い判断です。

チャットの編集や削除を認めると、監査性、表示制御、競合、通知など考えることが一気に増えます。

対話履歴が順番に積み上がるという基本形は、設計としても明快で、最初に抑えるべき構造です。編集・削除は将来的に必要に応じて拡張する判断でも十分でしょう。

初期管理者を先に用意する設計で運用を始めやすくしている

認証まわりで見逃しやすいのが、最初の Admin をどう作るかという点です。

MentorApp では、設定ファイルに書かれた ExternalId のユーザーを起動時に Admin として作成します。

これにより、「管理者がいないから管理者を作れない」という詰まり方を避けられます。地味ですが、実運用では大事な判断です。

補足：要件の観点をもっと網羅したい場合

「何を要件として挙げるべきか」の網羅性を確認したいときは、補助線として標準的な資料を見るのも有効です。

まとめ

今回、要件定義について解説をしました。ポイントは以下です。

要件定義は、あとで迷ったときに立ち返れる地図を作る作業です。

決めたことを言葉にして残しておくことで、設計も実装も迷いにくくなります。

次回は、この要件をもとに システム構成を設計する 段階へ進みます。ブラウザ、Blazor Server、データベース、認証基盤の関係を整理していきましょう。