こんなこと聞いたことありませんか?
こんな話を聞いて、
「エンジニアはしんどすぎて自分には無理かも」
と考えてしまっていないでしょうか。
筆者自身もIT企業に就職する前は同じような考えを持っていました。
「残業ばっかりなら、どのみち仕事は続かない。IT企業への就職はやめたほうがいいかな」
「ワーカーホリックでも、仕事を楽しめるタイプでもない。働き詰めになるのなんて嫌だ」
しかし、実際働き始めるとイメージしていたより残業は少なく、夜間作業とか深夜残業は5年程エンジニアとして働いていますがほとんどありませんでした。
(周りでも夜間作業や深夜残業をする人は少なかったです)
結局のところイメージではなく、実際どれくらい残業があるのかを知ることが重要です。
この記事では次のことが分かります。
- エンジニアの残業時間
- 残業時間が昔よりも減った理由
- 残業に対する2つの考え方
この記事を読むとあなたの「残業」に対する不安が小さくなります。
エンジニアの残業時間

残業は、職種ごと、企業ごと、プロジェクトごとで変わってきます。
また、残業の発生タイミングは
・納期前やリリース前
・障害が起きたとき
・バグが見つかったとき
・仕様が急に変更になったとき
など、プロジェクトの状況や時期によっても変わります。
残業時間の実態
時期や状況によって変わる残業ですが、全体的な月々の残業時間が政府の調査で分かっています。

参考:賃金構造基本統計調査 (2019)
システム・エンジニア全体の残業時間は 14時間/月です。
思っていたよりも少ないと思いませんか?
全国平均なので人によっては、ほぼ毎日定時帰りや毎日数時間の残業が発生している方もいるかもしれません。
ですが、全国平均から見る限り多くの場合は週に3~4時間ほどの残業があるだけです。
残業が発生するタイミング

残業が発生するタイミングはだいたい決まっています。
まずはどんなタイミングで残業が発生するかみていきましょう。
納期前・リリース前
エンジニアの仕事には、保守でない限り必ず『納期』『リリース(システムスタート)』が存在します。
つまり、エンジニアの仕事には明確な期限があるということです。
期限までにプログラムやシステムが完成していない場合、残業が発生します。
そもそもの期間に対して、求められているもののレベルが高かったり、予期せぬバグが見つかり修正を余儀なくされたりと様々な理由で期限ぎりぎりになってしまうケースもあります。
期限に間に合わせるために、連日の残業が必要となります。
バグが見つかった時

バグが見つかった場合、それの原因を突き止め、対応する必要があります。
なぜなら、そのバグがお客様の業務に影響を及ぼす場合があるからです。
また、お客様にバグが存在する欠陥品を渡すわけにはいきません。
バグの解消は、すぐにできるものもありますが、何時間かけても原因が分からず対処法を導き出せない場合もあります。
バグの調査、改修が発生するため、残業が必要になります。
仕様変更が発生した時

仕様変更は発生しない方がいいのですが、お客様の要望が変わったり、追加要望が発生したりする場合があります。
仕様変更が発生した場合、納期の調整が入り費用も追加してくれたらいいのですが、そこまで理解のあるお客様は少ないです。
こうなるとエンジニアがそのしわ寄せを受け、増えた作業量を補わなければなりません。
このように、お客様の仕様変更や追加要望により作業量が増加し残業が発生してしまうのです。
なぜエンジニアは「激務」というイメージなのか

それではなぜ「エンジニアは激務」と言われているのでしょうか。
理由は3つあります。
- エンジニアの仕事は、夜間作業が発生する
- デスマーチが発生する
- 10年前は確かに残業だらけだった
エンジニアの仕事は、夜間作業が発生する
エンジニアの仕事は、夜間に作業が発生するケースがあります。
例えば、日中はシステムを誰かが使っているため、夜間にしか作業できない場合です。
この場合、ユーザーに影響がでないように、夜の間にシステムリリースや保守対応を行う必要があります。
また、システムに問題が発生した場合は早急な対応が求められます。
最近はリモートでの対応も増えてきましたが、夜間や休日に関係なく現場へ出向かなくてはなりません。
デスマーチが発生する

IT業界で使われる「デスマーチ」という言葉をご存じでしょうか?
デスマーチ
「死の行進」という意味の英語表現で、IT業界では過酷な労働環境や極端な過重労働を課されるシステム開発プロジェクトの現場を表す俗語として用いられる。
引用:IT用語辞典 e-Words
ネットやSNSでもたまに流れている言葉です。
納期前にも関わらず、システムが完成していないため、時間外労働・休日出勤をすることでどうにか対応し、心身ともに疲弊していく状況のことをデスマーチと呼んでいます。
IT業界ではしばしば見かける状況ですが、
本来、人的資源や時間が適切に確保できている場合は、デスマーチは起きません。

例えば、元々社員が少なく、会社としての力も低い場合、費用が抑えられ納期が短いような条件が悪い契約を結ぶことがあります。
元々人員も少ないとどんな案件でも、少人数でプロジェクトに向き合わなければなりません。
結果的に契約を満たすためデスマーチが発生します。
一方で、社員を多く抱えている場合は、一つのプロジェクトに適正な人数を割り当てることができます。
また、納期に関しても大きな会社だと調整しやすいです。
もしも、デスマーチに陥りそうなプロジェクトが発生した場合、他から人員を追加できデスマーチを回避することができます。
つまり、デスマーチは勤める企業によって発生頻度は変わってくるということです。
健全なプロジェクトを運営できる企業であれば、デスマーチは避けられます。
10年前は確かに残業だらけだった

IT業界はブラック、激務
このように言われるのは、なにも今に始まったことではありません。
昔からずっと言われています。
私もよく先輩達から聞かされました。
10年前だったら、定時に帰るなんてありえなかった。(空が明るい時間に帰宅できるなんてびっくりだ)
10年前だったら、深夜まで残業して、数時間後に出勤していた。(寝に帰るだけの毎日だった)
10年前だったら、残業代だけで大きな金額を稼いでた。
このように昔と比べて今は…という話がありました。
昔自慢のような言い方ですが、そんな毎日私だったら絶対嫌だと思ったくらいです。
先輩方がおっしゃる通り、10数年前は本当にブラックで残業時間も結構多かったみたいです。
法律も罰則がなかったので、サービス残業が当たり前にありました。
ですが、現在は働き方改革とか、社会の風潮が残業は悪みたいな認識になっているのでだいぶ働きやすくなりました。
今では、定時退社日とか、休日出勤には上司の許可が必要とかで時間外労働をしにくい環境を作っている企業もあるくらいです。
転職する際に、平均残業時間やデスマーチが起こった際の企業としての対応方法を含めた情報収集を行っておくと過酷な労働環境を避けることができます。
残業時間が減った理由

①36協定
36(サブロク)協定とは、労働基準法36条にもとづく労使協定のこと
この協定は、労働基準法で定められている「1日8時間、1週40時間以内」を超えて社員に残業させる場合に取り交わす協定です。
36協定では、時間外労働の上限は「月45時間・年360時間」と定めています。
2019年4月から36協定が法律に定められ、罰則がつきました。
2019年4月以前は、厚生労働省による目安で強制力はありませんでした。
36協定が目安から罰則がつくようになり、ここ数年で残業が少なくなっています。
ほとんどの場合は、断りにくいのでそのままサインしてしまいます。
(なかなか入社時に残業はしません!なんて言えないですよね)
上限自体もその上限高すぎ、とは個人的に思いますが、罰則がついただけでも大きな進歩だと言えます。
②働き方改革
ご存じの方も多いと思いますが、政府が一億総活躍社会の実現に向けて「働き方改革」を推進しています。
働き方改革では、
- 労働時間制法の見直し
- 雇用形態に関わらない公正な待遇の確保
をめざしています。
労働基準法の見直し
①で解説した36協定のように残業時間を規制したり、年間5日の有給休暇をとることを定めるなど、ワーク・ライフ・バランスを実現しようとする動きがあります。
雇用形態に関わらない公正な待遇の確保
同一企業内における正社員と非正規社員の待遇の差をなくす動きがあります。
参考:厚生労働省 働き方改革 ~ 一億総活躍社会の実現に向けて ~
③社会の風潮

①、②の動きも影響していますが、残業への考え方が少しずつ変わってきています。
どちらかというと、長時間労働を抑制して効率的に仕事をしようとする動きです。
社会の風潮に伴い、企業の在り方も変わってきています。
人材不足が問題となっている昨今、残業が多く働きにくい企業は敬遠されます。
多くの優秀な人材が欲しいと考えるのなら、社員が仕事しやすく魅力的な企業である必要があります。
その為、企業としても残業を減らし、計画的・効率的に働く考えが広まってきています。
エンジニアの残業に対する2つの考え方

- エンジニアに残業はつきもの。月10時間は想定しておく
- デスマーチを避ける環境づくり
エンジニアに残業はつきもの。月10時間は想定しておく
エンジニアは、ほぼ確実に残業が発生します。
あまり残業が発生しない業界もありますが、そういうところは少ないので
確実にあると覚悟しておいた方がいいでしょう。
最初から週3~4時間は残業があると思っておくと、これより多くなっても少なくなっても気持ち的に対応しやすくなります。
時には10時間を超えることもありますが、最初の段階で残業が発生することがある程度分かっているので対応しやすいです。
デスマーチを避ける環境づくり

一番大事なポイントは、デスマーチが多発する企業やプロジェクトへ参加しないことです。
あなたがデスマーチを避けたいならこの点は絶対に外せません。
特に入社して数年はプロジェクト管理についてはノータッチになるので自分の力ではなにもできないからです。
これまでの経験上、就職するときに
「実際の残業時間の平均はいくらか」
「年間の残業時間はいくらか」
「納期ギリギリのプロジェクトに対する周囲の対応はどんなものか」
「入社3年以内の離職率はいくらくらいか」
「定時退社日はあるか」
このあたりを確認すれば多くの場合は避けることができます。
また、この辺りは転職エージェントを通して情報を集めることもできます。
経験を積みプロジェクトをマネジメントする側にたったら、見通しを持って仕事を行いましょう。
いつまでに完了していなければならないのか。
遅れている作業はないか。(遅れていれば、他から人員を追加して対応できないか、効率的に作業をすすめられないか)
お客様都合の場合、納期を伸ばしてもらうのも手です。
このように出来るだけデスマーチになる前に対応する必要があります。
まとめ
システム・エンジニア全体の残業時間は 14時間/月です。
世間で言われるほど激務という残業時間ではありません。
残業が発生するタイミングは
- 納期前やリリース前
- 障害が起きたとき
- バグが見つかったとき
- 仕様が急に変更になったとき
どういう時に残業が発生するかわかっていると、計画の変更や事前の作業見直しなどで、
残業自体の発生を抑えることができます。
残業時間が減った理由 は
- 36協定
- 働き方改革
- 社会の風潮
の3つです。残業には上限があり超えた時の罰則があります。
エンジニアになるのであれば、残業に対する2つの考えを心得ておきましょう。
- エンジニアに残業はつきもの。月10時間は想定しておく
- デスマーチを避ける環境づくり
エンジニアと残業は切り離せないものです。
しかし実情を知り、事前にデスマーチを避けたり10時間くらいは残業があるとわかっていると働きやすくなります。
エンジニア転職を目指しているなら、しっかり業界研究や転職活動を行っていきましょう。
コメント