第9章要件からドメインを整理する

Webアプリケーションの中心部を作る部である。要件をドメインへ整理し、データベースへ落とし、APIとして公開し、画面を作り、テストとセキュリティを確認する。各章で、その分野の中心になる専門用語を扱う。

この章は、短い要求文を、いきなりDBカラムや画面部品に変えず、後続のデータ設計・API設計・画面設計・テストへ渡せる「設計材料」へ分解する方法を扱う。ここでは、要件整理とドメイン整理で使う、研修の外でも通用する一般的な用語を解説する。

ドメイン

読み：ドメイン（domain）
一言で言うと：その仕事で使う言葉、状態、ルール、例外のまとまり。
くわしく：ソフトウェアは、何かの仕事（業務）を助けるために作る。その仕事の世界で使われる言葉、起こり得る状態、守るべき決まり、例外的なケースをひとまとめにしたものをドメインと呼ぶ。ドメインを整理する目的は、実装者同士の誤解を減らすことである。画面・API・テストで同じものを別の名前で呼んでいると、同じ概念なのか別物なのか分からなくなる。だから設計の前に、まず仕事の言葉と決まりをそろえる。
具体例：支援ステータス機能のドメインには、受講者、メンター、担当受講者、学習ログ、提出、支援ステータスといった言葉が含まれる。これらの意味と関係をそろえてから、DBやAPIの設計へ進む。
つまずきやすい点：ドメインは難しい理論ではなく「その仕事で通じる言葉と決まり」と捉えてよい。逆に、いきなりテーブル名やAPIパスをドメインだと思い込むと、業務の言葉が後回しになる。
関連語：ユースケース（第9章）、用語集（第9章）、ドメインモデル（第9章）、DDD（第9章）
テキスト本文での登場箇所：第9章「ドメインは、仕事で使う言葉と決まりである」

DDD

読み：ディーディーディー（Domain-Driven Design、ドメイン駆動設計）
一言で言うと：業務の言葉と、ソフトウェアの設計を近づける考え方。
くわしく：DDDはDomain-Driven Designの略で、業務（ドメイン）で使う言葉をそのまま設計やコードに反映させ、業務と実装の食い違いを減らそうとする考え方を含む。テーブル名やAPIのfield名、画面の文言、テスト名が、同じ業務用語につながるように設計するのがねらいである。本格的なDDDは大きな理論体系だが、この章ではその入口として、言葉とルールを軽量に整理するところだけを扱う。
具体例：支援ステータス機能で、業務用語「支援ステータス」をコードでも supportStatus に統一し、画面・API・テストで呼び名がずれないようにするのは、DDDの考え方の軽い実践にあたる。
つまずきやすい点：DDDの専門用語（境界づけられたコンテキストなど）を暗唱することが目的ではない。業務の言葉を設計に近づける、という意図を押さえれば十分である。
関連語：ドメイン（第9章）、用語集（第9章）、ドメインモデル（第9章）
テキスト本文での登場箇所：第9章「ドメインは、仕事で使う言葉と決まりである」

機能要求

読み：きのうようきゅう（functional requirement）
一言で言うと：利用者や関係者から出る「こういう機能がほしい」という要望。
くわしく：機能要求は、システムに何をさせたいかを表す要望である。多くの場合、一文の短い形でやってくる。注意したいのは、機能要求と実装方法は別物だということである。要求文の中には、利用者は誰か、目的は何か、誰が何を変えられるか、どこまで作るか、といった多くの判断が隠れている。だから要求文を受け取ったら、すぐ実装名に変えず、まず利用者と目的に戻して中身を取り出す。
具体例：支援ステータス機能の要求は「メンターが、担当受講者に支援ステータスを付けられるようにしたい。」という一文である。短いが、メンターとは誰か、担当受講者とは何か、誰が変更できるか、といった判断を含んでいる。
つまずきやすい点：要求文をそのまま「DBにstatusカラムを足す」のような実装名へ直訳しないこと。値の種類、更新できる人、未設定の扱いなどが決まる前にカラムだけ作っても、設計は終わらない。
関連語：ユースケース（第9章）、受け入れ条件（第9章）、Output / Outcome（第2章）
テキスト本文での登場箇所：第9章「要求文を、すぐ実装名に変えない」

ユースケース

読み：ユースケース（use case）
一言で言うと：誰が何のために何をするかを、一つの流れとして書いたもの。
くわしく：ユースケースは、画面操作の手順書ではない。利用者、目的、事前条件、基本の流れ、例外や分岐、成功条件、今回対象外までを一続きで書く。こう書くと、機能名だけでは見えない前提や例外が表に出てくる。大事なのは画面名や部品名ではなく、利用者の目的である。画面部品は後で変わるかもしれないが、利用者の目的は設計判断の基準として残り続ける。ユースケースは、設計に入る前の地図のような役割を持つ。
具体例：支援ステータス機能なら「メンターが担当受講者の支援状況を確認し、必要ならステータスを変更する。」を出発点に、事前条件（ログイン済み、担当受講者がいる）、基本の流れ（一覧を開く→ステータスを見る→変更する→保存・再表示）、例外（担当受講者がいない、未設定、担当外の変更）、今回対象外（自動アラート、CSV出力）まで分解する。
つまずきやすい点：「セレクトボックスを追加する」のような実装部品で書かないこと。「メンターが支援状況を一覧で確認し、必要な受講者のステータスを変更できる」のように、目的の言葉で書く。
関連語：機能要求（第9章）、受け入れ条件（第9章）、ドメインモデル（第9章）
テキスト本文での登場箇所：第9章「ユースケースは、利用者の動きを一つの流れにする」

用語集

読み：ようごしゅう（glossary）
一言で言うと：チームが同じ言葉を同じ意味で使うための、小さな取り決め。
くわしく：用語集は辞書ではなく、チーム内の小さな契約である。似た言葉を早めに分け、どの言葉が何を指すかをそろえることで、画面の文言、APIのfield名、DBのテーブル名、テスト名、PRの説明が同じ業務用語につながる。これは初心者向けの補助ではなく、設計作業そのものである。迷っている用語は消さず、注意点として残す。迷い自体が、レビューやメンター確認で詰めるべき論点になるからである。
具体例：支援ステータス機能では、未提出（学習ログが未提出の状態）と要支援（メンターが追加支援が必要と判断した支援ステータス）を別概念として分け、コード上の名前候補（learner、mentor、supportStatus など）も並べて書く。
つまずきやすい点：未提出・未対応・要支援・アラート対象のような似た言葉を、同じ意味として混ぜないこと。混ぜると、提出状態と支援ステータスが別物なのか同じものなのか分からなくなり、設計が崩れる。
関連語：ドメイン（第9章）、状態（第9章）、ドメインモデル（第9章）
テキスト本文での登場箇所：第9章「用語集は、チームの小さな契約である」

状態

読み：じょうたい（state）
一言で言うと：対象が今どういう段階にあるかを表す値。
くわしく：状態は、対象の「今の様子」を表す。たとえば支援ステータスが「要支援」なのか「解決済み」なのか、といった値である。状態は、後の設計で保存される値になる可能性が高く、DBカラム、API response、画面表示、テストの期待値につながる。状態を考えるときの注意は、種類を増やしすぎないことである。近い言葉を並べすぎると、利用者がどれを選べばよいか迷う。初回は、判断と運用が続けられる最小の状態から始める。
具体例：支援ステータスの状態候補は、未設定（none／unset）、要支援（needs_support）、支援中（in_progress）、解決済み（resolved）など。意味とコード候補を分けて書いておくと後で扱いやすい。
つまずきやすい点：状態とルールを混同しやすい。「学習ログを提出したら自動で解決済みにする」は状態そのものではなく、状態を変える条件（ルール）であり、採用するかも別判断である。
関連語：イベント（第9章）、ルール（第9章）、用語集（第9章）
テキスト本文での登場箇所：第9章「状態、イベント、ルールを分ける」

イベント

読み：イベント（event）
一言で言うと：状態を変えるきっかけになる出来事。「誰が何をしたか」で表す。
くわしく：イベントは、状態を動かすきっかけになる出来事である。「メンターが支援ステータスを変更した」「受講者が学習ログを提出した」のように、誰が何をしたかの形で書く。状態が「今どうなっているか」なのに対し、イベントは「何が起きたか」である。イベントは後の設計で、APIのrequest、更新日時、監査ログなどに関係する。注意点は、イベントが起きたからといって、必ず状態が変わるとは限らないことである。変わるかどうかはルールで決める。
具体例：支援ステータス機能では、メンターが支援ステータスを変更する、受講者が学習ログを提出する、メンターが支援メモを追加する、などがイベントになる。これらをAPI request やログの設計の手がかりにする。
つまずきやすい点：イベントと状態を同じ表に混ぜて書くと、保存する値（状態）と操作（イベント）の区別が曖昧になる。種類を分けて書く。
関連語：状態（第9章）、ルール（第9章）
テキスト本文での登場箇所：第9章「状態、イベント、ルールを分ける」

ルール

読み：ルール（rule、業務ルール／ビジネスルール）
一言で言うと：いつ、誰が、何をしてよいか・してはいけないかを決める条件。
くわしく：ルールは、操作を許す条件や禁止する条件である。「担当メンターだけが支援ステータスを変更できる」「受講者本人は変更しない」のように、権限や手順の制約を表す。ルールは後の設計で、認可（誰に許すか）、DB制約、APIのエラー、画面の制御、テスト条件につながる重要な材料である。状態・イベントと分けて書くことで、保存する値・起きる出来事・守る制約が混ざらない。便利そうな自動化（イベントで状態を自動変更する等）も、ルールとして切り出すとMVPへ混ぜすぎずに済む。
具体例：支援ステータス機能のルールは「メンターは担当受講者の支援ステータスだけ変更できる」「受講者本人は変更しない」「初回リリースでは自動アラートを作らない」など。担当外の受講者を変更できるかどうかは、必ずルールとして残す。
つまずきやすい点：権限ルールを後回しにすると、担当外の受講者を変更できるかが曖昧なまま実装に入ってしまう。誰が変更できるかは早めに一行で残す。
関連語：状態（第9章）、イベント（第9章）、受け入れ条件（第9章）
テキスト本文での登場箇所：第9章「状態、イベント、ルールを分ける」

スコープ／境界

読み：スコープ（scope）／さかい（boundary）
一言で言うと：今回作る範囲、今回は作らない範囲、後で検討する範囲を分ける線。
くわしく：スコープ（境界）は、その機能で「どこまでやるか」を決める線である。境界が曖昧なまま進めると、小さな機能がすぐ大きくなる。今回作る範囲・今回作らない範囲・後で検討する範囲の三つに分け、対象外には理由も添える。「やらない」とだけ書くと価値を否定したように見えるため、「初回MVPの確認対象ではない」「運用ルールが未確認」のように理由を書くと、後で再検討しやすい。境界はPR本文にも効き、「なぜ通知がないのか」を別の検討事項として扱える。
具体例：支援ステータス機能なら、今回作る＝メンターが担当受講者のステータスを手動更新し一覧で確認できる、今回作らない＝自動アラート・CSV出力・分析ダッシュボード、後で検討＝変更履歴・通知・引き継ぎ・集計、と分ける。
つまずきやすい点：対象外を書くことを「価値を小さくすること」と誤解しやすいが、実際は今回確認したい価値を絞って見えるようにする作業である。
関連語：MVP（第2章）、ユースケース（第9章）、ルール（第9章）
テキスト本文での登場箇所：第9章「境界を決めると、MVPが膨らみにくくなる」

MVP

読み：エムブイピー（Minimum Viable Product）
一言で言うと：最初に価値や前提を確かめるための最小範囲。雑に作ることではない。
くわしく：この章では、境界を決めて初回リリースを膨らませない文脈でMVPが再び登場する。詳しくは →第2章。
具体例：支援ステータス機能なら、初回は手動更新と一覧確認までに絞り、自動アラートや分析は対象外にする。
つまずきやすい点：単なる機能削減版として扱うこと。何を確かめたいかから範囲を決める。
関連語：スコープ／境界（第9章）、Output / Outcome（第2章）、MoSCoW（第2章）
テキスト本文での登場箇所：第9章「境界を決めると、MVPが膨らみにくくなる」

ドメインモデル

読み：ドメインモデル（domain model）
一言で言うと：業務に出てくる主な概念とその関係を表す、DB設計前のたたき台。
くわしく：ドメインモデルは、業務の主要な概念（人・もの・出来事）と、それらの関係を表すメモや図である。最初から厳密なER図を作る必要はなく、主要な言葉と関係の箇条書きで十分である。この段階ではまだテーブル名にしない。目的は完成図を作ることではなく、「この概念はどこに属するのか」という次の問いを見つけることである。後続章で、データ設計へ変換するための材料になる。
具体例：支援ステータス機能では、メンター・受講者・担当・学習ログ・提出・支援ステータス・支援メモを主要概念として並べ、「メンターは複数の受講者を担当する」「受講者は支援ステータスを持つ」のように関係を書く。これにより「支援ステータスは受講者が持つのか、担当関係が持つのか」という問いが見えてくる。
つまずきやすい点：ドメインモデルをDBのER図と取り違えないこと。テーブルにするか既存の関係で表すかは第10章で考える、設計前の地図である。
関連語：ドメイン（第9章）、用語集（第9章）、RDB（第10章）
テキスト本文での登場箇所：第9章「ドメインモデルは、DB設計の前に作る概念の地図である」

受け入れ条件

読み：うけいれじょうけん（acceptance criteria）
一言で言うと：実装が要求を満たしたと言える、具体的な条件。
くわしく：受け入れ条件は、作ったあとに「何を見れば終わったと言えるか」を表す。実装手順（どのボタンをどこに置くか）ではなく、「どの前提で、何をしたら、どんな結果になればよいか」を書く。この粒度なら、API確認・画面確認・テストケースへそのまま変換しやすい。正常系だけでなく、権限や例外も条件として書くと、抜けが減る。受け入れ条件は、PRの確認方法や後続のテスト設計の土台にもなる。
具体例：支援ステータス機能なら「前提: メンターが担当受講者の進捗一覧を開いている／もし: 支援ステータスを要支援に変更する／ならば: その受講者のステータスが保存され、再読み込み後も要支援と表示される」のように書く。権限なら「担当外の受講者は変更できず権限不足として扱われる」を加える。
つまずきやすい点：受け入れ条件を画面部品や実装手順の説明にしてしまうこと。実装後に観察できる結果の形で書く。
関連語：Given / When / Then（第9章）、ユースケース（第9章）、ルール（第9章）
テキスト本文での登場箇所：第9章「受け入れ条件は、完了の見方を決める」

Given / When / Then

読み：ギブン・ウェン・ゼン（Given / When / Then）
一言で言うと：前提・操作・結果の三つに分けて、条件を書く型。
くわしく：Given / When / Then は、受け入れ条件やテストの条件を整理する書き方の型である。Given が前提（どんな状態から始めるか）、When が操作（何をするか）、Then が結果（どうなればよいか）を表す。日本語では「前提・もし・ならば」と書くこともある。前提と操作と結果を分けるので、実装後に観察できる形になりやすく、API確認・画面確認・テストケースへ変換しやすい。正常系・権限・対象外をそれぞれこの型で書くと、確認すべきことが揃う。
具体例：支援ステータス機能の正常系なら「Given メンターが担当受講者の進捗一覧を開いている／When 支援ステータスを要支援に変更する／Then その受講者の支援ステータスが要支援として保存され、一覧で確認できる」となる。
つまずきやすい点：When に複数の操作を詰め込むと、どの操作が結果を生んだか分からなくなる。一つの条件には、なるべく一つの操作で書く。
関連語：受け入れ条件（第9章）、ユースケース（第9章）
テキスト本文での登場箇所：第9章「受け入れ条件は、完了の見方を決める」

第9章 要件からドメインを整理する