(Sat)Tweetデスマーチに引導を渡すには、何をしたら良いんだろう。問題を解決するときに踏む手順は、いつも同じだと思う。原因を突き止めて、それを除くアイディアを出し、実践する。デスマーチの原因は、一体なんだろう。開発者(デベロッパ)が、アッパラパー。管理者(マネージャー)が、アッパラパー。営業が、アッパラパー。顧客が、アッパラパー。個人的な経験から言うと、はじめの原因、工数不足は、間接的な原因でしかないと思う。期間も人員も膨大だとしても、デスマーチは起こる。結局、ふたつ目以降の人間の問題が、大きいのだと考えている。パラッパラッパーはさておき。デスマーチのとき、一番の憂き目に遭うのは、開発者、特に末端のプログラマやテスターだろう。中心(顧客)から遠ければ遠いほど、振られる幅は大きくなる。確かな仕様書もなく、自分の書いたソースコードが仕様になるような場合、プログラマのストレスは最高潮に達する。何とか動くアプリケーションをこさえても、「仕様と違う」とか腐れSEに言われてしまうのだ。仕様なんて無かったとしても。ここで愚痴を言うだけのアッパラパー開発者ばかりだと、デスマーチは終わらない。何らかの対策をこうじなければ、同じことが延々と繰り返されるだけ。デスマーチ時の管理者の心労も、とんでもなく大きい。問題は増えるばかりで、減る見込みがない。厳しい状況が続けば、管理下のプログラマが退職することも出てくる。人のディスパッチ、スケジューリングなど、どう考えても無理な線を引かざるをえない。ここで明らかに無理な線票をつくるアッパラパー管理者がいては、デスマーチは終わらない。何らかの対策をこうじなければ、いつか線票から線が消えてしまう。アッパラパー営業とアッパラパー顧客は、こうした現場の状況を、少し知るだけでも違いが出てくると思う。それでもデスマーチは終わらないけど。したらデスマーチは終わるのだろうか。