あるPJでバグは日々たくさん出るが直る数も多く、頑張ればバグはなくなるように見えました。
ここでほんの少しSINを遅らせるだけで収束するように見えます。
「あと二週間徹夜すれば！！」本当にそうか？

このときの収束曲線

開発を経験しているのであれば、バグが日々出ていることに着目して、「この時期にこんなにバグって出るもんだっけ？」と疑います。さらにバグの中身を見ます。単純な表示上の問題や計算の問題に見えるものが多いです。数十の画面で表示されるべきものが表示されなかったり、別のものが表示されたり。ここで「あれ？」と感じる人も多いでしょう。「バグの数が多すぎます。別のものが表示とは？表示されなかったり？数からいう１画面あたり１回以上？」どういう作りをするとそんなことに？
実態は、あまりにもバラバラに正規化されたテーブルを集めてデータにするところを一か所に集めてルーチン化したのですが、パターンが増えるごとにそこに手を加えていって、ものすごい巨大な関数がいつの間にか出来上がっていたのでした。なので問題があると、そこだけ直せば直るのですが、影響調査がしきれず、ほかのところに影響が出て、新たなバグになり・・・・バグの収束の速さとバグが出る量が多いことはそこが原因でした。「典型的スパゲッティー・・・」
それをほぐすには！とすぐに期間の見積もりを指示しますが、１月２月ではとてもやりきれないほどめちゃめちゃに・・・仕様の整理も十分にされていないようです。たとえバグをつぶしていって機能要件を満たしたとしても、性能要件での問題が起きそうです。
これは死亡プロジェクトの例です。行きつく先は契約解除と損害賠償です。(実例かどうかはノーコメント)
仕様がはっきりしない段階から開発をはじめ、仕様が明確になるにしたがって、機能を追加していった結果のコードでした。(最初に単機能のものを作り、あとから追加された機能をその機能に追加しました。あとから予想もしない機能がどんどん言われて、それも追加していくうちに、後戻りできず、現場はさらに追加し続けてしまった)現場のプログラマに開発を任せ、ウオーターフォールを無視して、設計レビューをせずにものの完成のみを追っていったために起きたのでした。アプリケーションアーキテクチャを機能全体を見て設計していたら避けられた事態です。
サービスイン直前まで数字のみを追って、現場の報告をうのみにしてきたためにそうなってしまったのです。開発経験をしたことがある人は何となくわかると思いますが、中身を見るPMであればもっと前から問題点に気が付いたであろう、予兆が見えたと思います。
上記例では技術上がりの管理者としては火を噴いた後から「たーすーけーてー」という声を受けて支援に入ったところで事態がわかるということになるかと思います。もっと早くから事態がわかっていれば打てた対策もあるかもしれません。

本来の収束曲線

どうするか！「解(solution)」に書きます