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

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

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

 きちんと変更管理できない理由のひとつは、変更管理をする上での役割やプロセスが決まっていないことである。

 

 変更管理には多くの労力が必要だ。役割やプロセスを決定し、それらを多くの利害関係者に周知徹底することや、要件からテストに至るまでの一貫性を維持・管理していくには、コストがかかる。そのため、なんとなく変更管理のメリットを感じていたとしても、実行に移すとなると二の足を踏む。

 

 結局はユーザ企業とSIベンダの甘えと癒着の構造、SIベンダと下請けの連鎖による無責任体質が原因であることはいうまでもない。変更が管理されていないことで、プロジェクトに混乱が生じ、要求と開発したシステムとの間で大きなギャップが生まれる。最後の最後で技術者が渋々、そのギャップを埋める作業をしているのである。

 

 本書では、ユーザ企業・設計事務所・SIベンダの3者によるプロジェクトの実現を想定している。これら3者が、どのような役割で変更を管理すればよいだろうか?

 

ユーザ企業側の役割

 変更要求は、さまざまな利害関係者から出される。要求内容によっては、利害が相反する可能性や、ほかの要件との矛盾が発生する可能性がある。その利害を調整し、その変更によるスケジュールや品質への影響を考慮に入れた上で、最終的な判断を下さなければならない。

 

 つまり、ユーザ企業側では、変更の受け付けから決定に至るまでの変更承認プロセスを規定しなければならない。

 

設計事務所側の役割

 設計事務所は、要件を取りまとめ、設計を行い、システムが設計通りに実装されていることを監督する立場にある。つまり、ユーザ企業側のポジションとして動く立場である。そのため、設計事務所側に変更管理者を置くのが適切である。

 

 変更が承認されたら、その管理は変更管理者に委譲される。変更管理者は、利害関係者に変更内容を周知徹底し、それぞれが担当するドキュメントやプログラムへの修正指示を行う。そして、修正状況や変更内容の妥当性を管理していく。

 

 以上をまとめると、変更管理者には、

 

  • プロジェクトに変更はつきもの、という現実を受け入れる柔軟性
  • 成果物の品質判断を行えるだけの技術的バックグラウンド
  • 変更によるリスクと影響範囲を的確に判断できる洞察力

が要求される。「そんな人材がゴロゴロいたら誰も苦労しないよ!」と言われそうな人材像であるが、プロジェクトにとって変更管理というのは決定的に重要である。プロジェクト管理の経験が豊富で、変更管理について正しい知識を持った担当者を割り当てるべきである。

 

 「成果物は常に変更されるものであり、変更のないプロジェクトはあり得ない」という点を受け入れることのできない管理者や技術者は、変更管理者として適任ではない。これらは、本質的には人員配置の問題だが、変更管理を行ううえにおいて重要な観点である。

 

SIベンダ側の役割

 SIベンダ側では、「作っているものが正しいものである」ことを証明するために、変更を把握しなければならない。要件定義・要求仕様・設計書の整合性と実現可能性を判断し、変更内容や、その変更によって影響を受けるスケジュールなどをプログラマやテスト担当者に周知徹底し、正しく変更されていることを管理しなければならない。

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

13.4. 変更管理における役割 ハッピィ・エンジニアリング関連ページ

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

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