情報セキュリティマネジメント 2018年 秋期 午前（科目A） 問49
問題文
企画、要件定義、システム開発、ソフトウェア実装、ハードウェア実装、保守から成る一連のプロセスにおいて、要件定義プロセスで実施すべきものはどれか。
選択肢
ア：システムに関わり合いをもつ利害関係者の種類を識別し、利害関係者のニーズ及び要望並びに課せられる制約条件を識別する。（正解）
イ：事業の目的、目標を達成するために必要なシステム化の方針、及びシステムを実現するための実施計画を立案する。
ウ：目的とするシステムを得るために、システムの機能及び能力を定義し、システム方式設計によってハードウェア、ソフトウェアなどによる実現方式を確立する。
エ：利害関係者の要件を満足するソフトウェア製品又はソフトウェアサービスを得るための、方式設計と適格性の確認を実施する。
🔒 解説は解答すると表示されます
要件定義の役割【情報セキュリティマネジメント解説】
正解の理由
要件定義では、対象システムに関わる人や組織（利害関係者：ステークホルダー）を洗い出し、それぞれのニーズや要望、適用される制約を明確にします。問題の選択肢の中でこの内容を示しているのが ア です。
要件定義は「何を実現すべきか」を決める工程であり、ここで得た要求が後の設計・開発・テストの基礎になります。したがって、利害関係者の識別とニーズ・制約の整理が要件定義の中心作業になります。
要件定義は「何を実現すべきか」を決める工程であり、ここで得た要求が後の設計・開発・テストの基礎になります。したがって、利害関係者の識別とニーズ・制約の整理が要件定義の中心作業になります。
（補足）利害関係者＝ステークホルダー（例：業務担当者、経営、顧客、外部委託先など）
解法ステップ
- 問題文で「要件定義プロセス」とある点を最優先で読む。ここは「何を決める工程か」を問うている。
- 選択肢を見て、「問題の工程の目的」に合致する文を探す。要件定義は「要件（要求）」を整理する工程であることを思い出す。
- 「利害関係者の識別」「ニーズ・要望の整理」「制約条件の明確化」といった語句があれば正答候補とする。
- 他の選択肢に「実施計画」「方式設計」「方式の確認」など実装・設計・検証の語があれば、それらは要件定義より後の工程（企画や設計、検収）に属するので誤りと判断する。
選択肢別の誤答解説
- ア：正解。利害関係者（ステークホルダー）を特定し、彼らのニーズや要望、制約（法規制・予算・既存システムの制約など）を整理するのが要件定義の本質です。職場ではヒアリングやワークショップ、要求一覧（要件定義書）を作成します。
- イ：誤り。事業の目的・目標やシステム化の方針、実施計画の立案は企画段階やプロジェクト立ち上げ時の仕事です。要件定義は企画で決まった方向性を受け取り、具体的な要求に落とし込む工程です。
- ウ：誤り。システムの機能・能力の定義やハード／ソフトによる実現方式の確立は「方式設計」や「基本設計」と呼ばれる後工程の作業です。要件定義はまず「何を求めるか」を定義しますが、実現手段は設計で検討します。
- エ：誤り。方式設計と適格性の確認（承認・検証）まで含むのは、設計～テスト～受入れにまたがる工程の説明です。要件定義はその前段で、満足すべき要件（目的）を定めます。
よくある誤解
- 「要件定義で詳細な設計まで行う」と考える誤解：要件定義は「何を実現するか」を決める段階で、具体的なハードやソフトの選定、画面レイアウトやデータベース設計といった詳細設計は後工程です。
- 「要件＝機能要求だけ」と捉える誤解：性能・可用性・セキュリティなどの非機能要件（システムの品質に関する要求）も要件定義で明確にします。非機能要件は設計・テストでも重要な基準になります。
補足コラム
- 非機能要件とは：システムが「どのように動くべきか」を示す要求で、性能（処理速度）、可用性（稼働時間）、セキュリティ（アクセス制御・暗号化）、拡張性（将来の増強）などを指します。要件定義でこれらを明確にしておくと、後の設計や調達でぶれが少なくなります。
- 職場での運用イメージ：要件定義は業務担当者（業務オーナー）と開発側が共同で行います。典型的な手順は、関係者の洗い出し→ヒアリング→業務フローの確認→要件（機能・非機能）の文書化→合意（署名や承認）の取得、という流れです。外部委託する場合は、要件定義書を基に見積りや提案（RFP：Request for Proposal：提案依頼書）を出します。
FAQ
Q1. 要件定義書に署名は必要ですか？
A1. はい。合意内容を明確にして変更管理を容易にするため、関係者の承認を得るのが望ましいです。業務の責任者や発注側の承認印・電子承認を使います。
A1. はい。合意内容を明確にして変更管理を容易にするため、関係者の承認を得るのが望ましいです。業務の責任者や発注側の承認印・電子承認を使います。
Q2. 要件定義は誰が主導すべきですか？
A2. 業務側の代表（業務オーナー）が主導し、システム部門や外部ベンダーと協力して作成します。IT部門が代行するケースもありますが、業務要件の最終責任は業務側にあります。
A2. 業務側の代表（業務オーナー）が主導し、システム部門や外部ベンダーと協力して作成します。IT部門が代行するケースもありますが、業務要件の最終責任は業務側にあります。
Q3. 要件が変わったらどうする？
A3. 変更管理（チェンジコントロール）プロセスを定めます。影響範囲やコスト・スケジュールへの影響を評価し、関係者の合意を得てから反映します。
A3. 変更管理（チェンジコントロール）プロセスを定めます。影響範囲やコスト・スケジュールへの影響を評価し、関係者の合意を得てから反映します。
関連キーワード: 要件定義、利害関係者、非機能要件、要件定義書、基本設計
\ せっかくなら /
情報セキュリティマネジメントを
クイズ形式で学習しませんか？
クイズ画面へ遷移する→
すぐに利用可能！