変更管理

■変更管理の目的

仕様変更、仕様追加による影響が最小限になるようコントロールする。

■変更管理の方法

1. 仕様変更、仕様追加は変更依頼書等の文書を通じて受け付け、変更管理台帳に記録を残す。もしくは変更管理ツールで管理する。
2. 変更管理台帳の項目は、依頼日・依頼者・システム名・処理名・機能名・変更理由・変更内容・想定リスク・リスク対策・適用予定日・適用日・備考等からなる。
3. 変更依頼書を受け取ってもSEの判断で対応しない。
4. 会議を開き、当初のスコープ定義（成果物・作業範囲）への影響について審議する。
5. スコープ定義が変わる事による工数・品質・納期への影響を洗い出す。
6. 変更の責任がユーザ側にある場合、その変更をプロジェクトの範囲外にできないか交渉する。範囲外にできない場合は、他の機能を削る事を検討する。また、納期を延長や費用の追加も交渉する。
7. 変更の責任が開発側にある場合、納期短縮や工数削減の方法を検討する。また、開発者の能力に問題がある場合は交代も考える。
8. 変更に関わる作業をスケジュールに反映する。

■ユーザによる仕様変更・仕様追加の原因

1. ユーザ要件から漏れていた。
2. ビジネス環境が変わってしまった。
3. 法律や制度が変わってしまった。
4. 経営方針が変わってしまった。
5. ユーザの組織が変わってしまった。
6. ビジネスモデルが変わってしまった。
7. ビジネスルールが変わってしまった。
8. ビジネスルールが間違っていた。
9. 現場業務の調査が不十分であった。
10. 現場の意見調整が不十分であった。
11. ユーザ担当者が代わってしまった。

■開発者による仕様変更・仕様追加の原因

1. ユーザ要件を漏らしていた。
2. 技術検証が不十分であった。
3. 設計ミスを犯していた。
4. 思い込みで設計した。
5. 全体の整合性を検証せずに設計した。
6. SEのコミュニケーション能力不足。
7. 設計担当者が代わってしまった。

■仕様変更予防策

1. 仕様書は契約書のようなもの。詳細に記述し、委託者と受託者が十分な時間を取って確認する。
2. 要件確認リストを使い、可能な限り要件漏れを無くす。
3. 要件定義書をユーザと共にレビューする。
4. 早期の段階でプロトタイプを作り、イメージを確認する。
5. 変更が見込まれる機能は可変化する。
6. 現場を見学し、現場の声を聞く。出来れば業務を体験させてもらう。
7. 事前に技術検証をしておく。
8. 不明点はユーザに必ず確認を取る。その際、解決策をいくつか用意しておく。
9. 全体の整合性はレビューで防ぐ。
10. 余裕があれば、仕様説明を兼ねて、レビュー会にプログラマーを参加させる。

---

位置：　トップ　>　プロジェクト管理　>　プロジェクト統制
通読：　前頁　|　次頁