要件定義書の読み方
要件定義書は、「何を作るか」「なぜ作るか」を定義したドキュメントです。プロジェクトの最上流で作成され、すべての設計・実装の基になります。
要件定義書とは
役割
- システムの目的・背景を定義
- 機能要件（何ができるか）を定義
- 非機能要件（性能、セキュリティなど）を定義
- 制約条件（予算、期間、技術制限）を定義
いつ使うか
| プロジェクト参加時 | システムの目的を理解 |
| 仕様確認時 | 「なぜこの機能が必要か」を確認 |
| 設計判断時 | 要件に沿っているか確認 |
| テスト時 | 要件を満たしているか確認 |
要件定義書の構成
よくある構成要素
| 項目 | 内容 | 確認ポイント |
|---|---|---|
| プロジェクト概要 | 背景、目的、スコープ | なぜこのシステムを作るのか |
| 現状の課題 | 現行業務の問題点 | どんな問題を解決したいのか |
| システム化の目標 | 達成したいこと | 何を達成すれば成功か |
| 機能要件 | システムが提供する機能 | 何ができればよいか |
| 非機能要件 | 性能、可用性など | どれくらいの品質が必要か |
| 制約条件 | 予算、期間、技術制限 | 何を守らなければならないか |
| 用語定義 | 業務用語の説明 | 専門用語の意味 |
機能要件と非機能要件
機能要件
「システムが何をするか」を定義します。
【機能要件の例】
- ユーザーはメールアドレスとパスワードでログインできる
- 商品を検索して一覧表示できる
- 商品をカートに追加できる
- クレジットカードで決済できる
非機能要件
「システムがどう動くか」を定義します。
| 種類 | 内容 | 例 |
|---|---|---|
| 性能要件 | 処理速度、レスポンス | 画面表示は3秒以内 |
| 可用性 | 稼働率、停止時間 | 稼働率99.9%以上 |
| セキュリティ | 認証、暗号化 | パスワードはハッシュ化 |
| 拡張性 | 将来の拡張 | 月間100万ユーザーまで対応 |
| 保守性 | 運用のしやすさ | ログ出力、監視機能 |
【サンプル】要件定義書の実例
ECサイト構築プロジェクトの要件定義書サンプルです。
基本情報
| プロジェクト名 | ECサイト構築プロジェクト |
| 作成日 | 2024/01/10 |
| バージョン | 1.0 |
| 作成者 | 〇〇株式会社 システム企画部 |
プロジェクト概要
【背景】
現在、当社の商品販売はカタログ通販と実店舗のみで行っている。競合他社がECサイトを展開する中、当社もオンライン販売への参入が急務となっている。
【目的】
オンラインで商品を販売できるECサイトを構築し、新たな販売チャネルを確立する。
【スコープ】
- 商品検索・閲覧機能
- 会員登録・ログイン機能
- カート・購入機能
- 決済機能（クレジットカード）
- 注文管理機能
【スコープ外】
- 実店舗の在庫連携（フェーズ2で対応）
- ポイントシステム（フェーズ2で対応）
現状の課題
| No | 課題 | 影響 |
|---|---|---|
| 1 | 24時間販売ができない | 機会損失 |
| 2 | 若年層へのリーチが弱い | 顧客層の偏り |
| 3 | 電話注文の人件費が高い | コスト増 |
| 4 | 在庫確認に時間がかかる | 顧客満足度低下 |
システム化の目標
| No | 目標 | 指標 | 目標値 |
|---|---|---|---|
| 1 | オンライン売上拡大 | 月間売上 | 1億円以上 |
| 2 | 新規顧客獲得 | 会員登録数 | 月1万人 |
| 3 | コスト削減 | 電話注文件数 | 50%減 |
機能要件
【FR-001】商品検索機能
- キーワードで商品を検索できる
- カテゴリで絞り込みができる
- 価格帯で絞り込みができる
- 検索結果は新着順、価格順でソートできる
【FR-002】会員機能
- メールアドレスで会員登録できる
- メールアドレスとパスワードでログインできる
- パスワードを忘れた場合、再設定できる
- 会員情報（氏名、住所）を変更できる
【FR-003】カート機能
- 商品をカートに追加できる
- カート内の商品数量を変更できる
- カート内の商品を削除できる
- カートの合計金額を表示する
【FR-004】購入機能
- 配送先を入力できる
- 配送方法を選択できる
- クレジットカードで決済できる
- 注文完了メールを送信する
【FR-005】注文管理機能
- 注文履歴を一覧表示できる
- 注文の詳細を確認できる
- 注文をキャンセルできる（出荷前のみ）
非機能要件
【NFR-001】性能要件
| 項目 | 要件 |
|---|---|
| 画面表示 | 3秒以内 |
| 検索レスポンス | 2秒以内 |
| 同時接続数 | 1,000ユーザー |
| 処理件数 | 1日1万件の注文 |
【NFR-002】可用性要件
| 項目 | 要件 |
|---|---|
| 稼働率 | 99.9%以上 |
| 計画停止 | 月1回、深夜3時間以内 |
| 障害復旧 | 4時間以内 |
【NFR-003】セキュリティ要件
| 項目 | 要件 |
|---|---|
| 通信 | HTTPS必須 |
| パスワード | ハッシュ化して保存 |
| クレジットカード | 決済代行会社を利用（自社保持しない） |
| 個人情報 | 暗号化して保存 |
制約条件
| 種類 | 制約 |
|---|---|
| 予算 | 5,000万円以内 |
| 期間 | 2024年10月リリース |
| 技術 | 既存インフラ（AWS）を活用 |
| 運用 | 社内で運用できる体制 |
用語定義
| 用語 | 説明 |
|---|---|
| 会員 | 本サイトに登録したユーザー |
| ゲスト | 会員登録せずに購入するユーザー |
| SKU | 商品の最小管理単位（色・サイズ別） |
| 出荷 | 倉庫から商品を発送すること |
読み方のポイント
1. 目的・背景を最初に理解する
- なぜこのシステムを作るのか
- どんな課題を解決したいのか
- 成功の基準は何か
→ 目的を理解すると、仕様の意図が分かる
2. スコープを確認する
- 何が含まれるか
- 何が含まれないか
→ スコープ外を実装しないよう注意
3. 機能要件を把握する
- どんな機能があるか
- 各機能で何ができるか
- 機能間の関連は何か
4. 非機能要件を確認する
- 性能はどれくらい必要か
- セキュリティ要件は何か
→ 実装・テストに影響する
5. 用語を確認する
- 業務用語の意味を把握
- 設計書で使われる用語と照らし合わせる
よくある疑問
Q: なぜ要件定義書を読む必要があるか？
設計書だけでは「なぜその仕様になっているか」が分かりません。要件定義書を読むと、仕様の背景が理解でき、適切な実装判断ができます。
Q: 要件と仕様の違いは？
- 要件：「何を実現したいか」（What）
- 仕様：「どう実現するか」（How）
例：
- 要件：「商品を検索できる」
- 仕様：「キーワードをLIKE検索で部分一致」
Q: 要件にない機能を追加していいか？
基本的にはNGです。追加したい場合は、要件定義者に確認して要件を更新します。
1年目エンジニアとしての関わり方
| 場面 | やること |
|---|---|
| プロジェクト参加時 | 要件定義書を通読して全体像を把握 |
| 設計理解時 | 「なぜこの機能が必要か」を要件から確認 |
| 実装時 | 要件を満たす実装になっているか確認 |
| テスト時 | 要件に書かれた機能が動作するか確認 |
ポイント：要件定義書は「お客様との約束」です。要件を満たさないシステムは、どんなに技術的に優れていても「失敗」です。
関連ドキュメント
- 設計書・仕様書の読み方 - 設計書全般の読み方
- 基本設計書の読み方 - 設計書の詳細