あるプロジェクトで、私は変更管理を担当していた。もともと変更がたくさん発生するのがわかっていたため、専任の変更管理の管理担当者としてアサインされた。実際担当をして変更管理プロセスを回してみると、もともと予想されていたより更に多く（おおよそ２倍）の変更要求が発生した。
もともとはこのプロセスはお客様のため（つまり開発途中で要求が詳細化、具体化されて、それが設計変更につながると予測されたため）に作られた。しかし蓋を開けてみるとお客様からの変更も予測通り発生したが、開発側からの変更が多数発生した。
開発側からの変更って何？って思われるはずなのでプロジェクトの構造を簡単に説明すると。
お客（自分はお客様側PMOの立場）-元請けSIer-２次受けSIer
という構造となっていた。あと変更管理といっても予算管理は別にして、リソース管理（受容工数に対して、変更を受け入れることができるか？また優先順位をどのようにつけるか？）に特化して管理を行っていた。
お客からの変更は予想通り、しかし元請けSIerから「これこれを修正したいので変更させてくだい」という依頼が大量に来た。
※お客と元請けは請負契約ではないので、リソース余裕は丸見えになっていた。前のフェーズの反省からあえて余裕をもたせていた。
おかしいと思いなぜ発生したのか簡単に分析してみた。当初は課題やバグ（もうテストフェーズに入っていたため。ウォーターフォールでテストフェーズでなんで変更フリーズできないとか言わないで察してください）から派生して変更になっているのかと考えたが、課題管理のプロセスからではなく、いきなり変更管理に飛んできていた。
テストをやってて網羅的にテストポイントがカバーできているなら、バグ由来の変更になるんじゃないの？（元請けが２次受けにバグとして対応依頼をできないため、予算は持ち出しで、リソースを使わせてくださいとプロセスに乗っける）
変更管理担当としては、
- お客様の変更を優先したいが、開発側の変更（実際はバグ）を認めないとそもそもプログラムが動かない。
- 今発生している分はしょうがないが、将来のフェーズに向けて対策を立てたい。
- お客様の変更要求に対してのリソース余裕をもたせていたはずなのに、それを食い潰したくない。品質が悪いなら品質担保のためのタスクを設けリソースを確保するべき。
と考えたので、お客様、開発側に上記2の提案をしてみた。
とすると「これからもテストはまだまだ予定されており、前フェーズより網羅的にテストする予定であるので新たなタスクは必要ない」
いやいや、変更は、ちょっとした打ち合わせ、有識者の気づきから発生していて、仕様（設計書）レベルのバグと考えていた、設計書の総点検をしたいぐらいであるが、そのことを主張しても結局は受け入れられなかった。
テストシナリオ（ケース）の組み立てを経験値に頼り、間違った設計書をもとにしているので、抜け漏れが発生すると考えて提案をしたのだが、本当はもっとうまい提案の仕方があったのだろうか？過去のタスクを否定することはタブーなのだろうか？
0 件のコメント:
コメントを投稿