なつかしきエンジニアのデスマーチあるあるまとめてみた

IT業界はブラックだ、うつ病になる、最悪の場合過労死する、といったイメージがあるかもしれません。噂が一人歩きしている感じもありますが、すべてがまったくの嘘だというわけではありません。

そもそも人間は長時間パソコンの前で考え続けるようにはできていないので、向き不向きによって中には体調を崩す人がいるのも事実ですね。そんなIT業界動向の中でもよく話題になる現象の一つがデスマーチです。最近ではだいぶ見かけなくなりました。

日本語では「死の行進」とも言われますが、要するにプロジェクトにおける過酷な労働環境を指します。実際どのくらいになるとデスマーチかは微妙ですが、だいたいスケジュールが押していて徹夜や休日出勤が当たり前の状況になってくると「デスマ」と言っている人がちらほら出てきます。

単に納期が遅れていて残業が多くなっている状況や、突発的な不具合で深夜作業するような状況だとデスマーチとは言わないかと思います。デスマーチに明確な定義があるわけではありませんが、実際のプロジェクトではだいたいこのような感覚で使われています。

このページでは、そんなデスマーチのあるあるをまとめてみました。

なぜか嬉しそうな人がいる

デスマーチは作業が終わるまで寝れない、帰れない、といった過酷な状況なのですが、なぜ毎回嬉しそうにしている人が現場に何人か存在します。具体的には、「今日も徹夜だー」「終電なくなったwww」「デスマ最高！」といった発言です。

自分を鼓舞するためにあえてそのような発言をしているとも取れますが、私が見ている限りそうではなさそうでした。単純に仕事が好きだということもあるかもしれませんが、それよりは忙しい自分に酔っている、自分が会社やプロジェクトから強く求められている感じがする、といった理由が大きいように思います。

なぜなら、自分がどれだけ忙しいか、プロジェクトにとって必要な人材かを熱弁する人が多いからです。人によっては、デスマーチにのみ快感を覚えるデスマーチ依存症のようになっています。

デスマーチに陥る原因は？

冗談のような話に思えるかもしれませんが、実話です。デスマーチに陥る原因にはそもそもの納期に無理がある、人が足りていない、スキルが足りていない、クライアントからの仕様変更が多い、連係ミスが多い、といったことが挙げられます。

きちんと考えれば改善できそうな部分も多いのですが、責任の所在が不明確なまま放置され、非効率な状況でプロジェクトが進んでいくことも多いのです。それと同時に、開発現場にデスマーチを喜ぶ人が存在すれば、なおさらですマーチはなくならないでしょう。

デスマーチを喜ぶ人を批判するつもりはありませんが、「最近のプロジェクトは生ぬるい」「昔は3日徹夜も当たり前だった」「こんなのはプロジェクトではなくプロジェクトごっこだ」といった発想はどうかと思います。

効率的に短時間で終わるのであれば、それに越したことはないでしょう。

朝出勤すると床で寝ている人がいる

デスマーチの状況では、終電で帰れる空気ではなくなります。終電過ぎてからが勝負だとよくわからない発言をしている人もいます。私自身は終電を過ぎても現場から家が少し遠ければタクシーで、近い場合はロードバイクで出勤していたので、ロードバイクで帰宅していました。

しかしいったん帰るのが面倒、そのまま寝て起きて作業した方が効率的だ、といった理由でオフィスに泊まり込んでいる人も多いです。しかし椅子だと寝にくいため、だいたいは床で寝転んでいるのです。

なので、朝出勤するとそのまま床で寝ている人がいます。特にこれに問題があるというわけではなく、床で寝ている人を見ると今ってデスマーチなのかな、と思ったりします。

失踪する人が出てくる

アルバイトのばっくれなどは割とよくある話かもしれませんが、デスマーチの状況では正社員が失踪します。失踪というよりは、出勤しなくなります。もちろん電話をしてもつながりません。

どこで何をしているのかは定かではありませんが、おそらく自宅に引きこもって寝ているかゲームなどをしているのでしょう。出勤すればまた夜中か次の日の朝まで帰れなくなるので、行きたくなくなるのです。

本人の精神状態まではわかりませんが、おそらくうつ状態やそれに近い状態の人もいるのでしょう。デスマーチの環境下ではバグや手詰まりも発生しやすく、いわば解決できそうもない問題に悩まなければならないこともあります。

解決できないにも関わらず、周囲やクライアントからはプレッシャーが掛かります。すぐに相談したりできれば良いのですが、もともと相談するのが苦手な人だったり、周囲も忙しそうだから声を掛けづらかったということもあるでしょう。

デスマーチのときはみんなが忙しくなるので、コミュニケーションを取らずに悩みを抱える人が多発します。忙しくてもうまくスケジュールを消化できていれば良いのですが、パンクして手が止まってしまうと追い込まれていきます。

その結果、失踪という形につながってしまうのです。そして一人失踪するとプロジェクトの負担はより大きくなり、また別の人も失踪してしまうことがあります。

「失踪者が出たからプロジェクトがより忙しくなるし、あの人も失踪したから自分もいいかな」といった感じかと思います。負の連鎖を招き、デスマーチに拍車が掛かります。

バグが増える

デスマーチになるとバグが増えるため、さらにデスマーチの状況が悪化します。バグが増える理由としては、まず作業量が多すぎるせいで一つ一つのコードが雑になります。

見直している時間もあまりないため、結果的にミスにつながります。そして一か所ミスをすると関連する部分もミスをしやすいため、バグはどんどん膨らんでいきます。

次に、上で説明した通り人が失踪すると誰かが引き継がなければなりません。プロジェクト内の人が引き継ぐ場合もあれば、また人を増やして代わりに担当する場合もあります。

代わりの人が入る場合その人はまだ仕様をきちんと理解していないのですが、それでも誰かが付いてきっちり説明している余裕がありません。その結果、新しい人は仕様がよくわからないまま手さぐりで作業を進めることになります。

手さぐりの状況にも関わらずすでに現場はデスマーチなので、パニックになってバグのオンパレードです。収集が付かなくなり、加速していくのがデスマーチの特徴の一つです。

仕様変更が重なる

デスマーチでただでさえ忙しいのに仕様変更も多いのかよ、と思われるかもしれません。しかし、デスマーチだからこそ仕様変更が重なるとも言えます。デスマーチはそもそもスケジュールに余裕がないことが大きな原因で生まれるのですが、スケジュールに余裕がないということはクライアントも焦っているということです。

早くリリースしなければならない状況で急いでシステム設計のための要望をだしていたりするので、そもそもの要件定義に問題があるケースも多々あります。プロジェクト内部も外部も余裕がないため、混乱して仕様がどんどん変わっていくのです。

さらに悪いことに、仕様変更が重なると当然連係ミスが起こりやすくなります。一つのミーティング内でも仕様がああでもないこうでもないと話し合われるので、結果的にどこに落ち着いたのか曖昧なままになってしまうこともあるのです。

認識を合わせるのが重要

そうすると、連動するシステムでたとえばAさんは仕様Aに基づいてプログラミングしているのに、Bさんは仕様Bに基づいてプログラミングしている、そして結果的に正解は仕様Dだった、といったことがかなり頻繁に起こります。

一人一人がバラバラの仕様に基づいてプログラミングしていたり、仕様変更が反映されていなかったりします。このように、悪いことに悪いことが重なるのがデスマーチです。

ちなみに、仕様変更が重なるともともと動いていたソースコードまで動かなくなることが多々あります。それはバラバラに修正を加えたため、他の人の担当部分との連携がうまくいかなくなるからです。

リリース後すぐにトラブルが発生する

デスマーチを乗り越えてようやくリリースしたと思ったら、その後すぐにトラブルが発生することが多々あります。これまでの流れでもわかるかと思いますが、デスマーチの状況ではトラブルが多発しています。

すべてのトラブルを確実に直しているような時間も余裕もないので、結果的に「なんとかバグが発生しませんように」と祈りながらリリースするようなことが多いのです。

そして、残念ながらその祈りは届かないことが多いです。システムは書いた通りにしか動かないので、人間がいくら強く祈ったところで動きが変わってくれるわけではありません。

必死に完成させた挙句、また修正対応に追われる日々が始まるのです。

日に日にハゲていく人がいる

これは番外編ですが、実際に目にした光景です。私の正面にこちらに後頭部を向ける形で座っている人がいたのですが、その人の頭頂部が日に日に後退していっている感じがしました。

もともと薄毛ではあったのですが、数か月前には一応前髪と呼べるものはあったかと思います。また後ろから見たときはハゲてはいませんでした。しかしデスマーチに突入してからは正面から見るとひよこの毛のようなものしかなく、後ろから見ても頭頂部がハゲているのがわかりました。

すべてデスマーチの影響かどうかはわかりませんが、その人の場合頭頂部でもデスマーチが進んでいたようです。デスマーチは身も心も髪の毛もダメージを受ける作業で、その先に素晴らしい恩恵があるわけでもありません。

中にはデスマーチを通して成長したと感じているエンジニアもいるかもしれませんが、基本的には明らかなオーバーワークです。デスマーチを避けたいと言って簡単に避けられるものではないのですが、なるべくなら避けたいものですね。