第2章
要件定義の進め方 — 機能要件と非機能要件を整理する
約6分
この章の目次開く
設計のスタート地点は「何を作るか」を明確にすることです。 これが曖昧なまま設計に入ると、テーブル設計もAPI設計も「たぶんこうだろう」という推測の上に成り立つことになり、後から覆ります。
この章では、要件定義で整理すべき項目と、実務でよくある抜け漏れパターンを紹介します。
学習者要件定義って偉い人がやるイメージ…。エンジニアもちゃんと考える必要があるの?
先生むしろエンジニアが参加しないと「技術的に実現困難な要件」や「非機能要件の抜け漏れ」に後から気づくことになる。設計フェーズで最もコストが低い工程だから、ここに時間をかける価値は大きいよ。
機能要件と非機能要件
要件は大きく2種類に分かれます。
| 種類 | 説明 | 例 |
|---|---|---|
| 機能要件 | システムが「何をするか」 | ユーザー登録ができる、商品を検索できる |
| 非機能要件 | システムが「どう動くか」 | レスポンス3秒以内、99.9%稼働、同時1000ユーザー |
駆け出しのうちは機能要件ばかりに目が行きがちですが、非機能要件の抜け漏れが本番障害に直結することは珍しくありません。

要件の洗い出し方
ユースケースから逆算する
「ユーザーが〇〇するとき」を列挙して、必要な機能を導き出します。
ECサイトの例:
1. ユーザーが商品を検索する → 検索機能、フィルター、ソート
2. ユーザーがカートに追加する → カート管理、在庫チェック
3. ユーザーが購入する → 決済、注文作成、在庫減算
4. ユーザーが注文履歴を見る → 注文一覧、詳細表示
5. 管理者が商品を登録する → 管理画面、画像アップロード
6. 管理者が注文を処理する → ステータス変更、出荷処理画面モックから洗い出す
画面モック(ワイヤーフレーム)があるなら、画面単位で必要なデータと操作を列挙します。
商品一覧画面:
- 表示するデータ: 商品名、価格、画像、在庫有無
- 操作: 検索、カテゴリフィルター、価格ソート、ページネーション
- 状態: ログイン済みなら「お気に入り」ボタンを表示非機能要件のチェックリスト
非機能要件は漏れやすいため、カテゴリ別にチェックします。
| カテゴリ | チェック項目 | 例 |
|---|---|---|
| 性能 | 同時アクセス数、レスポンスタイム | 同時1000人、API 500ms以内 |
| 可用性 | 稼働率、メンテナンス頻度 | 99.9%、月1回深夜メンテ |
| セキュリティ | 認証方式、データ暗号化、監査ログ | JWT、個人情報は暗号化 |
| スケーラビリティ | 将来のデータ量、ユーザー数の見込み | 1年後に10万ユーザー想定 |
| 運用・保守 | ログ、モニタリング、バックアップ | 日次バックアップ、7日保持 |
| 互換性 | 対応ブラウザ、デバイス | Chrome/Safari最新2バージョン |
よくある抜け漏れパターン
学習者要件定義で「あとで考える」って先送りにしたら、実装中に大問題になったことがあります…。
削除の仕様
「ユーザーが退会したらどうなるか」「商品を削除したら注文履歴はどうなるか」は最初に決めておかないと、テーブル設計に影響します。
| 検討ポイント | 選択肢 |
|---|---|
| 削除方式 | 論理削除(deleted_at)か物理削除か |
| 関連データ | CASCADE削除か、参照を残すか |
| 復元可能性 | 管理者が復元できるようにするか |
| 表示上の扱い | 「退会済みユーザー」と表示するか、名前を匿名化するか |
権限
「誰が何をできるか」を定義しないままAPI設計に入ると、後から認可ロジックを差し込むことになります。
ロール定義の例:
- 管理者: 全操作可能
- 編集者: 記事の作成・編集・自分の記事の削除
- 閲覧者: 閲覧のみ
- ゲスト: 公開記事の閲覧のみエラー時の振る舞い
正常系だけでなく、異常系の振る舞いも要件として定義します。
| 場面 | 決めるべきこと |
|---|---|
| 決済失敗 | 在庫を戻すか?再試行は何回? |
| API タイムアウト | リトライするか?ユーザーに何を表示? |
| 二重送信 | 冪等性をどう保証するか? |
| 同時編集 | 先勝ちか後勝ちか?楽観ロックか? |
メール・通知の要件
通知設計の例:
- 会員登録完了メール(即時、テンプレート必要)
- 注文確認メール(即時、注文内容を含む)
- 出荷完了メール(ステータス変更時)
- パスワードリセットメール(有効期限付きリンク)
- 管理者向けアラート(在庫切れ時)要件定義書のまとめ方
要件定義の成果物は、チームとクライアントの合意文書です。
■ プロジェクト概要
目的、背景、スコープ
■ 機能要件一覧
ID | 機能名 | 概要 | 優先度 | 備考
F-001 | ユーザー登録 | メールアドレスとパスワードで登録 | 必須 |
F-002 | ソーシャルログイン | Google, GitHubで認証 | 任意 |
■ 非機能要件
性能、可用性、セキュリティ、運用の各項目
■ 用語定義
「ユーザー」「管理者」「注文」など、プロジェクト内で統一する用語
■ 制約条件
予算、期限、技術制約、法的制約
■ 未決事項
検討中の項目と期限ちゃんと使うためのポイント
- 機能要件だけでなく非機能要件(性能・可用性・セキュリティ)を必ず確認する
- 「正常系」だけでなく「異常系」「境界値」の振る舞いも要件として定義する
- 削除の仕様、権限、通知は初期段階で決めておかないとテーブル設計から影響する
- 要件が曖昧なまま設計に進むと、設計の手戻りではなく実装の手戻りになる
- 「未決事項」を明示して先送りにしたことを可視化しておく
次の章では、要件をもとに行う基本設計と詳細設計の2つのフェーズを整理します。