平成26年度 秋期 ITパスポート試験 公開問題 問37 解説 システム開発の要件定義

システム開発におけるドキュメントの役割を理解していれば、迷わず「何を決めるための書類か」に着目することで正解にたどり着けます。この問題は「開発の対象範囲」というキーワードが、要件定義という「システムの方向性を決める最初の工程」と結びついていることが判断のポイントです。

開発工程とドキュメントの役割

システム開発は一般的に、企画から始まり、要件定義、設計、プログラミング、テスト、運用へと進んでいきます。

要件定義書は、その名前の通り「システムに何を求めるか（要件）」を定義する文書です。システムで実現したいことだけでなく、予算や期限、そして「どこまでをシステム化するのか」という開発の境界線（スコープ）を関係者全員で合意するために作成されます。ここが曖昧だと、後から「これもできると思っていた」という認識の齟齬が発生し、プロジェクトの遅延や失敗を招くため、非常に重要な工程と位置づけられています。

なぜ他の選択肢は違うのか

選択肢の各ドキュメントは、プロジェクトの異なるタイミングで役割を果たします。

アの移行計画書は、古いシステムから新しいシステムへ切り替える際に、データや業務をどう移すかを決めるものです。開発が終盤に近づいた段階で作られます。

イの結合テスト仕様書は、プログラム同士を組み合わせたときに正しく動くかを確認するためのチェックリストです。これは設計が終わった後の、テスト工程で使われます。

エの利用者マニュアルは、完成したシステムをユーザーがどう操作するかを説明する説明書です。開発の最終段階で作成されます。

これらはすべて「何を作るか（範囲）」を決めた後の工程で発生するものであり、「どこまでを作るか」を定義する要件定義書とは役割が異なります。

現場で求められる「スコープ」の意識

この問題が問うているのは、システム開発における「スコープ管理」の重要性です。実務の現場では、開発途中でクライアントから「これも機能として追加してほしい」といった要望が出ることは珍しくありません。

もし要件定義書で「今回開発するのはここまで」と範囲を明記していなければ、際限なく機能追加が求められ、プロジェクトの予算や納期が守れなくなります。ITパスポートでこの知識を問うのは、単なる用語の暗記ではなく、システム開発の責任者やメンバーとして「何をやらないかを決めることの重要性」を理解しているかを確かめるためなのです。

参考リンク

• 【ITパスポート】要件定義・外部設計・内部設計の違いを分かりやすく解説
• 要件定義の失敗を防ぐためのドキュメント作成術｜Zenn
• システム開発の要件定義に関するガイドライン｜経済産業省