問題
問33
次の記述のうち、業務要件定義が曖昧なことが原因で起こり得る問題だけを全て挙げたものはどれか。
- a ：企画プロセスでシステム化構想がまとまらず、システム化の承認を得られない。
- b ：コーディングのミスによって、システムが意図したものと違う動作をする。
- c ：システムの開発中に仕様変更による手戻りが頻発する。
- d ：システムを受け入れるための適切な受入れテストを設計できない。
- a, b
- b, c
- b, d
- c, d
[出典：ITパスポート試験 令和6年度 問33]
正解
正解は「エ」です。
解説
業務要件定義が曖昧な場合、後続の工程で以下のような問題が発生します：
業務要件が不明確だと、システムの開発中に仕様変更が頻発し、手戻り作業が増加します（選択肢c）。 また、要件が明確でないために、システム受け入れテストの基準が定まらず、適切なテスト設計が困難になります（選択肢d）。 これらの問題は要件定義の曖昧さが直接的な原因となります。
ア a, b:
「a」は業務要件定義の曖昧さが原因となりますが、「b」はプログラムの実装ミスが原因であり、業務要件定義とは無関係です。この選択肢は不適切です。
イ b, c:
「b」はプログラム実装の問題であり、要件定義の曖昧さとは関係がありません。一方「c」は要件定義の曖昧さが原因となるため、この選択肢は一部不適切です。
ウ b, d:
「b」は要件定義の曖昧さとは無関係なプログラム実装の問題です。「d」は要件定義が原因の問題であるため、この選択肢も一部不適切です。
難易度
普通
業務要件定義の基礎的な知識を問う問題です。基本的な用語や因果関係を理解していれば解けますが、曖昧な理解では混乱する可能性があるため標準的な難易度と言えます。
用語補足
業務要件定義:
システムを開発する際に、対象となる業務の目的やプロセスを整理し、システムに必要な要件を明確化する工程のことです。例えば、販売管理システムを構築する際に「受注処理」や「請求処理」の業務フローを定義することが挙げられます。
仕様変更:
開発中に決定されたシステムの仕様（動作や構成）を変更することです。例えば、顧客からの新たな要望で入力画面の項目を追加する場合などが該当します。
受入れテスト:
システムが業務要件を満たしているかを確認するために行うテストです。例として、請求書作成システムが正しい金額を出力するかを確認する作業があります。
対策
- 業務要件定義が後続工程に与える影響を学び、仕様変更やテスト設計の問題がなぜ発生するかを理解することが重要です。
- 各工程での作業内容を整理し、それぞれの目的や結果を明確にする訓練を行いましょう。
- 要件定義書のテンプレートを参照し、実際にサンプルを作成して練習することで具体的な理解を深められます。
