業務要件定義が曖昧だと、どの工程で問題が起きるのか
ITパスポート試験 令和6年度 問33 ／ システム企画 › 要件定義
過去問にチャレンジ
次の記述のうち、業務要件定義が曖昧なことが原因で起こり得る問題だけを全て挙げたものはどれか。 a 企画プロセスでシステム化構想がまとまらず、システム化の承認を得られない。 b コーディングのミスによって、システムが意図したものと違う動作をする。 c システムの開発中に仕様変更による手戻りが頻発する。 d システムを受け入れるための適切な受入れテストを設計できない。
- ア
a，b
- イ
b，c
- ウ
b，d
- エ
c，d
会話形式の解説
講師今回は、業務要件定義が曖昧なときに、その影響がどの工程に出るかを問う問題です。業務要件定義とは、システムが業務で実現すべき内容や制約、ルールを取りまとめて決める作業のことです。四つの記述が、要件定義より前の話か後の話か、そして直接の原因が何かに注目してください。
受験者私は、どれも要件定義と関係がありそうに見えてしまいます。企画でシステム化構想がまとまらないのも、要件がはっきりしないからではないでしょうか。
講師そこが最初の分かれ目です。システム化は、企画、要件定義、開発の順に進みます。システム化構想をまとめて承認を得るのは企画プロセスで、業務要件定義より前の工程です。
受験者前の工程で起きる問題なら、後の工程である要件定義の曖昧さが原因にはならない、ということですね。
講師そのとおりです。なので、システム化構想がまとまらないという記述は外れます。次に、コーディングのミスで意図と違う動作をするという記述はどうでしょう。
受験者意図と違う動作という部分は要件の話にも思えますが、原因はコーディングのミスと書かれています。
講師はい。結果の現れ方ではなく、直接の原因がどの工程にあるかで判断します。コーディングのミスは実装工程で起きる問題で、要件の曖昧さとは原因が別です。ですから、これも外れます。
受験者では、開発中に仕様変更による手戻りが頻発するという記述は、要件が曖昧なまま開発を進めたせいで起きる、と考えてよいですか。
講師よいです。要件が曖昧なまま進めると、途中で認識の違いや抜けが見つかり、仕様の変更や追加が繰り返されます。手戻りとは、前の作業に戻ってやり直すことで、遅れやコストの増加につながります。
受験者受入れテストを設計できないという記述も、要件と関係がありそうです。受入れテストは、できあがったシステムを利用する側が確かめるテストでしたよね。
講師はい、受入れテストは要件を満たしているかを確かめるテストです。要件が曖昧だと合否の基準が決まらないので、確認する項目や期待する結果を決められず、テストを設計できません。
受験者整理すると、企画の問題は要件定義より前、コーディングミスは原因が実装なので外れます。残る手戻りと受入れテストの二つを選んだ組合せが正解ですね。
講師正解です。他の組合せは、どれもコーディングミスかシステム化構想の記述を含んでいるので誤りです。この種の問題では、起きる工程が要件定義より前か後か、直接の原因は何か、の二つを確かめると判断しやすくなります。
まとめ
業務要件定義は、システムが業務で実現すべき内容や制約、ルールを取りまとめて決める作業です。システム化は企画、要件定義、開発の順に進むため、企画段階でシステム化構想がまとまらない問題は、要件定義の曖昧さが原因にはなりません。コーディングミスは実装工程の問題で、要件の曖昧さとは原因が別です。一方、開発中の仕様変更による手戻りと、合否基準が決まらず受入れテストを設計できない問題は、要件の曖昧さから起こり得ます。そのため「c，d」の組合せが正解です。
解答・解説
正解はエです
この問題のテーマ
業務要件定義が曖昧なとき、その影響がどの工程に出るかを問う問題です。業務要件定義より前にある企画、実装にあたるコーディング、要件を基準にする開発やテストを、工程ごとに切り分けて考えられるかが問われています。
解き方の考え方
まず、システム化が企画、要件定義、開発の順に進むことを確認します。そのうえで、a〜dの問題が要件定義より前に起きるのか、後に起きるのかを考えます。要件定義より前の企画段階で起きる問題は、要件定義の曖昧さが原因にはなりません。原因が要件ではなく実装のミスにあるものも外します。残ったcとdがどちらも当てはまるので、「c，d」の組合せが正解です。
選択肢ごとの解説
- ×ア a，baの「システム化構想がまとまらない」は企画プロセスの問題です。企画は業務要件定義より前に行うため、後の工程である要件定義の曖昧さが原因にはなりません。bのコーディングミスも実装工程の問題なので、どちらも当てはまりません。
- ×イ b，ccの仕様変更による手戻りは、要件が曖昧なときに起こり得る問題です。しかしbは、コーディングのミスがそのまま原因になっており、要件定義の曖昧さによるものではありません。bを含むので、この組合せは誤りです。
- ×ウ b，ddの受入れテストを設計できない問題は、要件が曖昧なときに起こり得ます。一方のbはコーディング工程で起きる問題で、要件定義とは関係がありません。そのため、この組合せも誤りです。
- ○エ c，dcは、要件が曖昧なまま開発を進めた結果、途中で認識の違いや抜けが見つかり、仕様変更や手戻りが繰り返し起きるものです。dは、合否を判断する基準が決まっていないため、確認する項目や期待する結果を決められず、受入れテストを設計できないものです。どちらも業務要件定義の曖昧さが原因で起こり得るので、これが正解です。
補足
この種の問題では「その問題が起きる工程は、要件定義より前か後か」と「直接の原因は何か」の二つを確かめると判断しやすくなります。bのように「意図と違う動作をする」と書かれていると要件の問題に見えますが、原因が「コーディングのミス」とはっきり書かれている点に注意してください。
POINT
- 業務要件定義は、システムが業務上実現すべき内容、制約、ルールを取りまとめて決める作業です。
- システム化は企画、要件定義、開発の順に進むので、企画段階の問題は要件定義の曖昧さが原因にはなりません。
- 要件が曖昧だと、開発中に仕様の変更や追加が起こりやすく、手戻りによって遅れやコストの増加につながります。
- 受入れテストは要件を満たしているかを確かめるテストなので、要件が曖昧だと合否の基準が決まらず、テストを設計できません。
- コーディングミスは実装工程で起きる問題で、要件の曖昧さとは原因が別です。