最終更新日:2026年6月6日
sg sg-strategy system_planning project_management system_strategy
まず結論
要求定義プロセスとは、システムに関係する利害関係者を識別し、そのニーズ、要望、制約条件を整理して、システムに求めることを明確にする工程です。
SG試験では、要求定義を「システムを作る工程」として覚えるよりも、関係者が何を求めているかを明確にする工程として押さえると判断しやすくなります。
選択肢では、次のように切り分けます。
- 利害関係者、ニーズ、要望、制約条件 → 要求定義
- 事業目的、システム化方針、実施計画 → 企画
- 機能、能力、方式設計、実現方式 → システム開発
- 製品・サービスの取得、適格性確認 → 実装・取得
- 稼働後の変更、修正、維持 → 保守
直感的な説明
要求定義は、家を建てる前に「住む人が何を求めているか」を聞き出す段階に近いです。
たとえば、家を建てるときに、いきなり設計図を書き始めると失敗しやすくなります。
先に確認すべきことがあります。
- 誰が住むのか
- どんな生活をしたいのか
- 何部屋必要なのか
- 予算や土地の制約は何か
- 将来、家族構成が変わる可能性はあるか
これらを整理してから、設計に進みます。
システムでも同じです。
利用部門、経営層、情報システム部門、運用担当者、委託先など、関係者によって求めることが違います。
要求定義プロセスでは、それらの要求を整理し、後続の設計や開発で迷わないようにします。
定義・仕組み
要求定義プロセスでは、目的とするシステムについて、利害関係者の要求を明確にします。
主に確認するのは、次のような内容です。
| 観点 | 確認すること |
|---|---|
| 利害関係者 | 誰がシステムに関係するか |
| ニーズ | 何に困っているか、何を実現したいか |
| 要望 | どのような機能や使い方を求めているか |
| 制約条件 | 予算、納期、法令、既存システム、セキュリティ条件など |
| 優先度 | どの要求を優先するか |
ここで重要なのは、要求定義が単なる「要望のメモ」ではないことです。
利害関係者の要求を整理し、矛盾や抜け漏れを確認し、後続工程で使える形にしていきます。
情報セキュリティマネジメント試験では、システム企画、システム開発、プロジェクトマネジメントなども出題範囲に含まれます。公式の出題内容は、IPAの情報セキュリティマネジメント試験 出題範囲で確認できます。
どんな場面で使う?
要求定義プロセスは、新しいシステムを導入したり、既存システムを大きく変更したりするときに使います。
たとえば、次のような場面です。
- 業務システムを新しく導入する
- 既存システムをクラウド化する
- 利用者認証を強化する
- 申請・承認ワークフローを見直す
- 外部委託先に開発を依頼する前に、必要条件を整理する
SG試験では、要求定義を「利用者の希望を聞くだけ」と狭く考えないことが大切です。
要求定義では、利用者だけでなく、運用担当者、管理者、経営層、セキュリティ担当者、委託先など、複数の利害関係者を考えます。
特にセキュリティに関係するシステムでは、次のような要求も整理対象になります。
- アクセス権限をどう管理するか
- ログをどの範囲で取得するか
- 個人情報をどう保護するか
- 障害時にどの程度の時間で復旧するか
- 委託先にどのセキュリティ条件を求めるか
要求定義で整理した内容は、後続の設計、開発、テスト、運用の判断材料になります。
よくある誤解・混同
企画プロセスとの違い
企画プロセスは、事業目的や目標を達成するために、システム化の方針や実施計画を立てる段階です。
一方、要求定義プロセスは、そのシステムに対して利害関係者が何を求めているかを明確にする段階です。
| 工程 | 見るポイント |
|---|---|
| 企画 | 事業目的、目標、システム化方針、実施計画 |
| 要求定義 | 利害関係者、ニーズ、要望、制約条件 |
選択肢で「事業の目的・目標」「システム化の方針」「実施計画」とあれば、要求定義ではなく企画プロセスを疑います。
共通フレーム2013での企画・要求定義・開発・運用の切り分け
共通フレーム2013の問題では、作業名がどのプロセスに属するかを問われることがあります。個別の用語を丸暗記するより、作業の目的で整理すると判断しやすくなります。
| プロセス | 典型的な作業の方向性 |
|---|---|
| 企画プロセス | 事業目的を踏まえ、システム化の構想や実施計画を作る |
| 要求定義プロセス | 利害関係者のニーズ、要望、制約条件を明確にする |
| 開発プロセス | システム要件、設計、実装、テストなどを具体化する |
| 運用プロセス | 本番利用、運用確認、障害対応、改善を行う |
SG試験では、「システム化の方針や計画を立てる」なら企画プロセスと判断します。
一方、「利害関係者の要望を明確にする」なら要求定義、「システムとして何を作るかを具体化する」なら開発、「本番運用で確認する」なら運用です。
機能要件と非機能要件の違い
要求定義では、機能要件と非機能要件を混同しないことも重要です。
- 機能要件:登録、検索、計算、表示、承認など、システムが行う処理そのもの
- 非機能要件:性能、稼働率、復旧時間、使いやすさ、保守しやすさ、セキュリティなど、品質や制約条件
SG試験では、「何を処理するか」なら機能要件、「どの品質で動くか」なら非機能要件と切り分けます。
詳しくは、非機能要件とは?機能要件との違いをSG試験向けに整理で確認できます。
システム開発プロセスとの違い
システム開発プロセスでは、目的とするシステムを実現するために、機能や能力を定義し、方式設計などによって実現方式を具体化します。
要求定義が「何を求めているか」を明確にする工程だとすると、システム開発は「どう実現するか」を具体化していく工程です。
- 要求定義:関係者が何を必要としているかを整理する
- システム開発:機能、能力、方式設計などで実現方法を具体化する
選択肢で「機能及び能力を定義する」「方式設計によって実現方式を確立する」とあれば、システム開発プロセス寄りです。
実装・取得プロセスとの違い
実装や取得の段階では、設計に基づいてソフトウェア製品、ハードウェア、外部サービスなどを得たり、適格性を確認したりします。
要求定義は、製品を買う・作る前に、何が必要かを明確にする工程です。
| 表現 | 疑う工程 |
|---|---|
| 要求を満たす製品やサービスを得る | 実装・取得 |
| 方式設計と適格性確認を行う | 実装・取得または開発 |
| 利害関係者のニーズを明確にする | 要求定義 |
ステークホルダマネジメントとの違い
要求定義では、利害関係者を識別します。
そのため、ステークホルダマネジメントと似て見えることがあります。
ただし、見るポイントが少し違います。
| 用語 | 見るポイント |
|---|---|
| ステークホルダマネジメント | 関係者の期待・利害・影響を管理する |
| 要求定義プロセス | 関係者の要求をシステムに求める内容として整理する |
選択肢で「関係者の期待や影響を管理する」とあればステークホルダマネジメント、
「関係者のニーズ・要望・制約条件を明確にする」とあれば要求定義プロセスを考えます。
確認問題(SG試験対策)
ある会社では、営業部門で使う顧客管理システムを刷新することになった。要求定義プロセスで行う活動として、最も適切なものはどれか。
- ア. 営業担当者、管理者、情報システム部門などの関係者に確認し、必要な機能、運用上の制約、セキュリティ上の条件を整理する。
- イ. 顧客管理システムの刷新によって売上拡大を目指すか、業務効率化を目指すかなど、投資の目的と実施方針を決める。
- ウ. 入力画面、データベース、外部サービス連携などの構成を決め、どの技術で実現するかを設計する。
- エ. 導入候補のパッケージ製品を評価し、契約後に納品物が条件を満たしているかを確認する。
▶ クリックして答えと解説を見る(ここを開く)
正解:ア
解説
- ア:適切。利害関係者のニーズ、要望、制約条件を明確にするのは要求定義プロセスです。
- イ:不適切。投資目的や実施方針を決める話なので、企画プロセス寄りです。
- ウ:不適切。構成や実現技術を決める話なので、設計・開発プロセス寄りです。
- エ:不適切。製品評価や納品物の確認は、調達・取得や受入確認の段階で問われやすい内容です。
👉 判断ポイント
「利害関係者」「ニーズ」「要望」「制約条件」がそろっていれば、要求定義プロセスを優先して考えます。
まとめ(試験直前用)
- 要求定義プロセスは、利害関係者のニーズ、要望、制約条件を明確にする工程です。
- 企画は、事業目的・システム化方針・実施計画を立てる工程です。
- システム開発は、機能・能力・方式設計などで実現方法を具体化する工程です。
- 実装・取得は、製品やサービスを得て、要求を満たすか確認する段階です。
- SG試験では、「何を求めているか」を整理するなら要求定義、「どう実現するか」なら開発と切り分けます。