デスマーチを経験して感じたこと
２月から３月にかけて一か月休みのない状態が続いた。
いわゆるデスマーチに陥ってしまった。
精神的にも肉体的にもつらい状況だが、ようやく
落ち着きつつあるので、振り返る意味でも感じたことを書こうと思う。
[プロジェクトの概要]
会員管理システムのリニューアル
既存システムのリニューアル。
機能数は約300。
リニューアルではあったが、半分ぐらいは新機能の追加だった。
期間は約1年半。
ベンダーが間に入った２次請。
[デスマーチ]
本稼働後に多くの不具合が発生し、
日中に対応できず、夜間の対応に追われ
泊まり込み、休日出勤が続いた。
[デスマーチが起こった原因]
・テストが不十分
期間はそれほどきつくはなかったはずだったが、
スケジュールが押してしまい、作るのがやっとで
単体テストもままならなかった。
・業務を分かっているメンバーが少なかった。
旧システムを知っているメンバーが少なく、
業務自体を理解せずにプログラムを作成したため、
運用に沿ったテストが行えなかった。
・受け入れテストの期間不足
ベンダーの受け入れテストがほとんどなく、
本格的に受け入れテストが行われたのは約１週間前。
・修正作業が夜間になった
日中に発生した不具合の対応が翌日までに対応しなければ
ならないことが多く、夜間作業になった。
プログラムを修正後、ベンダーに確認を取ってもらうため
そこでも時間がかかってしまった。
[反省点]
・スケジュールが遅れ気味になった時に対策を打てなかった。
期間が長かったので途中で立て直すチャンスはあったと思う。
・業務を理解したテストを行えなかった。
本稼働後に発生した不具合のほとんどが業務を理解して
テストできていれば防げたものが多かった。
・優先度の切り分けができなかった。
ベンダーがはいっているため、不具合の優先度が
分かりにくかった。すべてが急ぎでやらなければならないような
状況に陥った。
[今後に向けて]
一か月休みのない状態になったのは初めての経験だったし、
二度とこのような経験はしたくない。
そのためにも今後このようなことがないように
今回の反省を生かしたい。
・スケジュールの遅れが発生したら早めにチェックする
・業務を理解したテスト、テスト仕様書の作成を行う
・受け入れテストについてベンダーと話し合う
→今回はあいまいになっていたが、受け入れテストなしには
うまくいかない。一括でまとめて受け入れテストを行うのは
労力がかかるが、機能のカテゴリごとに分割してやってもらうことを
提案したい。
とにかく思ったのはテストの不十分さ。
単体レベルでテストできたとしても業務に即した
動きになっているかをテストしないとテストとしては不完全。
