単なる“ブラック”ではない

　デスマーチ。死の行進である。システム開発の現場にいれば、一度はデスマーチに加わってしまった経験があるはず。どんなに優秀なエンジニアでも、顧客やプロジェクトマネージャなどに引きずり込まれてしまう。

　長期の大型プロジェクトであれば、どの業界でも起こりそうなものだが、何かとIT業界でクローズアップされる。その理由を考える前に、まずは筆者によるデスマーチの定義を紹介したい。

　「『作業量が多い』『忙しい』だけでは、個人的にはデスマーチと呼びたくないです。プロジェクトに問題が発生していて、『その問題に対して今打っている対策が、真の対策足り得ないこと』を誰もが意識しつつ、しかしそれを選択せざるを得ない状況になったとき、デスマーチだな、と私は考えます」。そして、マーチ（行進）であることから、一人ではなく、チームの状態を指す。

　デスマーチとなる要因について、本書ではIT産業が成熟期に入ったことをあげている。例えば、当初は趣味の延長のプログラマが多かったが、企業規模が大きくなるにつれて、会社員としてのプログラマへと変わっているということ。趣味の延長であれば、デスマーチを苦痛とは感じにくい。“会社員化”が、それを苦痛に変えたというわけだ。

　限られた期間、決まらない仕様。そのような現場は数多く、デスマーチが起こりやすい環境にある。本書でも解決に向けた妙案は見当たらない。であれば、まずは問題意識をもつこと。それが大切だ。（亭）

『デスマーチはなぜなくならないのか』
宮地弘子　編
光文社　刊（760円＋税）