新しく学んだ事

業務システムの受託開発を主に行っています。人生日々勉強。日々新しく学んだ事を記します。

デスマーチを経験して感じたこと

2月から3月にかけて一か月休みのない状態が続いた。

いわゆるデスマーチに陥ってしまった。

精神的にも肉体的にもつらい状況だが、ようやく

落ち着きつつあるので、振り返る意味でも感じたことを書こうと思う。

 

[プロジェクトの概要]

会員管理システムのリニューアル

既存システムのリニューアル。

機能数は約300。

リニューアルではあったが、半分ぐらいは新機能の追加だった。

期間は約1年半。

ベンダーが間に入った2次請。

 

[デスマーチ]

本稼働後に多くの不具合が発生し、

日中に対応できず、夜間の対応に追われ

泊まり込み、休日出勤が続いた。

 

[デスマーチが起こった原因]

・テストが不十分

 期間はそれほどきつくはなかったはずだったが、

 スケジュールが押してしまい、作るのがやっとで

 単体テストもままならなかった。

・業務を分かっているメンバーが少なかった。

 旧システムを知っているメンバーが少なく、

 業務自体を理解せずにプログラムを作成したため、

 運用に沿ったテストが行えなかった。

・受け入れテストの期間不足

 ベンダーの受け入れテストがほとんどなく、

 本格的に受け入れテストが行われたのは約1週間前。

・修正作業が夜間になった

 日中に発生した不具合の対応が翌日までに対応しなければ

 ならないことが多く、夜間作業になった。

 プログラムを修正後、ベンダーに確認を取ってもらうため

 そこでも時間がかかってしまった。

[反省点]

・スケジュールが遅れ気味になった時に対策を打てなかった。

 期間が長かったので途中で立て直すチャンスはあったと思う。

・業務を理解したテストを行えなかった。

 本稼働後に発生した不具合のほとんどが業務を理解して

 テストできていれば防げたものが多かった。

・優先度の切り分けができなかった。

 ベンダーがはいっているため、不具合の優先度が

 分かりにくかった。すべてが急ぎでやらなければならないような

 状況に陥った。

 

[今後に向けて]

一か月休みのない状態になったのは初めての経験だったし、

二度とこのような経験はしたくない。

そのためにも今後このようなことがないように

今回の反省を生かしたい。

・スケジュールの遅れが発生したら早めにチェックする

・業務を理解したテスト、テスト仕様書の作成を行う

・受け入れテストについてベンダーと話し合う

 →今回はあいまいになっていたが、受け入れテストなしには

  うまくいかない。一括でまとめて受け入れテストを行うのは

  労力がかかるが、機能のカテゴリごとに分割してやってもらうことを

  提案したい。

とにかく思ったのはテストの不十分さ。

単体レベルでテストできたとしても業務に即した

動きになっているかをテストしないとテストとしては不完全。