デスマーチの終焉 [中編]

デスマーチに引導を渡すには、何をしたら良いんだろう。

問題を解決するときに踏む手順は、いつも同じだと思う。原因を突き止めて、それを除くアイディアを出し、実践する。じゃあ、デスマーチの原因は、一体なんだろう。

  • 必要工数(期間 or 人員)が、足りない。
  • 開発者(デベロッパ)が、アッパラパー。
  • 管理者(マネージャー)が、アッパラパー。
  • 営業が、アッパラパー。
  • 顧客が、アッパラパー。
  • パラッパラッパー。

個人的な経験から言うと、はじめの原因、工数不足は、間接的な原因でしかないと思う。期間も人員も膨大だとしても、デスマーチは起こる。結局、ふたつ目以降の人間の問題が、大きいのだと考えている。パラッパラッパーはさておき。

デスマーチのとき、一番の憂き目に遭うのは、開発者、特に末端のプログラマやテスターだろう。中心(顧客)から遠ければ遠いほど、振られる幅は大きくなる。これ自然の摂理。

確かな仕様書もなく、自分の書いたソースコードが仕様になるような場合、プログラマのストレスは最高潮に達する。ようやく何とか動くアプリケーションをこさえても、「仕様と違う」とか腐れSEに言われてしまうのだ。仕様なんて無かったとしても。

ただ、ここで愚痴を言うだけのアッパラパー開発者ばかりだと、デスマーチは終わらない。何らかの対策をこうじなければ、同じことが延々と繰り返されるだけ。

一方、デスマーチ時の管理者の心労も、とんでもなく大きい。問題は増えるばかりで、減る見込みがない。厳しい状況が続けば、管理下のプログラマが退職することも出てくる。人のディスパッチ、スケジューリングなど、どう考えても無理な線を引かざるをえない。

ただ、ここで明らかに無理な線票をつくるアッパラパー管理者がいては、デスマーチは終わらない。何らかの対策をこうじなければ、いつか線票から線が消えてしまう。

アッパラパー営業とアッパラパー顧客は、こうした現場の状況を、少し知るだけでも違いが出てくると思う。それでもデスマーチは終わらないけど。

じゃあ、一体どうしたらデスマーチは終わるのだろうか。(つづく)

このエントリーのトラックバックURL
http://www.deftrash.com/admin/mt4/mt-tb.cgi/307