デスマーチの終焉 [中編] | dTblog | デザインとプログラムの境界をさまようブログ

デスマーチに引導を渡すには、何をしたら良いんだろう。 問題を解決するときに踏む手順は、いつも同じだと思う。原因を突き止めて、それを除くアイディアを出し、実践する。じゃあ、デスマーチの原因は、一体なんだろう。 必要工数(期間 or 人員)が、足りない。 開発者(デベロッパ)が、アッパラパー。 管理者(マネージャー)が、アッパラパー。 営業が、アッパラパー。 顧客が、アッパラパー。 パラッパラッパー。 個人的な経験から言うと、はじめの原因、工数不足は、間接的な原因でしかないと思う。期間も人員も膨大だとしても、デスマーチは起こる。結局、ふたつ目以降の人間の問題が、大きいのだと考えている。パラッパラッパーはさておき。 デスマーチのとき、一番の憂き目に遭うのは、開発者、特に末端のプログラマやテスターだろう。中心(顧客)から遠ければ遠いほど、振られる幅は大きくなる。これ自然の摂理。 確かな仕様書もなく