---
title: "要件定義プロセスとは？要求の識別・評価・合意の切り分け"
description: "基本情報技術者試験で問われる要件定義プロセスについて、利害関係者の識別、要件の識別、要件の評価、要件の合意を選択肢で切り分けられるように整理します。"
last_modified_at: "2026-06-29"
canonical_url: "https://stemtazoo.github.io/fe/requirements-definition-process/"
section: "fe"
---

# 要件定義プロセスとは？要求の識別・評価・合意の切り分け

システム開発では、いきなり設計やプログラム作成に入るのではなく、まず「何を実現したいのか」を整理します。

このときに重要になるのが、**要件定義プロセス**です。

基本情報技術者試験では、要件定義そのものの説明だけでなく、

- 利害関係者の識別
- 要件の識別
- 要件の評価
- 要件の合意

のように、活動内容を切り分ける問題が出ることがあります。

この記事では、特に迷いやすい **「要件の識別」「要件の評価」「要件の合意」** の違いを整理します。

---

## まず結論

**要件の識別**とは、利害関係者から要求を引き出し、制約条件や運用シナリオなどを明らかにする活動です。

試験では、次のように切り分けると判断しやすくなります。

| 活動 | 判断キーワード |
|---|---|
| 利害関係者の識別 | 誰が関係するか、誰が参画するか |
| 要件の識別 | 要件を引き出す、漏れなく集める、制約条件、運用シナリオ |
| 要件の評価 | 矛盾、曖昧さ、一貫性、実現可能性 |
| 要件の合意 | 説明する、合意を得る、承認する |

たとえば、

> 利害関係者から要件を漏れなく引き出し、制約条件や運用シナリオなどを明らかにする

とあれば、**要件の識別**です。

---

## 直感的な説明

要件定義プロセスは、ざっくり言うと **「何を作るかを、関係者と一緒に決める作業」** です。

その中でも、要件の識別は **材料集め** に近いです。

たとえば、社内システムを作る場合、利用部門に話を聞いて、

- どんな業務で使うのか
- どんな入力が必要か
- どんな帳票を出したいか
- いつまでに処理したいか
- 使ってはいけない条件はあるか

などを引き出します。

この段階では、まだ「それで本当に作れるか」「矛盾がないか」を細かく確認する前です。

英語で考えると、少しイメージしやすいです。

> identify requirements ＝ 要件を見つけ出す・洗い出す

つまり、**要件の識別は、要件を探して集める段階**です。

---

## 定義・仕組み

要件定義プロセスでは、システム化する範囲や機能について、関係者の要求を整理し、合意できる状態にしていきます。

流れとしては、次のように考えると分かりやすいです。

```text
利害関係者の識別
↓
要件の識別
↓
要件の評価
↓
要件の合意・承認
```

それぞれの役割は次のとおりです。

### 利害関係者の識別

まず、システム開発に関係する人や組織を明らかにします。

たとえば、

- 利用部門
- 管理部門
- システム部門
- 外部委託先
- 承認者

などです。

問題文に **「どの工程でどの関係者が参画するか」** とあれば、利害関係者の識別と考えます。

### 要件の識別

次に、利害関係者から要求を引き出します。

ここでは、

- 業務上必要な機能
- 制約条件
- 運用シナリオ
- 利用者の期待
- システム化する範囲

などを明らかにします。

問題文に **「要件を漏れなく引き出す」「制約条件を明らかにする」「運用シナリオを明らかにする」** とあれば、要件の識別です。

### 要件の評価

集めた要件を確認し、問題がないかを評価します。

たとえば、

- 要件同士が矛盾していないか
- 曖昧な表現がないか
- 実現不可能な内容がないか
- 一貫性があるか

を確認します。

問題文に **「矛盾」「曖昧」「一貫性」「実現可能性」** が出てきたら、要件の評価を疑います。

### 要件の合意

最後に、整理・評価した要件について、関係者と合意します。

ここでは、要件の内容や問題点を説明し、関係者から承認を得ます。

問題文に **「説明する」「合意を得る」「承認する」** とあれば、要件の合意です。

---

## どんな場面で使う？

要件定義プロセスは、新しいシステムを作るときだけでなく、既存システムを改修するときにも使われます。

たとえば、次のような場面です。

- 業務システムを新しく導入する
- 既存システムに機能を追加する
- 手作業の業務をシステム化する
- 外部委託先に開発を依頼する
- 利用部門とシステム部門で認識を合わせる

FE試験では、細かい開発技法そのものよりも、**どの工程で、何をするのか** が問われることがあります。

特に、要件定義は「作る側だけの作業」ではありません。

利用部門、管理部門、承認者など、複数の関係者と確認しながら進める点が重要です。

---

## よくある誤解・混同

### 誤解1：要件の識別と要件の評価を混同する

要件の識別は、要件を **引き出す** 活動です。

要件の評価は、引き出した要件に **問題がないか確認する** 活動です。

| 見分け方 | 活動 |
|---|---|
| 要件を集める、引き出す | 要件の識別 |
| 矛盾や曖昧さを確認する | 要件の評価 |

「漏れなく引き出す」は、評価ではなく識別です。

### 誤解2：要件の評価と要件の合意を混同する

要件の評価は、要件の内容をチェックする活動です。

要件の合意は、評価した結果を関係者に説明し、承認を得る活動です。

| 見分け方 | 活動 |
|---|---|
| 実現可能か、矛盾がないかを確認する | 要件の評価 |
| 関係者に説明し、合意を得る | 要件の合意 |

「合意を得る」と書かれていれば、そのまま要件の合意と判断してよいです。

### 誤解3：要件の識別と利害関係者の識別を混同する

どちらにも「識別」という言葉が出てくるので、ここはひっかけになりやすいです。

| 見分け方 | 活動 |
|---|---|
| 誰が関係するかを明らかにする | 利害関係者の識別 |
| 何が必要かを明らかにする | 要件の識別 |

つまり、

- **人を見つける** → 利害関係者の識別
- **必要なことを見つける** → 要件の識別

と考えると整理しやすいです。

---

## まとめ（試験直前用）

要件定義プロセスの問題では、細かい用語を丸暗記するよりも、**問題文の動詞**に注目すると切り分けやすくなります。

- **誰が関係するか** → 利害関係者の識別
- **要件を引き出す・漏れなく集める** → 要件の識別
- **矛盾・曖昧さ・実現可能性を確認する** → 要件の評価
- **説明して合意・承認を得る** → 要件の合意

FE試験の選択肢では、

> 利害関係者から要件を漏れなく引き出し、制約条件や運用シナリオなどを明らかにする

とあるため、正解は **要件の識別** です。

要件定義の活動を見分けるときは、

```text
人を決める → 利害関係者の識別
要件を集める → 要件の識別
要件をチェックする → 要件の評価
要件を承認する → 要件の合意
```

この順番で思い出すと、選択肢を切りやすくなります。

## 参考

- IPA「試験要綱・シラバスなど」  
  https://www.ipa.go.jp/shiken/syllabus/