SEやプログラマーは激務？IT業界のデスマーチってどのくらい辛くて大変なの？【体験者が語る】

IT業界の話になるとかならずといっていいほど出てくる負のワード、それが「デスマーチ」です。ツイッターなどでも頻繁にネタとして扱われます。

しかし、まだデスマーチを体験したことがない人、これからIT業界で働こうと考えている人には、いまいちどういうものかわからないかもしれません。

そこで、今回はデスマーチというものがどういうものなのか、私の体験からご紹介していきます。

デスマーチとは

「デスマーチ」とは、その過酷な労働状況を「死の行軍」となぞらえて名付けられたIT用語です。極度の時間外労働と休日出勤によってエンジニアが疲弊していく様は、まさにデスマーチと呼べるものです。私も何度か経験したことがありますが、その過酷さは想像以上のものでした。

「デスマーチ」は和製英語のように思われる人もいるかもしれませんが、意外なことにこの言葉を作ったのは日本人ではなくアメリカ人でした。

エドワード・ヨードン氏はその著書『デスマーチ：なぜソフトウエア・プロジェクトは混乱するのか』の中でデスマーチがなぜ起きて、どのように失敗していくのかを分類しています。詳しくは書籍をお読みください。

さて、デスマーチのキツさは期間によってさまざまですが、ちょっと残業時間が多くなってくらいではデスマーチとは呼びません。デスマーチと呼ばれるのはどこからでしょうか？これはハッキリと定義されているものではありませんので、あくまで私の考えとしてご理解ください。

どこからデスマーチなのか？

私は1ヶ月以上の長時間残業が続けばデスマーチであると考えます。1、2週間程度毎日終電まで残業するなんてことはどこの業界でもあることでしょう。これが土日出勤を挟んで1ヶ月以上続けばそれは立派なデスマーチです。

残業時間で見てみましょう。定時が5時、終電が11時の人で考えると1日6時間の残業です。

つまり、平日は6時間×5日で30時間。これに土日どちらか、もしくは両方出勤した場合、40時間～50時間の残業時間となります。1ヶ月で残業が100時間を超える人がいるプロジェクトはかなりの末期状態であるといえるでしょう。

私もこの状態になったことが1度だけありました。

私のデスマーチ体験記

それでは、私の経験したデスマーチをご紹介していきます。デスマーチになった経緯、そしてプロジェクトはどのように変化していったのかなどを交えて回想していこうと思います。

この人数じゃ無理でしょ！残業時間80時間超えのアプリ制作

このプロジェクトはもともと3人でスタートしたプロジェクトでした。PM（プロジェクトマネージャー）とPL（プロジェクトリーダー）である私、それと外注で参加しているプログラマーの3人です。

最初は要件定義から入り、設計までは順調に進んでいきました。どのプロジェクトも設計まではだいたい普通に進みます。問題が起きたのは実装フェーズに入ってからでした。このプロジェクトはWindowsアプリの開発でしたが、実行環境が特殊でまったく新しいフレームワークで開発する必要がありました。

どのメンバーも従来の方法とは異なる実装方法に手間取り、少しずつスケジュールが遅延していきました。本来であればスケジュールの遅延が見え始めた段階でテコ入れすればよかったのですが、残業にうるさい会社だったので、19時以降の残業に申請が必要でした。そのため、遅延は少しずつ累積していき、気づいたときにはかなりの遅れになっていたのです。

新しい技術を使った開発では検証だけで1日、2日取られてしまうことも珍しくありません。スケジュールにはあらかじめ余分に「遊び」の日程を入れておくのが通常ですが、その余裕すら食いつぶしてしまうほど技術検証に時間を取れられてしまいました。

最終的に、実装段階で他プロジェクトから応援を呼び、最後は事業部長までもがスケジュール管理に周ることに。総勢10名で開発、テストまでを突貫工事することになりました。約2ヶ月間はデスマーチが続きました。私も毎日終電は当たり前、土日はどちらか出勤するほどになってしまい、月の残業は80時間ほどになっていました。

＜原因＞
新技術であるにもかかわらず、アサインされたメンバーが少なすぎた点が挙げられます。実装フェーズに入って技術検証に手間取っている時点で間に合わないことは明白でした。しかし、上にアラートを投げても他プロジェクトも一杯いっぱいの状態で、応援部隊を呼ぶこともできませんでした。結局、他プロジェクトが完了し、応援部隊が駆けつけた時点で火の車になっていたのです。

＜プロジェクトの雰囲気＞
最初は和気あいあいと進んでいたプロジェクトでしたが、状況が悪化するにつれ雰囲気は悪化していきました。とくに、実装チームと管理側でギクシャクしてしまったのが失敗でした。

スケジュールどおりに進めたい管理側と、進めたくても新技術で予定どおりに進まない実装側がぶつかることもしばしば。どうにか着地できたのは部長とPMが全面的に指揮を取るようになってからです。力不足を痛感したプロジェクトとなりました。

月の残業時間160時間！精神を病みかけた医療プロジェクト

もう1つは私が新人のときのプロジェクトです。新規プロジェクトの立ち上げに携わることができたのですが、このプロジェクトが地獄でした。今となっては笑い話ですが、本気で精神を病みそうになりましたし、実際に先輩社員が2人精神を病んで退職してしまいました。

このプロジェクトは最終的にメンバーが30人ほどの規模に膨れ上がりましたが、新人の私はなぜか主幹機能を担当することになりました。新人研修を終え、OJTも終わって間もない新人にプロジェクトの命運を分ける機能を任せるなんて、今考えても謎だらけの人選でした。

このプロジェクトは設計段階からすでに怪しい雰囲気が出ていて、実装に進む時点で炎上が始まっていました。そこから毎月120～160時間の残業時間を約10ヶ月続けました。平日は終電帰り、土日はどちらか出勤、たまに徹夜もしながらの作業は本当に地獄でした。

ここまで長期間＆長時間を会社で過ごしていると、家に帰るというよりも会社から出かける感覚に近くなってきます。ひたすら働き、家に帰って寝る、ということを繰り返すだけの日々は単調で少しずつ精神がおかしくなっていくのがわかりました。

＜原因＞
このプロジェクトは、そもそも不確定要素が多すぎるプロジェクトでした。新技術を使った開発、経験がないプロジェクトマネージャー、経験の少ないデザイナーなど、さまざまな要因があったと思います。

しかし、最大の要因はシステムコンサルティング会社とクライアントです。システム開発ではよくありがちなのですが、クライアントのシステム開発担当が途中で交代するという事態が発生。それまで進めてきた要件定義が白紙に戻されてしまいました。さらに、間に入っていたシステムコンサルティング会社が話をややこしくしてしまい、開発もスムーズに進みませんでした。

開発チームとクライアントの間にシステムコンサルタントが入ってきたために、確認漏れや認識合わせが難しくなってしまったのです。開発チームとクライアントが直接やり取りしていれば発生しなかったトラブルも少なくありませんでした。

＜プロジェクトの雰囲気＞
こちらのプロジェクトは設計段階からメンバー間で「ヤバいことになる」という意識があり、最初から少しピリピリしたものになっていました。私は新人だったのでその「ヤバさ」を理解することができなかったのですが、雰囲気はヒシヒシと感じました。

プロジェクトが進行するにつれ、開発メンバーと管理者（部長＆PM＆PL）が対立することが増えていきました。管理者には管理者の事情もあるのはわかりますが、それをうまくメンバーに伝えられないとこういった対立が起こります。

社内では常に遅くまでフロアの電気が消えないことから私たちの部署は「不夜城」と呼ばれるようになりました。実際、毎日誰かしら徹夜をしていましたし、土日も誰かしら出勤していました。

途中からは焦りもなくなり、淡々とやるべきことをこなすだけになっていったのを覚えています。本当に朝から晩までプログラムを組んでいました。

デスマーチでは人間の心理状態はこうなる！

私の経験では、デスマーチになると人間の心理状態は以下のようになります。

焦り
開発スケジュールから遅れないようにしたいが、積み上げられたタスクはそれを許さない。また、状況によっては複数タスクが同時並行する場合もあり、物理的に達成不可能なものになっている。

混乱
プロジェクトマネージャーやリーダーはプロジェクトの遅延理由を偶発的なトラブルや人的ミスに求めようとする。しかし、開発メンバーはもっと根本的な理由（無茶な納期や人員不足）にあると考える。そのため、プロジェクト内の意識共有が進まず、混乱に陥る。

葛藤
多くのメンバーが現状のままではまずいと考えつつも、何も手を打てない状態。第三者から見れば「一度立ち止まって方向転換をすればよいのでは？」と考えるが、当事者からすると、締め切り（納期）が迫っている（むしろ遅れている）状況で開発をストップして立ち止まるなどということができるはずもない。

また、方向転換をするというのは、これまで積み上げてきたものを一部（下手したらすべて）放棄することになる。よほど強いリーダーシップを持った管理者が決断しないことには、葛藤しながら作業することになる。

諦め
プロジェクトメンバーは管理者も含め、頑張っただけでは状況を改善することができないとわかっている。そして、システム開発ではデスマーチは起こりえるもので、このプロジェクトもその1つに過ぎないという諦めの念が出てくる。そのため、現状を改善するという考えはなくなり、目の前の仕事をこなしていくことしかできなくなる。

怒り
プロジェクトの遅延理由を他者に求めようとする。「あの人が意味わからないことをいうから」「あの人のプログラムはいつも爆弾（バグ）が仕込まれている」など、表面的な理由だけを見つけて攻撃対象にする。次第にプロジェクト内で派閥のようなものができあがる。

私の場合はほかにもこのような状態になりました。

夢でも仕事をしている

ずっと仕事をしていると、疲れ切っているのに寝ていても頭が半覚醒状態なので夢を見ます。そして、恐ろしいことに夢の中でも仕事をしているのです。「あのモジュールのロジックは不十分だから見直そう」「あそこのバグの原因はどこだろう」なんてことを夢の中でもしているので、まったく休んだ気がしません。

時間に対する感覚がルーズになる

デスマーチが続いてくると、残業が当たり前になります。こうなると、定時になっても「あと5、6時間はある」「最悪徹夜すればいい」などという時間感覚になってきます。そして、スケジュールの帳尻を合わせるために土日も稼働時間として計算するようになってきます。中には「定時になると調子が出てくる」みたいなことを言い出す人がいる始末です。このような状況で効率の良い仕事ができるはずがありません。

お金よりも時間が欲しくなる

まともな会社であれば、残業をすれば残業代が出ます。私の場合、残業時間が毎月100時間を超えている状況でしたので、給料は通常の倍以上になっていました。おそらく管理職並の金額をいただいていましたが、仕事をして帰って寝るだけの生活でしたので、まったく使う暇もありませんでした。

次第に給料はいらないから休ませてほしい。辞めたい、何も考えずに寝たい。と考えるようになりました。

デスマーチを経験した感想

私はデスマーチを体験したことでエンジニアとして強くなりました。なにしろ、新人で経験したプロジェクトが後にも先にも最悪のデスマーチでしたので、どのプロジェクトに入っても動じることがなくなりました。

最悪のプロジェクトを乗り越えたことが自信となったのでしょう。「あのプロジェクトに比べればマシだな」と思えば、どんなプロジェクトでも怖くありません。自分にできることを全力で取り組めば良いだけなのです。

ただし、デスマーチを経験することがすべてのエンジニアにとって必要か、といわれればそうは思いません。むしろ、可能であれば回避したほうが良いでしょう。デスマーチというのは会社の経営からすれば「失敗プロジェクト」です。よくてプラマイゼロ、ほとんどの場合は赤字でしょう。

つまり、デスマーチは成功体験でもなんでもなく、ただの敗戦処理でしかありません。エンジニアとして成長するには成功体験の方が何倍もプラスになります。

デスマーチを回避するには？

デスマーチはなるべく回避するに限ります。回避するためにはデスマーチがあまりない会社に就職することをおすすめします。なぜかというと、デスマーチは会社の体質で起こっている要素が強いからです。

デスマーチは会社の体質！

デスマーチはプロジェクトメンバーの能力次第で起こると考える人もいますが、私はそうは考えません。デスマーチになってしまうメンバーを選んでいるのは会社です。デスマーチになる納期の仕事を受けているのも会社、デスマーチになる予算しか組めないのも会社なのです。結局、デスマーチは起こるべくして起こっているのです。

たとえば、社長が営業に「なんでもいいから仕事を取ってこい！」というノルマを出すとしましょう。この場合、営業は納期も単価も度外視で仕事を取ってくる確率が上がるでしょう。そうなれば、短納期の低予算のプロジェクトができあがります。デスマーチの条件は揃っていますね。

そのほか、プロジェクトが多すぎて常に人的リソースがカツカツの会社があります。メンバーがしっかりしているプロジェクトは良いですが、その場しのぎでメンバーを集めたプロジェクトは上手く進行できずにデスマーチ化する確率が上がります。

このように、デスマーチになりやすい条件は会社が潜在的に孕んでいるものです。もし、自分が希望する会社があれば、現役の社員に聞いてみるのが一番でしょう。「デスマーチはあるのか」「デスマーチになる原因はなんなのか」ということを聞けば、その会社が持つデスマーチ要因が見えてくるでしょう。

ここで気になるのはIT業界すべてが過酷なのか？ということです。

近年のIT業界の残業状況

以下の表は、dodaの実地調査による業界、職種ごとの残業時間を表したものです。その中でもとくにエンジニアに関する職種を黄色で塗ってみました。

参考：doda

この表によると、ゲームクリエイターとITコンサルタントはそのほかの職種と比べて残業が多いようです。

この手の調査はアンケート対象によって数値が実態と乖離していることが多いのですが、実態をよく表していると思います。

とはいえ、これも会社によって大きく変わることは間違いありません。職種だけを見て選ぶのではなく、会社の実態をチェックすることは必須と覚えてください。

エンジニアの就労環境は変わってきた？

dodaが3,000人のビジネスパーソンに対して行った、「この1年で残業は増えたのか、減ったのか。その要因はどこにあるのか」という調査によれば、全体の26.3％が「減った」と回答していることがわかりました。これには会社の制度変更が大きく関わっているそうです。

参照：doda

以下の表はどの業界で残業が減ったのかを表したものです。IT・通信が2位に来ていますね。近年では「ライフワークバランス」という言葉がよく聞かれるようになり、個人としての生活の質の向上が、結果として仕事の質も向上させるともいわれています。SEの現場でも36協定、残業規制という言葉がよく聞かれるようになってきましたし、確実にIT業界にも残業を減らすという流れは来ていると思います。

参照：doda

デスマーチの少ない職種ベスト3

・社内SE
社内SEはいわゆる一般企業のシステム情報部門のSEです。ある程度の規模の会社だと、業務の効率化のためにシステム情報部門が設置されます。そこで働くSEは一般的なSEと違い、デスマーチが発生することはほとんどありません。

なぜかというと、社内SEはクライアントがいないため納期というものがそこまで厳格ではありません。もちろん、プロジェクトのスケジュールは遵守しますが、無理のないスケジュールで進められますし、遅延した分を無理して取り戻すこともありません。

そのため、比較的余裕のある働き方ができる職種として人気です。

・外資系SIer
外資系は日系企業と違い、経過よりも結果を重視する傾向が強いです。そのため、効率的な仕事を何よりも評価します。定時上がりで成果を出す社員が「有能」とされているため、誰もが定時までに上がろうとしますし、その分、定時で上がれば給料もインセンティブがつくようになっています。

・ユーザー系SIer
ユーザー系SIerは、一般企業の情報システム部門が独立してシステム開発を行っている企業です。仕事は親会社からの依頼がメインですので、無茶な要求をされることも少なくデスマーチになる確率も少ないでしょう。ただし、一部では他社からシステム開発を受注することもあるので、そういう場合にはデスマーチになる可能性があります。

法改正による労働環境の変化にも期待

最近では労働基準法も整理されてきて、残業に対する規制もしっかりしてきました。2019年（平成31年度）からは月45時間・年360時間の残業を上限とし、それを超えて叩かせた場合、雇用主は法的に罰せられるようになりました。

詳しくはこちらを参照してください。

労働時間法制の見直しについて（労働基準法、労働安全衛生法、労働時間等設定改善法の改正） – 厚生労働省

労働時間等の設定の改善

労働時間等の設定の改善について紹介しています。

www.mhlw.go.jp

SE＝過酷というイメージが定着していますが、近年ではその働き方も見直しが進んでおり、かならずしもキツい職業ではなくなりつつあります。

私のデスマーチ体験記をお読みになって嫌なイメージを持たれた方もいるかと思いますが、しっかりした会社を選ぶことがデスマーチを回避し、豊かな生活を送るための第一歩です。会社を選ぶ際は事前リサーチを入念に行ってくださいね。