# 要件定義書テンプレート

> Beekle がシステム開発・AI開発の要件整理で使う考え方を、発注側でも使える形にしたテンプレートです。
> すべてを一枚の文書へ固定する必要はありません。実務では「要求」「機能仕様」「非機能要件・制約」「受入仕様」「未決事項」「設計判断」「変更履歴」を別の管理単位にし、相互にリンクして構いません。
> 最初から全部を埋めるのではなく、次の実装単位を安全に始めるために必要なところから具体化してください。
>
> 書き方の解説: https://beekle.jp/column/requirements-definition-complete-guide

- プロジェクト名: 〈プロジェクト名を記入〉
- 作成者 / 作成日: 〈氏名〉 / 〈YYYY-MM-DD〉
- バージョン: 0.1（ドラフト）

---

## 1. プロジェクト概要

### 1.1 背景・目的（なぜやるか）
〈このシステムで解決したい業務課題と、なぜ今やるのかを2〜3行で記入〉

（記入例）現場が紙とExcelで在庫を管理しており、月末の棚卸しに時間がかかっている。リアルタイムで在庫を把握できる状態を作り、確認作業と欠品判断を改善したい。

### 1.2 成功の定義（何が達成されたら成功か）
〈「何がどうなったら成功」と言えるかを、確認できる形で記入〉

### 1.3 スコープ

**今回やること**
- 〈今回のリリースで作る範囲〉

**今回やらないこと**
- 〈あえて作らない範囲〉

---

## 2. ステークホルダーと意思決定

### 2.1 ステークホルダー一覧

| 役割 | 氏名・部署 | 期待すること / 関わり方 |
| --- | --- | --- |
| 発注責任者 | 〈記入〉 | 〈記入〉 |
| 現場利用者 | 〈記入〉 | 〈記入〉 |
| 情報システム | 〈記入〉 | 〈記入〉 |
| 開発責任者 | 〈記入〉 | 〈記入〉 |

### 2.2 意思決定者と権限
〈仕様変更、予算、リリース可否、セキュリティなどを誰が最終判断するかを記入〉

---

## 3. 要求（Demand）

ここでは、顧客・事業側の「何を実現したいか」「何に困っているか」を正本として残します。
いきなり詳細仕様へ変換せず、要求の由来と目的を失わないことを優先します。

### 3.1 要求一覧

| ID | 要求 / 課題 | 由来 | 期待する価値 | 優先度 |
| --- | --- | --- | --- | --- |
| DEM-01 | 〈例: 気になる商品を後で比較できるようにしたい〉 | 〈営業部〉 | 〈購入判断を支援〉 | 高 |
| DEM-02 | 〈記入〉 | 〈記入〉 | 〈記入〉 | 〈記入〉 |

### 3.2 要求の前提・仮説
〈まだ検証できていない前提があれば記入。事実と仮説を混ぜない〉

---

## 4. 機能仕様（User Story / Use Case）

要求から、「誰が何をできるようになるか」を機能仕様として分解します。
機能仕様を非機能要件や制約と混ぜないようにします。

### 4.1 User Story

基本構文:

```text
As a      〈ユーザー / 業務主体〉
I want to 〈できるようになりたいこと〉
So that   〈得たい価値〉
```

（記入例）

```text
US-01
As a      一般ユーザー
I want to 気になる商品をお気に入り登録したい
So that   後でまとめて比較・購入判断ができる
```

### 4.2 Storyと要求の対応

| Story ID | 元の要求 | 概要 | 状態 |
| --- | --- | --- | --- |
| US-01 | DEM-01 | 商品をお気に入り登録する | Draft |

---

## 5. 非機能要件・制約

### 5.1 非機能要件

| ID | 分類 | 要件 | 検証方法 |
| --- | --- | --- | --- |
| NFR-01 | 性能 | 〈記入〉 | 〈計測条件・テスト方法〉 |
| NFR-02 | セキュリティ | 〈記入〉 | 〈確認方法〉 |
| NFR-03 | 可用性 / 運用 | 〈記入〉 | 〈確認方法〉 |

「高速に」「安全に」「十分な性能で」のような表現だけにせず、必要なら条件・閾値・測定方法まで具体化します。

### 5.2 制約

| ID | 分類 | 制約 | 由来 |
| --- | --- | --- | --- |
| CON-01 | 法務 | 〈記入〉 | 〈法令 / 契約〉 |
| CON-02 | 技術 | 〈既存システム、利用必須技術など〉 | 〈社内方針など〉 |
| CON-03 | 予算・納期 | 〈記入〉 | 〈発注条件〉 |

---

## 6. 受入仕様（Acceptance Criteria / Scenario）

ここでは「何によって完成と判定するか」を定義します。
すべてをGherkinにする必要はありません。具体的な振る舞いを検証したい場合にGiven / When / Thenを使います。

### 6.1 正常系

```text
Scenario: 商品をお気に入り登録する
  Given 一般ユーザーがログインしている
  When 商品「A」をお気に入り登録する
  Then 商品「A」がお気に入り一覧に追加される
```

### 6.2 異常系・境界条件

```text
Scenario: 在庫数を超える出庫は登録できない
  Given 在庫数が1個の商品が存在する
  When 2個の出庫を登録しようとする
  Then 出庫登録は拒否される
  And 在庫数は変更されない
```

正常系だけでは完成判定として不足する場合があります。権限、入力境界、外部API失敗、重複処理、タイムアウトなど、事故になりやすい条件を確認します。

Gherkin解説: https://beekle.jp/column/gherkin-bdd-introduction

### 6.3 StoryとScenarioの対応

| Story ID | Scenario / AC | TestResult | PR / CI | 備考 |
| --- | --- | --- | --- | --- |
| US-01 | SCN-01 | 〈未実施 / Pass / Fail〉 | 〈URL等〉 | 〈記入〉 |

---

## 7. 未決事項・顧客回答

不明点を推測で埋めず、質問として管理します。

| ID | 質問 / 未決事項 | 回答者 | 期限 | 回答 | 変更案 | 確認状態 |
| --- | --- | --- | --- | --- | --- | --- |
| Q-01 | 〈記入〉 | 〈顧客担当者〉 | 〈日付〉 | 〈回答〉 | 〈正本へどう反映するか〉 | 未確認 |

**運用ルール**

顧客回答 → 変更案 → 人間による確認 → 正本へ反映

AIが顧客回答を直接仕様へ上書きすると、回答の文脈を誤解したまま正本へ固定する危険があります。回答と仕様変更を分けて確認します。

---

## 8. 設計判断

要求・仕様そのものと、実現方法の判断を分けます。

| ID | 判断 | 採用理由 | 却下した案 | 関連する要求 / 要件 | 日付 |
| --- | --- | --- | --- | --- | --- |
| ADR-01 | 〈記入〉 | 〈記入〉 | 〈記入〉 | DEM- / NFR- / CON- | 〈日付〉 |

要件や制約が変わったとき、「この設計判断を見直す必要があるか」を追える状態にします。

---

## 9. データ・外部連携・移行

### 9.1 主要データ
〈顧客、注文、在庫などの主要データと関係〉

### 9.2 外部システム / API

| システム | 連携内容 | 認証 | 失敗時の扱い | 担当 |
| --- | --- | --- | --- | --- |
| 〈記入〉 | 〈記入〉 | 〈記入〉 | 〈記入〉 | 〈記入〉 |

### 9.3 データ移行
〈現行システム / Excel等からの移行有無、量、クレンジング、切替方法〉

---

## 10. 変更履歴・影響範囲・Regression

上流情報を変更したら、変更日だけでなく影響範囲を確認します。

| Change ID | 変更内容 | 起点 | 影響するStory | Scenario | Task / 設計 | Test / Regression | 承認 |
| --- | --- | --- | --- | --- | --- | --- | --- |
| CHG-01 | 〈記入〉 | DEM- / Bug / 顧客回答 | 〈記入〉 | 〈記入〉 | 〈記入〉 | 〈記入〉 | 〈記入〉 |

### 不具合を次の仕様へ戻す

重要な不具合は、修正して閉じるだけにしません。

```text
Incident / Bug
  → Root Cause
  → 仕様の不足確認
  → Scenario / Regression Test
  → 次回のQuality Gate
```

同じ種類の事故を、人間の記憶だけで防がないようにします。

---

## 付録A: 仕様をTaskへコピーしない

Taskは実装作業です。仕様そのものをTaskへ丸ごとコピーすると、Story / ScenarioとTaskの両方が正本になり、変更時にずれやすくなります。

推奨:

```text
Demand → User Story → Scenario
                    ↘ Task → PR / CI → TestResult
```

Taskから元のStory / Scenarioへリンクし、完成条件は元の仕様で確認します。

---

## 付録B: StoryからScenarioへの書き分け例

**User Story**

```text
As a      一般ユーザー
I want to パスワードを忘れた時にメールから再設定したい
So that   問い合わせなしで自分でログインを回復できる
```

**Acceptance Scenario**

```text
Scenario: パスワード再設定メールを受け取る
  Given ユーザーが登録済みのメールアドレスを持っている
  When パスワード再設定を申請する
  Then 有効期限付きの再設定リンクがメールで届く

Scenario: 未登録のメールアドレスでも結果が同じに見える
  Given 入力されたメールアドレスが未登録である
  When パスワード再設定を申請する
  Then 登録済みの場合と同じ完了メッセージが表示される
```

Storyは「誰が・何を・なぜ」、Scenarioは「どの条件で何が起き、何をもって完成とするか」を表します。
Scenarioは、必要に応じて自動テストへ接続できます。Scenario自体とテストコードは同じものではありません。

---

## 関連ガイド

- 要件定義 完全ガイド: https://beekle.jp/column/requirements-definition-complete-guide
- 要件定義の進め方: https://beekle.jp/column/requirements-definition-process
- Gherkin / BDD: https://beekle.jp/column/gherkin-bdd-introduction
- RFPの書き方: https://beekle.jp/column/how-to-write-rfp

（本テンプレートは Beekle 株式会社が無償で提供しています。改変・社内利用は自由です。）