ITパスポート 2019年 春期 問45

受託開発中に中途で機能追加を依頼されたときの対応【ITパスポート 解説】

正解の理由

• 変更は影響を評価して承認を得る必要がある。
• いきなり受け入れたり断ったり、勝手に計画を変えるのは誤り。
• 変更管理の手順に従えば、契約・予算・納期の調整が適切に行える。

解法ステップ

1. 問題の焦点を確認する
   • 「委託元から機能追加の依頼」「期間が半分を経過した時点」→ 変更要求への対応が問われている。
2. 選択肢が示す行動の妥当性を評価する基準を決める
   • 影響評価の有無、手順に従っているか、契約や計画との整合性が取れるか。
3. 各選択肢を照らし合わせる
   • 影響の評価と正式な承認を伴うものが正しい対応。
4. 結論
   • 変更管理の手順に従う選択肢（ウ）を選ぶ。

• 変更要求の記録（誰が何をいつ頼んだかを文書化）
• 影響分析（コスト、スケジュール、要員、品質、リスク、契約への影響）
• 提案（追加費用や納期変更案）を作成して関係者に提示
• 承認を得て、合意したら計画（ベースライン）を正式に更新

選択肢別の誤答解説

• 誤り。いきなり受け入れると、どれだけ影響があるか不明なまま進めることになり、最終的に納期遅延や追加費用のトラブルになります。まず影響評価と承認が必要です。

• 誤り。変更を一律に拒否するのは不適切です。重要な変更なら受け入れて契約や計画を調整することもあります。ポイントは「手続きを踏むこと」です。

• 誤り。ベースライン（baseline：合意された計画の基準）を勝手に更新する前に、影響評価と関係者の承認が必要です。スコープ変更が他の要素（コストや期間）に波及することが多いため、単独で更新するのは不適切です。

よくある誤解

• 変更は「できるだけ断るべき」と考える誤解
  → 変更自体は悪ではありません。重要なのは影響を評価して合意の上で実施することです。
• ベースラインは「自由に更新してよい」と考える誤解
  → ベースラインは関係者が合意した基準です。勝手に変えると信頼や契約違反につながります。
• 影響分析は時間がかかるので省略してよいという誤解
  → 省略すると後で大きな問題になります。簡易でも必ず実施します。

補足コラム

• 変更管理の基本的な流れ
  1. 変更要求（Change Request）を提出・記録
  2. 影響分析（コスト・期間・品質・要員・契約）
  3. 関係者による承認（場合によっては Change Control Board（CCB：変更審査委員会）で審議）
  4. 承認後に計画（スコープ、スケジュール、予算など）の正式な更新
  5. 実施と結果の記録
• 契約形態による違い
  • 見積り・固定価格契約の場合は、追加機能の追加費用と納期調整が特に重要です。
  • 時間・材料（Time & Materials）契約なら追加コストは発生しやすいが、正式な承認は必要です。
• アジャイル開発との関係
  • アジャイルは変更を受け入れやすいですが、それでも影響と優先度の評価、ステークホルダー合意は必要です。柔軟性＝無秩序ではありません。

FAQ