平成21年度 秋期 ITパスポート試験 問44 解説 仕様変更の手順

この問題は、ソフトウェア開発における変更管理の標準的なプロセスを理解していれば、論理的な順番で解くことができます。正解を導くための基本は「まずは依頼を受け取り、次にその影響を考え、決断を下し、最後に作業する」という一連の流れをイメージすることです。

変更管理の基本的な流れ

ソフトウェア開発の現場では、顧客やユーザーから「ここの機能を少し変えてほしい」といった変更要求が寄せられます。しかし、要求があるたびにすぐさまプログラムを書き換えていては、開発の計画が崩れたり、予期せぬ不具合が発生したりします。そのため、一般的に以下の手順で慎重に進めます。

1. 変更要求の受付：何を変えてほしいのかを聞く
2. 変更内容の評価：それを変えることで、スケジュールやコスト、他の機能にどれくらい影響があるかを調査する
3. 変更の指示：評価結果に基づき、やるべきかどうかを決定し、作業担当者に指示を出す
4. 変更の反映：設計書やプログラムを実際に修正する

問題文の図において、「変更要求の受付」の直後のステップ（A）は、要求が妥当かどうかや、実現可能かどうかを分析する「変更内容の評価」となります。

現場で求められる思考プロセス

この問題は、単なる用語の暗記ではなく、仕事の段取りを問うています。 もし、評価をせずに即座に指示を出せば、開発期間が大幅に遅延したり、予算オーバーを引き起こしたりするリスクがあります。逆に、評価をせずに反映してしまえば、取り返しのつかないミスを犯すかもしれません。

試験対策としては、「まずは全体像を把握し、次に影響範囲を評価する」という、IT開発の現場で極めて重要な「守り」の意識を持っているかを問われていると考えましょう。

なぜこの知識が重要なのか

実際のシステム開発において、仕様変更はトラブルの最大の要因の一つです。安易な仕様変更は、プロジェクト全体の遅延や品質低下を招くため、多くのプロジェクトでは「変更管理委員会（CCB）」のような組織が設置され、提示された手順に従って厳格に変更をコントロールしています。

ITパスポート試験でこの手順が問われる意図は、ITエンジニアとして、あるいはシステムを発注する立場の人間として、仕様変更が「勝手にやっていいこと」ではなく、「計画的に承認を得て行うべき手順」であることを理解させる点にあります。この手順を遵守できるかどうかで、プロジェクトの成否が決まると言っても過言ではありません。

参考リンク

• ITパスポート試験の効率的な学習方法と合格への近道
• 変更管理の自動化を検討してみる：Zennでの実践事例
• ソフトウェア構成管理（変更管理の標準的な定義）：JIS規格解説