システム戦略｜令和6年度 ITパスポート試験 問33
次の記述のうち，業務要件定義が曖昧なことが原因で起こり得る問題だけを全て挙げたものはどれか。
- a 企画プロセスでシステム化構想がまとまらず，システム化の承認を得られない。
- b コーディングのミスによって，システムが意図したものと違う動作をする。
- c システムの開発中に仕様変更による手戻りが頻発する。
- d システムを受け入れるための適切な受入れテストを設計できない。
- a，b
- b，c
- b，d
- ✓ これが正解c，d
解説
何を作るかが曖昧だと、途中の作り直しと受入れで困ります。
業務要件定義は、新しい仕組みで業務をどうしたいのかを決める段です。ここが曖昧なまま先へ進むと、作っている途中で話が変わり、仕様変更による手戻りが繰り返されます。また、受け取るときに何をもって良しとするのかが決まらないので、適切な受入れテストを設計できません。よってcとdの二つです。aはこの段より前の企画で構想がまとまらない話なので、原因の順序が逆になります。bはコーディングの誤りで、作る段の腕の問題であり、決め方の曖昧さとは関わりません。起きる場所が要件定義より前か後かで振り分けられます。受入れテストの設計は、決めたことを裏返して作るものです。
ほかの選択肢はなぜ違うのか
- aとbを挙げています。aは要件定義より前の企画の段の話で、bは作る段の誤りです。どちらも要件が曖昧なことの結果ではなく、正しいcとdを両方落としています。起きた時期が近いものを選ぶと、この組合せになります。
- bとcを挙げています。cは正しいのですが、bはコーディングの誤りが原因とはっきり書かれています。開発中に起きる問題という点だけで結びつけると、この答えになります。
- bとdを挙げています。dは正しいのですが、bは作る段の誤りなので原因が違います。曖昧さのせいで起きたものと、腕の問題で起きたものを分けて見る必要があります。
この問題に関係する言葉
- 業務要件定義
- 要件定義作るシステムに何を求めるかを決める工程。業務の進め方だけでなく、稼働率や復旧までの時間といった条件も書き出します。
- 受入れテスト発注した側が、頼んだとおりに出来ているかを確かめる最後の試験です。合格すれば引き取り、本番の業務で使い始めることになります。
出典：令和6年度 ITパスポート試験 問33
同じ単元をまとめて解くならシステム戦略へ。
この解説に誤りを見つけたら教えてください。直して、直した記録を残します。誤りを報告する（メールが開きます）