ITパスポート 2024年 問33

業務要件定義が曖昧だと起きる問題を選ぶ問題【ITパスポート 解説】

正解の理由

解法ステップ

1. 「業務要件定義」が何をする工程かをはっきりさせる。→ 目的や受け入れ基準を定める工程。
2. 各選択肢が「目的や受け入れ基準の曖昧さ」から直接生じるかを考える。
   • 直接関連するか（要件の不明確さで発生する）→ 正しい候補。
   • 実装ミスや企画段階の問題など、別原因で起こるかを判断する。
3. 該当する選択肢の組合せを選ぶ。→ c（仕様変更で手戻り頻発）、d（受入れテストを設計できない）が該当するため エ。

選択肢別の誤答解説

• ア: a, b
  • a（企画プロセスでシステム化構想がまとまらず承認が得られない）
    → これは企画段階（どんなシステムにするかを検討する段階）の問題です。業務要件定義は企画の後に詳しくすることが多く、企画がまとまらない原因は要件定義以前の不十分な検討や意思決定の不足にあります。したがって「業務要件定義が曖昧」だけが原因とは言えません。
  • b（コーディングのミス）
    → コーディングミスは実装（プログラミング）上のヒューマンエラーやテスト不足の問題であり、必ずしも要件定義の曖昧さが原因とは限りません。
• イ: b, c
  • b は上記の通り直接的原因ではないため、この組み合わせは不正解です。c（仕様変更による手戻り頻発）は要件の不明確さと直接関係しますが、b と組むと不適切です。
• ウ: b, d
  • d（受入れテストが設計できない）は要件曖昧の典型的な結果ですが、b（コーディングミス）は別原因なので組合せとして誤りです。
• エ: c, d
  • c（開発中に仕様変更による手戻りが頻発する）：要件が曖昧だと、開発が進んだ段階で「要求と違う」「抜けがある」と判明し、仕様変更が多くなり手戻り（やり直し）が増えます。
  • d（受入れテスト設計ができない）：受入れテスト（受入れテスト：ユーザーや顧客が「これで要求が満たされているか」を確認するテスト）は、何をもって合格とするか＝受け入れ基準が要件に書かれていないと設計できません。
    → どちらも業務要件定義の曖昧さと直接結びつくため正解です。

よくある誤解

1. 「要件が曖昧＝プログラムミスが起きる」
   → 要件の曖昧さは誤解や追加要求を招きますが、単純なコーディングミス（タイプミスやロジック誤り）は要件の有無とは別の原因で起きます。両者は関連し得ますが同一視しないことが大切です。
2. 「企画段階の失敗も要件定義のせい」
   → 企画プロセス（システム化構想を作る段階）と業務要件定義は段階が異なります。企画がまとまらない原因は企画側の検討不足や経営判断の問題であることが多いです。

補足コラム

• 要件の種類と役割
  • 企画（計画）段階：どんな価値を出すかを決める（例：業務効率化、コスト削減）。
  • 業務要件定義（business requirements）：ビジネスが求める「何を」実現するかを明確にする（例：受注処理を24時間以内に処理する）。
  • システム要件定義（system requirements）：業務要件を実現するためにシステムがどう振る舞うべきかを技術的に定める（例：応答時間は2秒以内）。
    要件が下流に正確に伝わらないと、設計・実装・テストに悪影響が出ます。V字モデル（開発工程と対応するテスト工程を対応させる考え方）を思い出すと分かりやすいです。

FAQ