変更管理は、プロジェクト管理の最上位、あるいはプロジェクト管理よりも上位に位置すると言っても過言ではない。

　変更を承認する権限を持たない人間が勝手に承認することは認められず、指揮命令系統を無視して作業を進めていいものでもない。変更の承認権限はユーザ企業の意思決定権者に一元化すべきで、プロジェクトマネージャといえども、変更に対する諾否を決めてはならないのだ。プロジェクトをスムーズに進めるには適切な権限の委譲が必要不可欠であるが、変更承認権限は、委譲してはならない権限の代表である。

　変更承認〜変更指示に至るプロセスは相互に関連し合い、かつプロジェクトのほかのプロセスとも密接に関連していることが多い。そのため関連部署やチームとの調整が多くなる。しかし、個々の調整では、それぞれのメンバのエゴが出てしまうため、実際には、意思決定者が独立したプロセスとして規定しなければならない。

　変更管理プロセスは難しいと再三述べられているが、その理由は、変更管理プロセスは全社的な作業標準とすべきものだからである。プロジェクトごとに変更管理手順が異なっているのでは効率が悪いし、第一そんな手順には誰も従ってくれない。変更管理プロセスは全社的な資産ととらえ、最初は選抜チームを組むくらいの心構えがないと、確立することは難しい。

　変更管理のプロセス自体も、一度定義してしまえば終わりということではない。プロセスを定義したら、まずパイロットプロジェクトに適用し、そのプロセスをテストしてみるのが重要である。変更管理プロセスは人的側面が強い。そのため、煩雑だったり、理解しにくい手順だったりしては、効力を失ってしまう。パイロットプロジェクトに適用し、プロセスの不備や矛盾を適宜改善していかなければならない。当然、変更管理プロセスをパイロットプロジェクトから個々のプロジェクトに展開した後も、段階的にプロセスの改善を行っていくべきである。

　変更管理プロセスでは、

• 管理対象要素の識別
• 管理対象要素の命名規則や採番規則
• 管理対象要素のステータスの定義
• 管理対象要素のステータスを変更する要件
• ステータスの追跡手段（ツールの選定）
• 管理対象要素の履歴の管理方法（ツールの選定）
• 変更申請手順
• 変更承認手順
• 変更受け入れ基準
• 変更管理委員の任命
• 変更権限の定義と割り当て

といった点を定義する必要がある。作業用文書のひな型やガイドラインも用意するとよい。

13.3. 変更管理プロセスの位置付け ハッピィ・エンジニアリング関連ページ

13.1. プロジェクトにおける変更管理への認識

ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。

13.2. 変更管理のメリット

ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。

13.4. 変更管理における役割

ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。

13.5. 変更管理プロセス

ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。

13.6. 変更管理方法論

ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。