令和６年度 ITパスポート試験 公開問題 問33 解説 業務要件定義の不備

この問題は「業務要件定義」という工程が、システム開発プロジェクト全体においてどのような役割を果たしているかを理解していれば、論理的に正解を導き出せます。

業務要件定義が及ぼす影響を判断する

業務要件定義とは、システムを使ってどのような業務を実現したいのかを明確にするプロセスです。この定義が曖昧だと、開発の後半工程でつじつま合わせが必要になり、プロジェクトが混乱します。

各選択肢の判断基準は以下の通りです。

a：システム化の承認を得られないという状況は、要件定義以前の「企画プロセス」における構想の段階で発生する問題です。 b：コーディングのミスは、開発者がプログラムを記述する際の技術的な誤りであり、業務上の要件定義の内容とは直接的な因果関係がありません。 c：要件定義が曖昧だと、後工程で「本当はこうしてほしい」という修正依頼が頻発します。これが仕様変更による手戻りです。 d：何ができればシステムとして正しいのか（業務要件）が明確でないと、受入れテスト（最終的な確認）で何をテストすればいいのか基準を決められません。

したがって、業務要件定義の不備に起因するのは c と d となります。

なぜ手戻りとテスト設計が重要なのか

システム開発は「要求定義」「設計」「実装」「テスト」という工程を順番に進めるのが基本です。しかし、上流工程である要件定義で認識のズレが生じていると、下流工程に進んでからそのズレが表面化します。

手戻り（c）が発生すると、すでに行った設計や実装をやり直す必要があり、予算と時間が大幅に浪費されます。また、受入れテスト（d）は顧客（ユーザー）が「このシステムは業務に使える」と判断するための最終関門です。この基準が曖昧なまま開発を進めると、システムを納品してもユーザーから「求めていたものと違う」と突き返されるリスクが高まります。

現場で役立つ視点

ITパスポート試験でこの知識が問われるのは、システム開発の失敗要因の多くが技術的な問題よりも「何を作るか」という合意形成の不足にあることを理解させるためです。

システムエンジニアやプロジェクトマネージャだけでなく、システムを発注する立場のビジネスパーソンにとっても、要件定義を曖昧にすることは大きな経営リスクを伴います。実際のプロジェクトでは、要件定義の段階で「誰が」「いつ」「どのような手順で」業務を行うのかを関係者全員で可視化し、文書化して合意することが、プロジェクト成功の鍵となります。

参考リンク

• ITパスポート試験のシステム開発プロセスの解説
• 【システム開発】失敗しない要件定義の進め方と注意点を解説【実体験あり】
• 要求定義（システム開発） - IT用語辞典 e-Words