問36
頻出度★★★
合意済みのシステム要件に対し, 機能追加となる変更依頼を顧客から受けた。このときの受託側の対応として, 適切なものはどれか。
平成22年度 春期 ITパスポート試験 問36
マネジメント系プロジェクトマネジメント › プロジェクトマネジメント
この問題の解説と、これまでの解答の記録です。
解説
問 36
不正解ア
運用設計担当者は、システムを稼働後どう運用するかという観点の専門家であり、変更が運用に与える影響を評価する立場としては重要だが、要件変更の可否そのものを決める権限はもたない。開発工数・費用・納期・契約範囲といったプロジェクト全体への影響を引き受けられるのは決定権をもつ会議や責任者であって、一分野の担当者が単独で判断すると、他の領域への影響が見落とされたまま変更が入り込むことになる。
- イ
正解 正解は「イ 決定権をもつ会議や責任者が, 変更を行うかどうかを判断する」。いったん顧客と合意したシステム要件は、以後の設計・開発・テストの土台（ベースライン）となる。そこに機能追加という変更が入れば、開発工数・費用・納期・他機能への影響・契約範囲までが動くため、変更の可否は個々の担当者の判断に委ねてよい事柄ではない。そこでプロジェクトでは変更管理（変更管理委員会などの決定権をもつ会議、あるいは権限を委譲された責任者）の手続を定め、変更依頼書を受け付けて影響分析を行い、承認するか却下するかを正式に決定し、承認された場合だけ要件・計画・見積りを更新して関係者に周知する。イはこの正式な変更管理の流れそのものを述べているので適切である。
不正解ウ
営業担当者は顧客との窓口として変更依頼を受け取る役割は担うが、顧客の要望を通したいという立場に立ちやすく、開発への技術的影響や工数増加を正しく評価できるとは限らない。窓口が独断で「やります」と引き受けてしまうと、見積りも契約も更新されないまま作業だけが増える、いわゆるスコープクリープ（無管理の要件肥大）を招く。受け付けと承認は分け、可否は変更管理の手続で決めるのが正しい。
不正解エ
変更に係るソフトウェアの開発担当者は、実現可能性や必要工数を見積もる役割を担うが、主体となって可否を決める立場ではない。担当者が自分の判断で変更を取り込んでしまうと、変更内容が記録・承認されないまま実装が進み、他モジュールとの整合や納期・費用への影響、成果物の版管理が崩れる。技術的な評価情報を変更管理の会議に提供し、決定は権限をもつ側が下す、という役割分担を守る必要がある。
ここがポイント
- 合意済み（ベースライン化された）要件への変更依頼は、変更管理の手続に従って扱う。手順は、変更依頼を正式に受け付ける、コスト・納期・品質・他機能への影響を分析する、決定権をもつ会議（変更管理委員会など）や責任者が承認・却下を決定する、承認されたものだけ要件定義書・計画・見積り・契約に反映して関係者に周知する、という流れである。受け付ける人と承認する人を分けることが要点。
- プロジェクトスコープマネジメントの観点では、無管理な要件追加（スコープクリープ）を防ぐことが重要である。担当者の善意や口頭の合意で機能を足していくと、工数超過・納期遅延・後の責任の所在をめぐるトラブルにつながる。変更は必ず文書化し、権限をもつ意思決定者の承認を経てからスコープに取り込む。
用語