【変更管理⑥】変更依頼管理の全体像

以前、変更管理／変更依頼管理について色々とつづってきましたが、章ごとにバラバラにされていたのでわかりづらかったかもしれません。

ですので、今度はシチュエーションごとに整理してきました。

私は、変更依頼のトリガーは、大別すると

　①既に確定してしまった成果物に対して変更を加えたい場合
　②当初のプロジェクト推進計画に対して変更を加えたい場合
　③顧客都合によって要求事項または機能仕様に対して変更を加えたい場合

の３つがあると思っています。①と②は開発チーム側の都合で変更した場合です。③は一般的によく言われる「仕様変更」のことを言っていると思ってください。

「成果物に対する変更依頼」の場合

プロジェクトチームのメンバーによって、既に完成した（レビューが終わって、確定した）成果物に対して、「潜在的な問題を見つけてしまった」「リファクタリングがしたい」「ほかの機能を作っていたら、もっといい方法が見つかった」など、変更を加えたい場合に実施します。

もちろん、多くのプロジェクトが"こっそり"勝手に修正していると思います。実際、変更管理をきちんと導入しているプロジェクトは少ないでしょうし。ですが、その場合、トレーサビリティが確保できなくなってしまいますので、いざ何か問題を起こしてしまった場合に言い訳が苦しくなること間違いなしです。場合によっては、大きく信頼を損ねて針のむしろに座り続けることとなるでしょう。

すべてのストーリーをつなげると、次のようになります。