変更に振り回され進捗がままならない
場面
変更要求をどこに出していいか分からない
変更要求の影響の大きさを量っていない
変更が大きなトラブルを引き起こす
変更要求の採否に不満を持つため、その人とのリレーションが悪くなる
変更がなかなか反映されない
検討不十分のまますぐ変更を反映してしまう
変更内容が関係者に伝わっておらず、変更が変更を呼ぶ
担当者が変わると、今まで決めてきた事が変わる
変更要求のタイプ
- 仕様変更
機能追加/修正、法令変更、業務プロセス変更
お客様責任者/担当者の意見相違
業務のあるべき姿が十分判らないまま開発（新ビジネスプロセスのケース）
- メンバー変更
- 基盤（インフラ）変更
- 品質目標変更
- 仕様変更
対処のヒント
良いプロジェクト・マネジャーは、次の行動を起こします。
― プロジェクトに変更はつきものです ―
1. 変更を少なくするための手段をとる
- お客様の組織構造をよく理解して適切な担当者をアサインしてもらう
（専任度、権限度合、業務知識・経験） - 業務担当者に応じたヒヤリング技術を活用する
- 業務側とIT双方のプロの目で相互に確認する
機能要件（業務要件）の適切な洗い出しと整理 - 仕様の記述手法
仕様の記述は文章だけでは不足。ビジネスプロセスを表現する手法を併用する
（例：UML、DOA、DFD、ERなど） - まとめた仕様の確認
非機能要件の適切な洗い出しと整理 - 運用要件、性能要件、セキュリティ要件など
2. 変更に対して確実に対処する
- 変更の窓口の一本化
変更採否権限を持つ管理者を明確にする
（協力会社への変更管理の徹底を忘れないこと） - 変更管理プロセスの確立と遵守の徹底を図る
（プロセスの例）
影響分析
受入／却下決定
変更実施
変更実施結果の確認・文書化
3. 変更結果をプロジェクト全体へ反映する
- 変更内容と各種ベースラインの変更を関係者へ周知徹底をする
- 変更履歴管理（変更部分、影響を受けた部分）を実施する
- お客様の組織構造をよく理解して適切な担当者をアサインしてもらう
プロジェクトマネジメントではこんな言葉で表現されています
- スコープ・コントロール
- 統合変更管理
- ステークホルダー・マネジメント
- 組織構造
- 品質保証
このトピックスに関連の深い講座
IBM、IBMロゴ および ibm.com は、世界の多くの国で登録されたInternational Business Machines Corp.の商標です。他の製品名およびサービス名等は、それぞれIBMまたは各社の商標である場合があります。現時点での IBM の商標リストについては、http://www.ibm.com/legal/copytrade.shtml（US）をご覧ください。他の会社名、製品名およびサービス名等はそれぞれ各社の商標。
