2.要件定義

学習目標

要件定義が、コンセプトを「実現すべき機能と条件」に具体化するフェーズだと説明できる
機能要件・非機能要件・ビジネスルール・制約を区別できる
機能要件をユースケースで表せる
非機能要件を、測定できる形で書ける
MoSCoW で優先順位を付け、MVP で最初に作る範囲を決められる
要件を優先順位とともに要件定義書にまとめられる

企画では、何を・なぜ作るかをコンセプトとして定めました。要件定義では、そのコンセプトを、実現すべき機能と条件に具体化します。本章では、要件を機能要件・非機能要件・ビジネスルール・制約に分けて洗い出し、機能をユースケースで表し、MoSCoW と MVP で最初に作る範囲を決めて、要件定義書にまとめます。

1. 要件定義フェーズ

要件定義は、コンセプトを、作るべき要件に具体化するフェーズです。ここでは、その位置づけと、要件の種類を扱います。

1-1. コンセプトから要件へ

コンセプトは、「誰の・どんな課題を・どう解決し、何を作るか」を短くまとめたものでした。そのままでは、作る人が実装に移れません。コンセプトで描いた解決策を、入力する項目、表示の決まり、満たすべき条件まで具体化する必要があります。

こうして定めた、実現すべき機能と条件を要件と呼びます。要件をまとめた文書が 要件定義書 で、次の設計の前提になります。

1-2. 要件の種類

要件は、いくつかの種類に分かれます。プロダクトが何をできるかを表す 機能要件、操作に現れない条件を表す 非機能要件、そして、プロダクトが守るべきビジネスルールや、外部から決まる制約です。

種類	定める内容
機能要件	プロダクトが何をできるか（ユーザーの操作と結果）
非機能要件	操作に現れない条件（速さ・安全性など）
ビジネスルール・制約	守るべきルールと、外部から決まる前提

機能要件は「何ができるか」、非機能要件は「どれだけ速く、安全に、安定して動くか」を定めます。ビジネスルールと制約は、プロダクトが従うべき決まりと前提を定めます。

例：Stack Overflow では、「質問を投稿する」が機能要件、「検索結果が 2 秒以内に表示される」が非機能要件、「自分の回答には投票できない」がビジネスルールにあたります。

2. 機能要件

機能要件は、ユーザーがプロダクトで何をできるかを定めます。各機能を、アクターとシステムのやり取りとして記述します。これを ユースケース と呼びます。

2-1. ユースケース記述

ユースケースは、次の項目で書きます。基本フローは、利用者の操作とシステムの応答を順に並べたものです。画面やボタンなどの実現方法は、設計で決めます。

ユースケース名：…
アクター：…
事前条件：…
基本フロー：
  1. …
  2. …
代替フロー：…
事後条件：…

例：Stack Overflow の「質問を投稿する」。

ユースケース名：質問を投稿する

アクター：開発者

事前条件：ログインしている

基本フロー：

開発者がタイトルと本文を入力して質問を投稿する

システムが質問を保存し、一覧に表示する

代替フロー：タイトルか本文が空のとき、システムは投稿を受け付けず、入力を促す

事後条件：質問が保存され、一覧と詳細に表示されている

2-2. 機能の洗い出し

プロダクトに必要なユースケースを、アクターごとに洗い出します。漏れがあると、後のフェーズで作るものが足りなくなります。

例：Stack Overflow の主なユースケース。

開発者：ログイン／質問の投稿／回答／投票

閲覧者：質問と回答の閲覧・検索

3. 非機能要件

非機能要件は、機能の動作の質についての条件を定めます。

3-1. 操作に現れない条件

機能要件を満たしても、応答に時間がかかりすぎたり、他人になりすまして操作できたりすれば、実用に耐えません。操作の結果には直接現れないものの、満たされないとプロダクトが成り立たない条件が、非機能要件です。

3-2. 主な非機能要件

非機能要件には、いくつかの観点があります。性能は、応答の速さや、同時に使える人数です。セキュリティは、データの保護や、不正な操作の防止です。可用性は、止まらずに使い続けられることです。プロダクトに応じて、満たすべき観点と水準を決めます。

水準は、測定できる形で書きます。「速い」「使いやすい」では、満たせたかを判断できません。実務では、「どんな状況で・どれくらいの割合で・どの値を満たすか」まで決めます。たとえば「通常の利用で、検索結果の 95% が 2 秒以内に表示される」のように、前提と割合を添えて書きます。

例：Stack Overflow なら、同時に多くのユーザーが使っても検索結果の 95% が 2 秒以内に表示されること（性能）、パスワードを暗号化して保存し、なりすましや不正な連続投票を防ぐこと（セキュリティ）、計画した停止を除き稼働率 99% 以上で動き続けること（可用性）が、非機能要件にあたります。

4. ビジネスルールと制約

機能要件と非機能要件のほかに、プロダクトが従わなければならない決まりと前提があります。

4-1. ビジネスルール

ビジネスルール は、プロダクトが守るべき、操作や状態についての決まりです。誰が何をできるか、データがどんな状態を取りうるかを定めます。機能要件が「できること」を表すのに対し、ビジネスルールは「してはいけないこと」「守るべき条件」を表します。

例：Stack Overflow には、「自分の回答には投票できない」「同じ質問は重複させず、既存の質問へ誘導する」「一定の評価に達するまでは投票や編集ができない」といったビジネスルールがあります。

4-2. 制約

制約は、外部の事情で決まる、変えられない前提です。使う技術、動作環境、守るべき期限などが含まれます。機能や品質をどう実現するかは、この制約の中で考えます。

例：チームで Stack Overflow のようなプロダクトを作るなら、「3 週間で作る」「既習の Spring Boot と MySQL で作る」「主要なブラウザーで動く」といった制約のもとで、要件を絞ります。

5. 優先順位とスコープ

洗い出した要件を、すべて一度に作れるとは限りません。優先順位を付け、最初に作る範囲を決めます。

5-1. 優先順位（MoSCoW）

要件には、なければプロダクトが成り立たないものと、あれば良いものがあります。優先順位の付け方の一つが MoSCoW です。要件を、次の 4 つに分けます。

区分	意味
Must	なければ成り立たない
Should	重要だが、なくても成り立つ
Could	あれば良い
Won't	今回は作らない

例：Stack Overflow では、ユーザー認証と、質問・回答・閲覧、最良の回答が分かるための投票が Must です。採用やタグは Should、評価（reputation）は Could、検索の最適化や高度なモデレーションは Won't と分けられます。

5-2. MVP

Must の要件をそろえ、価値を届けられる最小限のプロダクトを MVP（Minimum Viable Product）と呼びます。多くの機能を一度に盛り込まず、まず MVP を作って動かし、そこから機能を加えていきます。

MVP は、ただ機能を削った最小版ではありません。コンセプトで定めた価値を、最小の機能で満たすものです。

例：Stack Overflow の MVP は、ユーザー認証・質問・回答・閲覧に加えて、投票を含みます。投票を外すと「最良の回答が分かる」という価値が失われ、単なる掲示板になるからです。採用・タグ・評価は、MVP のあとに加えます。

6. 要件定義書

要件定義の成果は、要件定義書という一つの文書にまとまります。その項目とまとめ方を扱います。

6-1. 要件定義書の項目

要件定義書には、機能要件・非機能要件・ビジネスルール・制約を、優先順位とともに記します。ほかの人が読んで開発を始められる文書にします。

項目	内容
概要	何を作るか、どんなプロダクトか
ターゲットユーザー	誰のためか
機能要件	ユースケース記述（アクター・事前条件・基本フロー・代替フロー・事後条件）
非機能要件	性能・セキュリティなどの観点と水準
ビジネスルール・制約	守るべきルールと、外部から決まる前提
優先順位	各要件の MoSCoW 区分
MVP の範囲	最初に作る要件

6-2. 要件のまとめ

例：Stack Overflow の要件をまとめると、次のようになります。

項目	内容
概要	開発者の疑問に最良の回答を届ける、プログラミングの Q&A サイト
ターゲットユーザー	コーディングで行き詰まる開発者と、同じ疑問を検索する開発者
機能要件	ユーザー認証・質問の投稿・回答・閲覧・投票（各機能をユースケースで記述）
非機能要件	通常の利用で検索結果の 95% が 2 秒以内（性能）、パスワード暗号化となりすまし・不正投票の防止（セキュリティ）、稼働率 99% 以上（可用性）
ビジネスルール・制約	自分の回答には投票できない、重複した質問は既存の質問へ誘導する（ビジネスルール）／3 週間・既習の Spring Boot と MySQL で作る（制約）
優先順位	ユーザー認証・質問・回答・閲覧・投票は Must、採用・タグは Should、評価は Could
MVP の範囲	ユーザー認証・質問・回答・閲覧・投票（コンセプトで定めた価値を満たす最小限）

全項目をそろえた要件定義書の実物は、ダウンロードできるサンプルを参照してください。

要件定義書サンプル標準構成のサンプル（Markdown、ダウンロード可）