SIerのプロジェクトマネジメント　「STとバグとリソース」

SIerのプロジェクトマネジメントでは、
SIerでPMをやってきた経験から、SIerでのプロジェクトで良くある状況で、僕ならPMとしてどのように判断していくかを書いていきたいと思います。
若手PMさんの参考になれば。

想定する状況

システムテスト工程に入ってから、結合テストまでに検知されるべきバグが多数見つかった。
お客様からの信頼は失いつつあり、挽回するためにも早急にバグ対応し、品質改善したいところ。
しかし、システムテスト工程に入る頃には、すでに開発者のリソースを解放しており、不具合に対応できる技術者の数が十分でない。
さらに、日々、バグの数は増え続けるし、バグとは別に改善要望など追加タスクもある。

という状況。

ウォーターフォールによる開発では、工程毎に予算確定し請負契約を締結するというケースは多く、システムテスト工程に入る頃には技術者がプロジェクトチームから離れてしまっているというのは良くある話。

そんな中で、日々増えていくバグの対応や、追加タスクへの対応しなければならないという時、僕ならどう対処していくだろうかと考えてみる。

状況の整理

状況整理すると下のようなる。

①固定してプロジェクトチームにアサインされているエンジニアはいない。
②バグやタスクの量は日々変化している。
③すぐには技術者は集められない。
④極力早く品質向上させたい。

思考と判断

まずは、④に対して、いつまでに品質向上させるのか、目標とする期日を決める。

システムテスト工程まで来ているということは、お客様企業ではリリースのタイミングなども具体的に検討されている場合もあり、かなりデリケートな時期である。
何事も期限をもって対処することを明言していかなければ、不信感は一気にふくれあがり、リリース直前での炎上事態になりかねない。
ずるずると計画が引き伸ばされればリリースに支障が出てきてしまう可能性もある。この時期には、期限を明示することは重要。

次に品質向上の程度を決める。もちろん、バグも改善要望も全て対応したいというのがお客様の気持ちではある。が、スケジュールや予算、リソースの関係で全てに対応することはデキないのが常である。だから、次の2パターンどちらかで品質向上として対応する内容を決めていく。

パターンＡ
期日までに対応するものを決めて、それをやりきれるだけの技術者をアサインしていくパターン。

パターンＢ
アサインできる技術者を決めて、その中でやれる分のバグやタスクを割り当てていくパターン。

②にあるように、バグやタスクが変化している状況では、対応すものを事前にきめる事ができないためパターンＡは現実的ではない。よって、この場合に僕はパターンＢを選択する。

パターンＢを選択することで、お客様には、
期限までに対応できるものに限りがあること
を了承していただかなくてはならない。

お客様と対峙するプロジェクトマネージャーにはストレスのかかる瞬間だが、お客様には正直にお話しするほかないだろう。

プロジェクトマネージャーの踏ん張りどころですね。