この記事の要点

要件定義 = システムが何を実現すべきかを確定する工程。後工程の設計・実装の前提となる 機能要件 (やること) と 非機能要件 (性能/可用性/保守性/セキュリティ) を分けて整理 ヒアリング → 業務フロー (BPMN) → ユースケース / ユーザーストーリー → Acceptance Criteria の流れ 優先度付け: MoSCoW (Must/Should/Could/Won't)、見積り: INVEST 原則 進め方: ウォーターフォールは要件定義書を完成させてから設計、アジャイルは継続的にバックログを更新

要件定義とは

要件定義 (Requirements Definition) は、システム開発の最上流工程で、「何を作るか」を確定する段階です。誰のための、どんな課題を、どこまで解決するシステムなのかをステークホルダー全員の合意として文書化します。要件定義の質が後工程の手戻りコストを直接左右します。

要件の分類: 機能要件 vs 非機能要件

分類	意味	例
機能要件 (Functional)	システムが提供する具体的な機能	「顧客は商品をカートに入れて決済できる」
非機能要件 (Non-Functional / NFR)	機能の実現の仕方・品質特性	「ピーク時 1000 同時アクセスで応答 1 秒以内」

非機能要件の代表分類 (FURPS+)

分類	例
Functionality (機能性)	セキュリティ、相互運用性
Usability (使いやすさ)	UI / UX、アクセシビリティ (JIS X 8341)
Reliability (信頼性)	稼働率 99.9%、MTBF、MTTR
Performance (性能)	応答時間、スループット、TPS
Supportability (保守性)	ログ、監視、CI/CD
+ (制約)	法規制、技術的制約、運用制約

要件定義の進め方

1. ステークホルダー特定: 業務責任者、エンドユーザー、運用、IT 管理、法務、外部関係者
2. ヒアリング: 個別インタビュー / グループワークショップ / 観察
3. 業務フロー図化: As-Is (現状) と To-Be (理想) を BPMN 等で図示
4. ユースケース / ユーザーストーリー: 利用者視点でシステムが提供する価値を記述
5. Acceptance Criteria: 完成判定基準を具体化
6. 優先度付け: MoSCoW で Must / Should / Could / Won't に振り分け
7. 要件定義書化 / 合意: ステークホルダーレビューで承認

業務フロー: BPMN の例

[顧客] ──注文─→ [営業] ──登録─→ (DB) ──通知─→ [倉庫] ──出荷─→ [顧客]
                     │                              │
                     └──支払依頼→ [経理] ←─着金確認─┘

主な記号 (BPMN 2.0):
 ○ : 開始/終了イベント
 □ : タスク (アクティビティ)
 ◇ : ゲートウェイ (分岐/合流)
 → : シーケンスフロー
 ✉ : メッセージフロー

ツール: draw.io / Cacoo / Lucidchart / Bizagi Modeler

ユースケース図とユースケース記述

[ユースケース図]
   ┌────────────┐
   │ ECサイト   │
   │  ┌─────┐   │
顧客 ─┤ 注文する │
   │  └─────┘   │
   │  ┌─────┐   │
   │  │決済する│  │ (include)
   │  └─────┘   │
   └────────────┘

[ユースケース記述: 注文する]
 名前       : 注文する
 アクター   : 顧客
 事前条件   : ログイン済、カートに商品あり
 基本フロー :
   1. 顧客が「注文確定」を押下
   2. システムは在庫を確認
   3. システムは決済フローを起動
   4. システムは注文を確定し注文番号を表示
 例外フロー :
   2a. 在庫切れ → エラーメッセージ表示し終了
   3a. 決済失敗 → 再入力画面
 事後条件   : 注文がDBに記録され、顧客に確認メール送信

ユーザーストーリー & Acceptance Criteria

アジャイル開発で使われる軽量フォーマット。「誰が、何を、なぜ」を 1 文で書きます。

[ユーザーストーリー]
  As a 顧客
  I want カート画面で数量を変更できる
  So that 買いすぎを防げる

[Acceptance Criteria (受入基準)]
  Given カートに商品Aが2個入っている
  When 数量を3に変更して「更新」を押下
  Then 合計金額が再計算され、3個の在庫が引当てされる

  Given カートに商品Aが2個入っている
  When 数量を0に変更
  Then 商品Aがカートから削除される

  Given 在庫が1個しかない商品B
  When 数量を5に変更
  Then エラー「在庫が不足しています」を表示

INVEST 原則

I	意味
Independent	他ストーリーに依存せず独立して実装可能
Negotiable	詳細は交渉可能 (契約書ではない)
Valuable	ユーザー価値がある
Estimable	見積もり可能 (粒度が適切)
Small	1 スプリント内に終わるサイズ
Testable	テスト可能な受入基準がある

優先度付け: MoSCoW

記号	意味	例
M (Must)	必須。これが無いと提供価値ゼロ	ログイン、決済
S (Should)	重要だが代替手段あり	パスワードリセット
C (Could)	あると良いが優先度低	ダークモード
W (Won't)	今回はやらない (記録は残す)	多言語対応 (Phase 2)

要件定義書サンプル目次

1. 概要
  1.1 プロジェクト背景
  1.2 目的 / ビジネスゴール
  1.3 ステークホルダー
  1.4 スコープ (含む/含まない)
  1.5 用語定義

2. 業務要件
  2.1 As-Is 業務フロー
  2.2 To-Be 業務フロー
  2.3 変更点と効果

3. 機能要件
  3.1 機能一覧
  3.2 ユースケース図
  3.3 ユースケース記述 (機能ごと)
  3.4 画面遷移図

4. 非機能要件
  4.1 性能 (応答時間/スループット)
  4.2 可用性 (稼働率/MTTR)
  4.3 セキュリティ (認証/権限/暗号化)
  4.4 拡張性
  4.5 運用 / 保守性

5. データ要件
  5.1 主要エンティティ (ER 図)
  5.2 データ量 / 増加見込み
  5.3 移行データ

6. インフラ要件
  6.1 想定アクセス
  6.2 構成案 (オンプレ / クラウド)
  6.3 監視 / バックアップ

7. 制約事項
  7.1 法規制 (個人情報保護法、PCI-DSS 等)
  7.2 既存システム連携

8. リスクと前提
9. スケジュール
10. 承認

ウォーターフォール vs アジャイル

項目	ウォーターフォール	アジャイル
成果物	要件定義書 (完成版)	プロダクトバックログ (継続更新)
変更対応	変更管理プロセス必要	スプリントごとに見直し
合意のタイミング	工程最後にレビュー → 承認	スプリント毎に Demo
粒度	詳細・網羅的	概要 + 直近のみ詳細
適性	規制業界・大規模	不確実性高い・スタートアップ

ツール

• Atlassian Jira: ユーザーストーリー / バックログ管理
• Confluence: 要件定義書・仕様書
• Notion: 軽量プロジェクト向け要件管理
• draw.io / Cacoo / Lucidchart: BPMN / ユースケース図
• Figma: 画面モックアップ・遷移図
• Miro / Mural: ヒアリングワークショップ

よくある失敗

• NFR の抜け漏れ: 「速くて安定」だけでは曖昧。具体数値が必要
• ステークホルダーの抜け: 運用部署を呼ばずリリース後にトラブル
• スコープクリープ: 「ついでにこれも」で膨張 → MoSCoW で歯止め
• 業界用語の曖昧さ: 同じ単語で異なる意味 → 用語定義必須
• As-Is スキップ: 現状把握なしに To-Be を作って業務破綻

FAQ

Q: 要件定義と要求定義の違いは？
A: 要求 (Requirement) = ユーザーが「欲しい」と言うこと。要件 = 開発側が「実現する」と確定したこと。要求は曖昧でも OK、要件は具体的・検証可能でなければならない。

Q: 非機能要件、どこまで書く？
A: IPA の「非機能要求グレード」が参考になります。性能・可用性・セキュリティ・移行・運用・システム環境の 6 大項目をレベル分けで定義する手法。

Q: 顧客が要件を確定できない
A: プロトタイプ (Figma / Sketch) を作って実物を見せながら詰める。アジャイルなら最小機能セットで早期リリースして反応を見る。