---
note: ビジネス要件・業務要件・システム要件と四層の対応表。システム要件=設計という誤解の訂正と、非機能要件の置き場
created: 2026-08-17T17:47:47+09:00
---

# 要件の種類と四層の対応 — ビジネス要件・業務要件・システム要件はどこに置くか

要件定義の書籍・現場では、要件を「ビジネス要件」「業務要件」「システム要件(機能/非機能)」に分類する流儀が広く使われている。本文書は、この分類とハンドブックの四層(要求・要件・仕様・設計)の対応を定め、他流派の用語を自分たちの体系に変換できるようにする。

結論: **分類としては採用しない。対応表で吸収する。** ただしこの分類が照らし出す欠落(非機能要件の置き場)は取り込む。

## 対応表

| 一般的な分類 | 四層での置き場 | 具体的な記載先 |
|---|---|---|
| ビジネス要件 | **要求** | 要求一覧、全体要件の目的・前提 |
| 業務要件 | **要件**(の本体) | 領域別要件のユースケース・業務ルール・管理する情報 |
| システム要件(機能) | **要件〜仕様** | 要件側は受入基準に畳む。振る舞いの詳細は仕様書 |
| システム要件(非機能) | **要件** | 全体要件の非機能節(性能・可用性・セキュリティ・データ保全)。領域固有の性能は各領域の受入基準 |
| 実現方式・構成(アーキテクチャ) | **設計** | 設計書。一般的な本でもこれを「要件」とは呼ばない |

## よくある誤解: 「システム要件=設計」ではない

「ビジネス=要求、システム=設計」という対応づけは半分だけ正しい。ビジネス要件=要求は正しいが、**システム要件は要件〜仕様に跨るものであり、設計ではない**。

混同の出どころは「システム」という語の二義性にある。

- システムの**振る舞い**(主語としてのシステム)→ 要件〜仕様。客先の審査対象
- システムを**作る作業**(対象としてのシステム)→ 設計。受注側の内部判断

システム要件を設計に置くと、機能要件・非機能要件が「受注側の内部判断」の箱に落ち、客先の審査対象から外れる。特に非機能要件(性能・稼働時間・セキュリティ)は客先が決めるべき要件であり、この誤配置は検収時の争点を生む。

層の判定には分類名でなく、いつもの2つの問いを使う。

1. **客先が業務の言葉で正否を判断できるか** — Yes なら要件
2. **この記述が変わる理由は、業務の変化か、作り方の変化か** — 作り方なら仕様以降

## なぜ分類として採用しないか

1. **境界が運用可能でない。** 業務要件/システム要件の線は本によって引き方が揺れる。「客先が業務の言葉で判断できるか」という判定を既に持っている以上、曖昧な境界に乗り換える理由がない
2. **二面記述を誘発する。** この分類で節を分けると、同じ事柄を「業務要件: 担当者は遅延に気づける」「システム要件: システムは遅延アラートを提供する」と両側から書くことになり、二重定義(→必ず食い違う)が構造的に発生する。ユースケース+受入基準の形式は、この二面を1箇所で表現している(ユースケースの主語は業務、受入基準はシステムの振る舞いを業務の言葉で判定する)

## 取り込むもの: 非機能要件の節

システム要件という分類が可視化する実在の欠落は、非機能要件の置き場である。対応は新しい分類の導入ではなく、**全体要件書(または全体要件シート)に非機能の節を1つ追加する**こと。

| 非機能の項目 | 置き場 | 例 |
|---|---|---|
| 性能(全体) | 全体要件の非機能節 | 通常操作の応答時間の許容 |
| 可用性・稼働時間 | 同上 | 業務時間内の稼働、障害時の復旧目標 |
| セキュリティ | 同上 | アクセス制限、認証の失効 |
| データ保全 | 同上 | バックアップ、削除の復旧可否 |
| 性能(領域固有) | 各領域の受入基準 | 「想定規模から対象を特定できる」 |
| 運用・移行 | 全体要件または別文書 | 初期データ投入、切替手順の要件 |

数値・水準はすべて発注者が決定するものであり、初版は要確認だらけのドラフトでよい。要確認として明示されていることが、確認されないまま実装される状態より価値がある。

## 使い方

- 客先・レビュアーが「業務要件書はどこか」「システム要件の一覧が欲しい」と言ったとき、この対応表で自分たちの文書に変換して案内する
- 要件定義の書籍を読むときは、書籍の分類を「工程の成果物リスト」として使い、自分たちの文書への綴じ方は四層で判断する
- 分類名で層を判定しない。判定は常に2つの問い(業務の言葉で判断できるか / 変わる理由は業務か作り方か)で行う

## まとめ

- ビジネス要件=要求、業務要件=要件の本体。ここまでは素直に対応する
- システム要件は要件〜仕様に跨る。**設計ではない**。設計に置くと非機能が客先の審査から外れる
- 分類は採用せず対応表で吸収する。分類による節分けは二面記述と二重定義を生む
- 取り込むのは非機能要件の節(全体要件に1節)のみ

**この記述は誰が審査するのか。** 分類名が何であれ、客先が審査すべき記述が受注側の内部文書に置かれていたら、それは層の誤配置である。