デスマサバイバルガイド
はじめに
僕がよく知っている業界は SI だが、これに限らずソフトウェア開発の現場には、過酷な現場…いわゆるデスマーチが多いと言われている。
一方で、そのような過酷な現場を渡り歩き生き残ることでしか、良いプログラマになる方法は無いと言った考え方もある。僕の個人的な経験則からすると、この理屈はある程度合っていると思う反面で、合っていて欲しくないという気持ちは強い。
高い技術力をもつプログラマの全てがデスマ職人という訳ではない。
デスマーチに巻き込まれたと気が付いた時の妥当で基本的な戦術は撤退戦だ。何か理由をつけて逃げ出すのが望ましい。つまり、休職なり退職なり、異動なりして、その職場から離れるのが望ましい、出社拒否も良い。しかしながら、何か様々な理由があって、そこから逃げ出せないことはあるだろう。
僕はもう長い事デスマーチに関わることなく生きられているが、徐々に忘れつつあるので、若いころに獲得したデスマーチを生き残る方法論について記録しておく。
最初に断っておくが、これから経験則に基づく医学的根拠のない知見を披露する。あなたが、それに基づいて行動した結果について僕は一切の責任を負わない。
デスマーチとは何か
ソフトウェア開発におけるデスマーチとは、おおむね終わる見込みが無いのに、様々な思惑がかみ合うことで何故か資金が投入され続けるプロジェクトのことである。
資金を獲得する際には、比較的過酷な努力目標が設定されるため、そこで稼働する労働者に対して高負荷を与えることが多い。
本稿ではデスマーチ（以後、デスマ）を生き残る技術について説明したいので、デスマが何であるかについては３６協定の限度時間を参照しておく。基準が厳しすぎると感じるかもしれないが、時間外労働をさせる場合の基準時間に抵触するプロジェクト、つまり一ケ月で時間外労働が４５時間を超えるプロジェクトは全てデスマであると考えるべきだ。
あなたが若かったり、経験豊富であったり、プロジェクトの人間関係が良好であったりと、様々な副次的な要件が満たされることによって、そのようなプロジェクトにいるにも関わらず特に危険を感じていないかもしれないが、それは大変幸運なことだと考えるべきである。