ITパスポート過去問 令和1年度（2019年）問38
システム開発プロジェクトの開始時に，開発途中で利用者から仕様変更要求が多く出てプロジェクトの進捗に影響が出ることが予想された。品質悪化や納期遅れにならないようにする対応策として，最も適切なものはどれか。
選択肢
- ア：設計完了後は変更要求を受け付けないことを顧客に宣言する。
- イ：途中で遅れが発生した場合にはテストを省略してテスト期間を短縮する。
- ウ：変更要求が多く発生した場合には機能の実装を取りやめることを計画に盛り込む。
- エ：変更要求の優先順位の決め方と対応範囲を顧客と合意しておく。
- ア
- イ
- ウ
- エ
正解と解き方・学習ポイント（AI解説）
仕様変更要求が多く出る見込みがある場合は、変更を禁止するのではなく、変更要求をどう評価して採否を決めるかを事前に決めておくことが重要です。具体的には、変更要求の優先順位の決め方と、どこまで対応するかの範囲を顧客と合意しておくことで、品質を保ちながら納期遅れの発生を抑えやすくなります。
Point
この問題は、開発途中に仕様変更要求が多発しそうな状況で、品質悪化や納期遅れを防ぐための現実的な対応を選べるかを確認しています。ポイントは、変更要求を前提として、優先順位付けの基準と対応範囲を顧客と合意し、変更管理を行うことです。
解くために必要な知識
この問題を解くには、システム開発における変更管理の理解が必要です。
用語の整理
| 用語名 | 意味 |
|---|---|
| システム開発プロジェクト | 期間を決め、特定のシステムを開発する一連の活動のことです。 |
| 仕様変更要求 | 開発の途中で、利用者から機能の追加や修正を求められることです。 |
| 優先順位 | 複数の要求があるとき、どれを先に対応するかを決める順序のことです。 |
| 合意 | 関係者同士が話し合い、納得して決定することです。 |
| 変更管理 | 仕様変更が発生した際に、影響を評価し、承認し、実施する流れを管理することです。 |
判断ポイントの整理
開発途中の仕様変更を完全になくすことは困難とされます。そのため、変更を禁止する前提ではなく、変更が起きたときに混乱しない運用ルールを事前に決めておくことが重要です。
事前に決めておくとよい項目（代表例）
-
優先順位の決め方（重要度、緊急度、影響範囲など）
-
対応範囲（納期・工数・予算の制約内で対応する範囲）
-
変更時の手続（影響見積り、承認者、反映タイミングなど）
問題の解法手順
問題の注目ポイントは、仕様変更要求が多く出る見込みがある状況で、品質悪化や納期遅れを避けるための対応策を選ぶことです。
各選択肢の整理
| 選択肢 | 判断の観点 | 評価 |
|---|---|---|
| ア | 変更要求を受け付けない運用が現実的か | 利用者側の事情で必要な変更が出ることがあり、運用として硬直的になりやすいです。 |
| イ | 品質を守れるか | テスト省略は不具合流出につながりやすく、品質悪化の典型です。 |
| ウ | 顧客との合意を保てるか | 一方的な実装取りやめは、求められる成果物を満たさない可能性があります。 |
| エ | 変更を管理して影響を抑えられるか | 優先順位と対応範囲を事前合意すると、変更を統制しやすく、品質と納期を守りやすいです。 |
このため、最も適切なのは「エ」です。
選択肢ごとの解説
- ア：不正解
設計完了後に変更を一切受け付けないという宣言は、利用者側の事情で必要な変更が発生した場合に対応できず、実用上問題が出る可能性があります。仕様変更を想定している状況での対応策としては適切ではありません。
- イ：不正解
テストを省略して期間を短縮すると、不具合が残ったままになる可能性が高まり、品質悪化につながります。品質悪化を避けることが条件のため不適切です。
- ウ：不正解
変更要求が多いことを理由に機能の実装を取りやめると、顧客が期待する成果物を満たせない可能性があります。実装範囲の調整が必要な場合でも、顧客との合意手続が前提になります。
- エ：正解
変更要求が多くなることを見越して、優先順位の決め方と対応範囲を顧客と事前に合意しておけば、変更要求を影響評価の上で取捨選択できます。重要な機能と品質を保ちながら納期遅れを抑えやすくなるため、最も適切です。
まとめ
仕様変更要求が多く出る見込みがある場合は、変更を禁止するのではなく、変更要求をどう評価して採否を決めるかを事前に決めておくことが重要です。具体的には、変更要求の優先順位の決め方と、どこまで対応するかの範囲を顧客と合意しておくことで、品質を保ちながら納期遅れの発生を抑えやすくなります。
マネジメント系 > プロジェクトマネジメント > プロジェクトマネジメント
設計完了後に変更を一切受け付けないという宣言は、利用者側の事情で必要な変更が発生した場合に対応できず、実用上問題が出る可能性があります。仕様変更を想定している状況での対応策としては適切ではありません。
テストを省略して期間を短縮すると、不具合が残ったままになる可能性が高まり、品質悪化につながります。品質悪化を避けることが条件のため不適切です。
変更要求が多いことを理由に機能の実装を取りやめると、顧客が期待する成果物を満たせない可能性があります。実装範囲の調整が必要な場合でも、顧客との合意手続が前提になります。
変更要求が多くなることを見越して、優先順位の決め方と対応範囲を顧客と事前に合意しておけば、変更要求を影響評価の上で取捨選択できます。重要な機能と品質を保ちながら納期遅れを抑えやすくなるため、最も適切です。