サービスイン真近のプロジェクトがあり総合試験も後半なのですが、バグが多くスケジュールに影響が出そうです。WEBをUIとしたDBのトランザクションシステムです。表示のための計算や表示のさせ方の複雑さはあります。高度に正規化されて、複数のテーブルを統合しないとデータを表示できません。投入履歴をスライスする感じでデータの反映時間をベースとしたリビジョンが作られ、どの段階でも検索により取り出せるように求められています。このようなシステムと仮定します。

ここでPMは判断を迫られます。スケジュール遅延をお客様に話して、SINを遅らせることを交渉するか、内部で無理してでも間に合わせる努力を最後までするか。

通常はスケジュール遅延をお客様に報告しつつ、最大限の努力をしている旨ご理解いただき、最悪、SIN日程が守れないことを報告します。本当にSINに間に合わないことがほぼ確実になった段階では、正直にそのようにいうしかないのですが、精神論で頑張ってしまった場合、お客様がSIN遅延の覚悟ができていないことがあります。

遅く報告した場合、次期によってお客様内部や外部への（接続関係や既存システムの停止撤去の工事日程、既存システムがリース契約であった場合リース延長手続きが間に合うか、延長のための費用が確保できるか？サービス開始を期待しているお客様へのプレスリリースの手配、損害賠償への準備など）様々な調整が間に合わなくなり多大な迷惑をおかけすることがあります。

この判断をするに当たって、この例では始末が悪いことに、「ものができていて、品質が悪いだけ、バグをつぶせれば大丈夫、」かのように見えることです。

すでに大量の人員を投入し、テストチームと開発チームに分かれていて、開発チームはサブシステムごとに方端からバグをつぶしていきます。チームリーダはPMのしんなりする人で構成されており、幾多の修羅場(大量のバグつぶし)をくぐってきた人たちです。

マネージメント層はバグの収束曲線を見ます。

バグは日々たくさん出るが直る数も多く、頑張ればバグはなくなるように見えます。ここでほんの少しSINを遅らせるだけで収束するように見えます。

「あと二週間徹夜すれば！！」本当にそうか？
続く・・・

実話かはノーコメントです