システム開発者なら誰もが一度は経験し、のちに武勇伝のように語られるデスマーチ。あの悲惨な状況から脱する方法を、考えてみる。

そもそもデスマーチとは何なのか。

実は最初、「多くの会社が年度末になる3月は忙しい」という意味だと勘違いしていた。マーチ違い。そうではなく、日本語に訳せば「死の行進」となるのが、デスマーチ。その定義に確固たるものは無いっぽいけど、単に「忙しい」のとは違う。底なし沼にズブズブ沈んでいくような感じが、デスマーチだと思っている。

たとえば。

• 仕様は固まっていないが、リリース時期が間近なため、とりあえず「動く何か」を作らなければならない。
• 仕事量に対する工数が足りない。各人の負担が大きいので退職者が出て、残った人の仕事量が増える、という状況がループ。
• １つの問題の解決に、2つ以上の問題を解決が要求され、問題がねずみ算で増えていく。
• 非効率な方法と分かっていても、目前の納期を死守するために、その手段を用いなければならない。

これは、単に締切が近く、土日もなく働きつづけなければならない忙しさと、ワケが違う。「ここさえ耐えれば」というポジティブ思考が、通用しないから。やればやるほど、ストレスが増えるばかり。ううう。

僕は、これまでシステム開発とWeb制作の両方を扱ってきた。忙しさで言うと、短納期になりがちなWeb制作の方が、キツイもんがある。ただ、Web制作のそれはデスマーチとは違う。一方のシステム開発は、デスマーチ的要因のせいで、精神的にキツイ。

さて、そんなデスマーチに終焉は訪れるのか。(つづく)