デスマーチの終焉 [中編]
デスマーチに引導を渡すには、何をしたら良いんだろう。
問題を解決するときに踏む手順は、いつも同じだと思う。原因を突き止めて、それを除くアイディアを出し、実践する。じゃあ、デスマーチの原因は、一体なんだろう。
- 必要工数(期間 or 人員)が、足りない。
- 開発者(デベロッパ)が、アッパラパー。
- 管理者(マネージャー)が、アッパラパー。
- 営業が、アッパラパー。
- 顧客が、アッパラパー。
- パラッパラッパー。
個人的な経験から言うと、はじめの原因、工数不足は、間接的な原因でしかないと思う。期間も人員も膨大だとしても、デスマーチは起こる。結局、ふたつ目以降の人間の問題が、大きいのだと考えている。パラッパラッパーはさておき。
デスマーチのとき、一番の憂き目に遭うのは、開発者、特に末端のプログラマやテスターだろう。中心(顧客)から遠ければ遠いほど、振られる幅は大きくなる。これ自然の摂理。
確かな仕様書もなく、自分の書いたソースコードが仕様になるような場合、プログラマのストレスは最高潮に達する。ようやく何とか動くアプリケーションをこさえても、「仕様と違う」とか腐れSEに言われてしまうのだ。仕様なんて無かったとしても。
ただ、ここで愚痴を言うだけのアッパラパー開発者ばかりだと、デスマーチは終わらない。何らかの対策をこうじなければ、同じことが延々と繰り返されるだけ。
一方、デスマーチ時の管理者の心労も、とんでもなく大きい。問題は増えるばかりで、減る見込みがない。厳しい状況が続けば、管理下のプログラマが退職することも出てくる。人のディスパッチ、スケジューリングなど、どう考えても無理な線を引かざるをえない。
ただ、ここで明らかに無理な線票をつくるアッパラパー管理者がいては、デスマーチは終わらない。何らかの対策をこうじなければ、いつか線票から線が消えてしまう。
アッパラパー営業とアッパラパー顧客は、こうした現場の状況を、少し知るだけでも違いが出てくると思う。それでもデスマーチは終わらないけど。
じゃあ、一体どうしたらデスマーチは終わるのだろうか。(つづく)
Posted by dT by 01:22
トラックバック
このエントリーのトラックバックURL
コメント
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31