平成22年度 春期 ITパスポート試験 問36 解説 システム変更管理

変更管理の鉄則は権限と影響範囲の評価

システム開発の現場において、後出しの要件変更はプロジェクトの「QCD（品質・コスト・納期）」を大きく揺るがすリスク要因です。そのため、現場レベルの独断ではなく、プロジェクト全体の責任を負う会議体や責任者が、変更の影響を分析した上で承認を下すのが正解です。

なぜ責任者の判断が必要なのか

システム開発は、当初の計画に基づいて予算、期間、人員が割り当てられています。ここで顧客から「機能追加」という変更依頼があった場合、以下の3つの観点で大きな影響が生じます。

1. コスト：機能が増えれば開発工数が増え、追加費用や予算超過のリスクが発生します。
2. 納期：開発期間が延びる可能性があるため、当初のリリース予定日を守れるかの再調整が必要です。
3. 品質：既存の設計と整合性が取れなくなり、新たなバグを引き起こすリスクがあります。

もし担当者が独断で「やります」と答えてしまうと、プロジェクト全体が崩壊しかねません。そのため、変更がプロジェクトに与える影響を客観的に評価し、全体最適の視点で「実施する・しない」あるいは「納期を延ばして実施する」といった判断を下すための仕組みが必要なのです。これを「変更管理」と呼びます。

現場で陥りがちな失敗を避ける考え方

ITパスポート試験において、この種の問題を解くコツは「責任の所在を明確にする」ことです。

選択肢にあるような「運用設計担当」「営業担当」「開発担当」といった個別の役割は、特定の専門領域には秀でていますが、プロジェクト全体の予算や納期をコントロールする権限は持っていません。例えば、営業担当者が顧客に良い顔をして安易に機能追加を承諾してしまうと、後工程の開発チームが地獄を見ることは想像に難くないでしょう。

この問題の教育的意図は、特定の技術知識だけでなく「システム開発は組織で動くものであり、変更という例外事象には組織的な統制が必要である」というガバナンスの意識を問う点にあります。実務では、このような会議体や責任者を置くプロセスを「変更管理プロセス」と呼び、正式な手順としてプロジェクト計画書に盛り込みます。

現場での活用イメージ

実際の業務では、以下のような流れで処理されます。

1. 変更依頼の受領
2. プロジェクトへの影響度分析（工数、予算、リスク調査）
3. 変更管理会議や責任者への報告
4. 承認または却下の判断
5. 関係者への通知と計画の修正

もし実務で顧客から「これくらいならすぐに追加できるよね？」と軽く頼まれた場合でも、「持ち帰ってプロジェクトの責任者と相談し、影響を確認した上で回答します」と返せるかどうかが、エンジニアやプロジェクト管理者としての信頼性を左右します。

参考リンク

• システム開発の「変更管理」とは？重要性と進め方を解説
• ITプロジェクトの成功率を左右する「変更管理」の現場
• 変更管理（Change Management）- PMBOKガイド