このエントリーをはてなブックマークに追加LINEで送る

13.5. 変更管理プロセス

ハッピィ・エンジニアリング表紙

 変更管理プロセスは、プロジェクト計画の承認後ただちに開始し、プロジェクトが終結に至るまで継続して行うべきものである。プロジェクトに対する変更は、そのライフサイクルすべての段階において変更の可能性がある。前述したように、プロジェクト計画そのものも変更管理の対象となるので、プロジェクト計画の初版がリリースされたら変更管理を始めるべきである。

 

 変更管理には厳格さが要求されると述べたが、変更プロセスはあまり煩雑であってもいけない。変更管理の最大の関門は、形骸化をいかに防ぐか、なのである。プロジェクトメンバも人の子、面倒で不合理な作業を押しつけられてはたまらないということもあるが、不明確で煩雑な作業プロセスなど、受け入れられるわけがないのである。

 

 また、プロジェクトが終結間際になると、緊急の事態が発生する。緊急時において、意思決定者の決定を待つわけにはいかない場合も発生するだろう。緊急時に対応するために、意思決定者が不在の場合と、変更管理者が不在の場合における代替策を用意しておくべきである。

 

 改めて述べるまでもないが、ユーザ企業の中で要件定義プロセスの成果物への合意はシステム化の大前提である。これを行わずして、変更の合理的判断はあり得ない。仮に、要件定義プロセスの成果物に対する合意が行われていないのであれば、まずユーザ企業側の意思決定者を決定し、意思決定プロセス(この意思決定プロセスは、変更承認プロセスとして利用可能である)を明確にするところから始めなければならない。

 

管理対象要素の識別

 プロジェクトの成果物が一貫性・整合性を持つためには、その変更要求に対して、どの成果物が修正の対象となるかを確認・修正する必要がある。つまり、変更管理プロセスの前提として、前述した構成管理が行われている必要があるのだ。構成管理が行われ、成果物の構成要素が明確になっていれば、変更を分析した結果として、何に変更を加えるべきかが明らかになるのである。変更の実施において、抜けが発生することがないように、管理対象となる成果物の構成はあらかじめ決定しておかなければならない。これは、最初の変更を受け付ける前に確立すべきプロセスである。

 

変更要求の受け付け

 ユーザ企業側で変更要求の受けつけを行う。変更要求に対しては、本来あるべきシステムの姿から逸脱していないか、利害が衝突し、要件に矛盾が発生しないか、経営戦略や事業戦略との矛盾が発生しないかなどの、変更の合理性を判断する。その上で、まずは設計事務所およびSIベンダに対して変更計画の立案を指示する。

 

 変更管理の大前提は、変更要求を一意に識別することである。簡単に言えば、成果物に対する変更を行った結果を追跡するには、「この成果物に対して行われた変更はどれか?」を識別できなければならない。そのためには、それぞれの変更要求に採番する必要がある。当然、「なぜ、変更要求が却下されたのか?」を識別するためにも、却下したものも含め、すべての変更要求に採番しておかなければならない。

 

変更計画の立案

 受け付けられた変更要求に対して、設計事務所およびSIベンダは、必ず変更計画を立案する。仰々しい変更計画書などを作成する必要はないが、要求根拠を確認するとともに、以下の内容について明らかにしなければならない。

 

  • 実現可能性(本当に実現できるのか、検証が必要か)
  • コスト
  • スケジュール
  • プロジェクトリスク

 必ずしも影響範囲が明確になるとは限らない。しかし、その場合も、潜在するリスクを明確にし、リスクの軽減策や、問題が発生した場合の対応策を事前に検討しておく必要がある。

 

 ユーザ企業側では、実現可能である限り、コストやスケジュール、リスクを考慮したうえで、最終的な意思決定を行う。納期などの制約によっては、プロジェクトスコープを狭め、より優先度の高い機能を実装するような判断を下すこともある。この場合、プロジェクトスコープの変更も管理対象となる。

 

権限の委譲と制限

 ユーザ企業の意思決定者により、変更の承認を得たら、プロジェクトマネージャは、すべての利害関係者に変更内容を周知徹底しなければならない。そして、その変更は変更管理者が管理する。変更管理者は、変更の影響が及ぶすべてのチームに対して変更を指示し、変更権限を委譲する。変更を実行するには必ず権限が必要であり、例えばプログラマがソースを修正するのは「変更管理者から、そのソースに対する変更権限を委譲された」からであって、「権限のないものが変更を行ってはならない」という原則をまず意識すべきだ。

 

変更の追跡

 成果物に加えられた変更は、追跡が可能になっていなければならない。追跡とは、単純に履歴が参照できればよいものではない。どのような要求が出されたのか、なぜ出されたのか、どのような判断のもとに受け入れを決定したのか、といった点が後から参照できなければならない。

 

 これを人手でやっていては大変なので、通常はツールを利用することになる。変更管理に対するよくある誤解に、「ツールを導入すれば、それでおしまい」というものがある。しかし、ツールは自分たちの管理方針に合わせてカスタマイズが必要である。管理方針が定まっていなければ、カスタマイズのしようがない。管理方針とは、すなわち変更管理プロセスのことであり、ツールを導入してもプロセスが明確になっていなければ宝の持ち腐れだ。

 

 変更の追跡には、波及した影響の追跡も含まれる。そのためには、成果物同士の依存関係が階層的に構成されていなければならない。例えば要件レベルの変更が生じた場合、設計書・ソースコード・テスト仕様書に影響が及ぶ。ソースコードを修正しただけでも設計書やテスト仕様書に影響が遡及するので、この点からも、安直にソースコードを修正すべきではないことがわかるだろう。

シェアしてくれると嬉しいです!
このエントリーをはてなブックマークに追加LINEで送る

13.5. 変更管理プロセス ハッピィ・エンジニアリング関連ページ

13.1. プロジェクトにおける変更管理への認識
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
13.2. 変更管理のメリット
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
13.3. 変更管理プロセスの位置付け
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
13.4. 変更管理における役割
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
13.6. 変更管理方法論
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。

ハッピィ・エンジニアリングとは? 書籍を読む プロフィール コンサルティング