プロジェクトを操縦する4

id:juratena:20070317
品質に問題があったプロジェクトAは、三回のリリースを行うようになっていたが、三回ともすべて失敗した。
1回目のリリースはリリース翌日の夜間バッチで異常停止した。原因はデータベース環境とプログラムのアンマッチが原因だが、アンマッチはそのリリースによって作られた。影響を受けたプログラムはリリース対象とは別のプログラムで、そのプログラムに対するテスト不足というかテスト未実施であったことが発覚した。正確には設計の段階から影響の可能性すら検討されていなかった。
2回目のリリースはお客様のリリース検証環境への導入時に発生した。原因は1回目のリリースと同じ。なんと、まったく同じミスをしでかしてしまったのだ。
3回目のリリースはデータ移行の必要性をまったく検討せず、データ移行なしでプログラムをリリースしてしまった。
これら三つのリリースの問題は自前の費用でコストを支払うことになった。我々としても状況把握や対応にコストを要したが、それらについての請求は今回は見送られた。

納期に問題が発生しているプロジェクトBはというと、いままさに続行中であるが、約12週の内、残り3週で二週間の遅れとなった。週次で進捗打合せをしていたが、意識的であったのか無かったのか、再計画の繰り返しによって隠されてしまい、再計画を停止させ厳密に確認したところ間に合わないということがわかった。しかも二週間でのこり四週。もっと早く手を打つべきだが手遅れにならなくて済むところで発見できてよかった。この時点で請負会社の方へひとつpingを打った。一括請負のスキームの中のことなので期日が完了していない時点でまだとやかく言うことではないがもし万が一のことがあれば被害を直接的にこうむるのはこちらの方である。リスクは早い段階で発見できることが重要なのだ。