ITパスポート試験 - 令和6年 - 問33

答え ： エ
分野 ： ストラテジ系 › システム戦略 › システム企画 › 要件定義
解説 ：
一般的なシステム開発プロジェクトは，概ねこのような流れで進みます。

・企画プロセス：そもそも「どんなシステムを作るか」の構想を練る段階
・要件定義：「業務をどう回したいか」「システムに何をしてほしいか」を具体的に固める段階
・設計・製造（コーディング）：要件定義をもとに，実際にプログラムを作る段階
・テスト：作ったシステムが要件通りに動くか確認する段階

「業務要件定義」とは，この2番目の「要件定義」の中でも特に，「業務上，システムに何をしてほしいのか」を明確にする作業のことです。ここが曖昧だと，後の工程に悪影響が連鎖します。

各選択肢を検討すると，

a：企画プロセスで構想がまとまらない
→ これは要件定義より前の「企画プロセス」の話です。要件定義はまだ始まってすらいないので，「要件定義が曖昧」が原因にはなりません。時系列がおかしいので×。

b：コーディングのミスで意図と違う動作をする
→ これは「要件は明確に決まっていたのに，プログラマが実装を間違えた」という単純な技術的ミスの話です。要件定義の曖昧さとは直接関係ないので×。

c：開発中に仕様変更による手戻りが頻発する
→ もし業務要件定義の段階で「何を作るべきか」がきちんと固まっていなければ，開発が進んでから「あ，やっぱりこの機能も必要だった」「ここは違う仕様だった」と気づくことが多発します。これが「手戻り」（前の工程に戻ってやり直すこと）です。要件が曖昧 → 後から仕様変更 → 手戻り，という因果関係がはっきりしているので○。

d：適切な受入れテストを設計できない
→ 受入れテストとは，「発注者側が，出来上がったシステムが自分たちの業務要件を満たしているか」を最終確認するテストです。そもそも業務要件が曖昧なままだと，「何を基準に合格・不合格を判定すればいいか」が決められません。つまりテストの設計そのものができなくなりますので○。

したがって正解は c と d の組み合わせ＝エ となります。