ITパスポート 令和6年度 問33：system_strategyに関する問題

答えは d「c, d」 です。

「業務要件定義」とは、システムで“何をしたいか”をはっきり決める最初の話し合いです。ここがあいまい（ふわっとしたまま）だと、作っている途中で「やっぱり違った」と作り直し（c）が起き、完成後の合格テストも“何ができたら合格か”が決められません（d）。

👉 覚え方：「最初の決め事があいまい」→「後で迷子になる」。

ほかは関係ありません：a は要件以前にそもそも企画が通らない話、b はプログラムの打ち間違い（要件のあいまいさとは別の原因）です。

なぜこれが正解か

正解は d（c, d）。業務要件定義は「システムで実現すべき業務上の要求」を明確化する工程。ここが曖昧だと下流に影響が波及する。

• c：要件が固まらないまま開発に進むと、後から「本当はこうしたかった」と仕様変更・手戻りが頻発する。典型的な悪影響。
• d：受入れテストは「要件どおり作れたか」を確認する作業。要件が曖昧だとテスト項目を設計できない。

各選択肢の解説

• a：企画プロセスでシステム化構想がまとまらず承認を得られない→これは要件定義より前の「企画」段階の問題で、業務要件定義の曖昧さが直接原因ではない。
• b：コーディングミスによる誤動作→実装段階の人的ミスが原因で、要件の曖昧さとは別物。

覚え方・ひっかけ注意

要件定義の曖昧さが効くのは「決め方」由来の問題（手戻り・テスト設計不能）。「作り方」由来（コーディングミス＝b）や企画段階（a）は除外する。「上流の曖昧さは下流に波及」と覚える。

理論的背景

業務要件定義の曖昧性がシステム開発プロジェクトに与える影響は、要件管理論（Requirements Engineering）の中核テーマである。要件定義は「What（何を作るか）」を確定するプロセスであり、その曖昧性はシステム開発のすべての下流工程に波及する「上流工程リスクの集中点」として位置づけられる。

正解dの「c（仕様変更による手戻り）とd（受入れテスト設計不能）の2点」が業務要件定義の曖昧性に直接起因する理由を分析する。要件定義の曖昧性はまず「設計・実装の方針が定まらない」という直接的影響を生む。開発が進むにつれて要件解釈の差異が顕在化し、発注者の「そうじゃない」という仕様変更要求（手戻り）が頻発する（c）。また受入れテストの設計は「正しい動作の定義（要件）」を基準として行われるため、要件が曖昧なままでは「何をもって合格とするか」が決められず、受入れテスト設計が不能になる（d）。

事例aの「企画プロセスでシステム化構想がまとまらない」は業務要件定義の「前段」である企画フェーズの問題であり、業務要件定義の「曖昧さ」ではなく「企画プロセスの不完全さ」に起因する。事例bの「コーディングミスによる意図と異なる動作」はプログラミング工程の技術的誤りであり、要件の曖昧さとは別次元の問題である。

実務での使われ方

要件定義の曖昧性が原因となるプロジェクト失敗は業界調査で一貫して上位を占める。Standish Groupの「CHAOS Report」によれば、IT プロジェクト失敗原因の第1位は長年「不完全な要件定義・不明確な要件」であり、プロジェクト規模が大きくなるほど要件の曖昧性のコストが指数的に増大する。

要件定義品質の向上手法として①ユースケース記述（UML Use Case）、②ユーザーストーリー（アジャイル開発）、③プロトタイピングによる早期要件確認、④要件の優先度付け（MoSCoW法：Must/Should/Could/Won't）、⑤要件トレーサビリティマトリックス（RTM：各要件がどの設計・テスト項目に対応するかを追跡）が実務標準として使われている。

近年はAI-assisted requirements elicitation（AIによる要件抽出支援）として、会議録の自動要約・要件間矛盾検出・自然言語要件からUMLへの自動変換などのツールが登場している。

試験での位置づけ

「工程ごとの問題発生原因の識別」はITパスポートの「システム開発管理」分野での重要出題パターンである。本問の構造的ポイントは「企画フェーズ（システム化構想）・設計・要件定義・コーディング・テストの各フェーズに何が属するか」の正確な理解にある。

よくある誤答は「aも含む（a, c, d）」という選択で、「企画でまとまらない」ことも要件定義の曖昧さのせいと誤解するパターン。システム開発ライフサイクル（SDLC）のフェーズ順序（企画→要件定義→設計→実装→テスト→運用）を正確に理解し、問題の「原因フェーズ」を特定できるかが問われている。

基本情報技術者ではソフトウェアプロセス改善（CMMI・ISO/IEC 12207）の文脈で要件管理プロセスが詳細に問われる。プロジェクトマネジメント（PMBOK）では要件定義の品質管理として「要件ベースライン（スコープ確定文書）の変更管理プロセス」が重要テーマとなる。

選択肢の発展補足

事例aの「企画フェーズでシステム化構想がまとまらない」の原因分析：これは業務要件定義の曖昧さの「結果」ではなく、要件定義に「先行する」企画フェーズの問題である。具体的には①経営戦略との整合性の欠如、②ステークホルダーのコンセンサス不足、③予算・スコープの未合意が原因として挙げられる。企画フェーズの問題が解決しなければ要件定義フェーズに進めないという時系列関係を理解すること。

事例bの「コーディングミス」の原因論：コーディングミスの原因は①仕様理解の誤り（設計書の読み間違い）、②プログラミング技術の不足、③テストカバレッジの不足であり、要件定義の曖昧さとは区別される。ただし「仕様理解の誤り」が要件定義の曖昧さに起因する場合もあるため、間接的な因果関係は存在するが、直接的原因ではない点がポイント。

c, dの因果メカニズムの深掘り：cの手戻り発生はウォーターフォール開発で特に深刻であり、後工程での手戻りは前工程の10倍以上のコスト増加をもたらすことが工学的に知られている（BoehBMのコスト乗数理論）。dの受入れテスト設計不能は「テスト設計＝期待値の定義」という等式から自明であり、要件定義＝正解定義が曖昧なまま「何をテストするか」を決定することは不可能。