IT業界のエンジニアに対して「華やかさ」や「格好良さ」をイメージする方が多い反面、「IT業界 ＝ 激務」というイメージを抱いている方も少なくありません。
では、実際にはIT業界のエンジニアたちは、毎月「どのくらいの残業」をして「どんな生活」を送っているのでしょうか？
今回は、ITエンジニアの「平均残業時間」と「良くないイメージ」の関係についてご紹介していきます。
激務ってホント？「エンジニアの仕事」の良くないイメージ
ITエンジニアの仕事について語る際、「夜遅くまで帰れない」「月に100時間以上の残業がある」「会社に泊まり込む」といった良くないイメージを挙げる方がいます。
私自身も仕事を聞かれた際に「IT業界で働いています」と言うと「激務なんでしょ？」と聞かれる事が多々あります。
しかし、全体から受ける印象として、IT業界の仕事時間について正確に把握している人は少なく、IT業界に対する「仕事の辛さ」や「良くないイメージ」が先行して定着してしまっている人が多いのではないでしょうか？
IT業界では、たしかに繁忙期や納期間近のプロジェクトの場合はそういった状況に陥るケースもありますが、実際には常にそういった状況が続く事は少なく、通常は安定した勤務時間で仕事を行える企業がほとんどです。
また、ハードワークなイメージを持たれがちなIT業界ですが、「繁忙期にかけて徐々に仕事が忙しくなる」という点では他業界の仕事と何ら変わりはありません。
IT業界の企業は「繁忙期に仕事が集中する可能性がある」ことを見越して、仕事の山場を越えた後にしっかりと休めるよう、充実した休暇制度を整えている企業も多く存在します。
このため、世間には「良くないイメージ」が先行していますが、実はイメージよりもずっと働きやすい環境が整っています。
ITエンジニアの「残業時間」と「勤務実態」について
IT業界の「良くないイメージ」が世間で共有されてしまっているということは、IT業界内にそういった一面が少なからず存在するのは確かです。
しかし、エンジニアの仕事に興味があるのに、イメージに踊らされて挑戦せずに諦めてしまうのは非常にもったいないことです。
まずはデータを調べてから総合的に判断をした方が、より正確にIT業界の実態を捉えることが出来ます。
それではここからは、実際のITエンジニアの「残業時間」がどの程度なのか、なぜ「良くないイメージ」が定着してしまったのかについて見ていくことにしましょう。
本当はどのくらい？エンジニアの「平均残業時間」
それでは、IT業界の「残業時間」がどの程度なのかを確認してみましょう。
求人情報・転職サイトDODAの「ITエンジニア」と「モノづくりエンジニア」を対象とした調査「エンジニアの転職白書／エンジニアの残業事情」によると、エンジニアの1か月あたりの残業時間は「20時間～40時間未満」が最多という結果が出ています。
また、このデータによると、全体から見て約70％のエンジニアが1月あたり「40時間未満」の残業時間でおさまっており、更にそのうち30％は「20時間未満」の残業時間であることが分かります。
この調査結果を見て、エンジニアの残業時間が意外に少ないと驚いた方も多いのではないでしょうか？
確かに10％程度は、80時間を超える残業をしているにエンジニアも存在していますが、このデータを確認する限り、「ITエンジニアの大部分は大きな残業も無く、安定した生活が出来ている」と言うことが出来そうです。
出典：求人情報・転職サイトDODA「エンジニアの転職白書／エンジニアの残業事情」
エンジニアの「平均残業時間」は「36協定」の基準時間に収まっている
ここまで記事を読んで「20時間～40時間未満でも、残業が多いのではないか？」と思う方や、「他業界の残業時間と比べてどうなのか？」と疑問に感じる方も居るかもしれません。
それでは、社会の労働基準と照らし合わせた場合には、エンジニアの「平均残業時間」が長いのか実際に確認してみましょう。
通常、企業内で長時間の残業が必要となった場合には、労働基準監督署に対して「時間外・休日労働に関する協定届」、通称で「36協定」と呼ばれる届け出を提出する必要があります。
この「36協定」の基準を見てみると、1か月の残業時間の上限時間は「40時間」と定められており、「40時間を超える長時間の残業」が発生する場合に届け出を提出するよう義務図けられています。
「36協定」の提出は、IT業界だけでなく他業界にも共通的に守っている労働基準です。
このことから考えても、ITエンジニアの平均残業時間は、他業界のサラリーマンやOLと比較して「大きく変わらない」ことが分かります。
「働き方改革」により、より働きやすい環境づくりが行われている
また、近年では企業の残業時間に関する考え方が見直されはじめ、「働き方改革」による残業時間の低減政策が積極的に行われるようになっています。
このような流れによって、労働環境や条件の改善が続いており、エンジニアにとって「より働きやすい職場環境」が整備されています。
このことから、ITエンジニアはイメージほどの激務になることはほとんどなく、通常時の勤務では、むしろ安心して快適に働ける職業であると言えます。
激務なイメージを持たれがちな「5つの要因」
ここまでの説明で、ITエンジニアの残業時間は他業界と比較して大きな差がないことが分かりました。
それではなぜ、「ITエンジニアは残業時間が長く多忙」というイメージが一般的に定着しているのでしょうか？
このIT業界の「良くないイメージ」は、IT業界の「独自の仕事の管理体制」や、「問題発生時の対応の行い方」などによって、繁忙期の残業時間や作業量が膨らむ可能性がある事が関係しています。
それではここからは、IT企業がハードワークなイメージを持たれてしまう「5つの要因」について解説していきましょう。
【要因①】「プロジェクト」単位での仕事管理
IT業界がハードワークなイメージを持たれる要因の1つ目として、「プロジェクト」と呼ばれる単位での仕事の管理方法と、問題発生時の対応の難しさが挙げられます。
IT業界では、顧客からの要望に万全に応えるためにオーダーメイドでシステムを一から作成することが少なくありません。
そのため、仕事を受注した場合にはそれぞれの顧客ごとに「プロジェクト」と呼ばれる単位で仕事を個別管理し、「プロジェクトチーム」と呼ばれる専属のチームメンバーを編成して作業の対応を行います。
ITエンジニアは自分が参加する「プロジェクト」が無事に終了するまでを1つの区切りとして対応を行うため、それぞれの「プロジェクト」が掲げる業務条件によって、作業の対応期間や各作業のボリュームが大幅に変わってきます。
通常は、顧客から仕事を請け負った時点で「余裕のあるスケジュールと作業計画の立案」「適切な人員の確保」「予想されるリスクの把握と対応コストの見積り」を行い、プロジェクトが安全に遂行できるように調整を行います。
この事前の調整作業が正確に行えていれば、大きな問題は起こらずに残業を行うこともなく仕事が行えます。
しかし、「どうしても3か月で稼働させてもらいたい」など、顧客の要望に特殊な条件があった場合には、万全な見通しを立てて作業を行う事が難しくなります。
プロジェクトによって残業が求められる要因は様々ですが、よくあるケースとしては「費用面の問題で低コストで要望を実現しなくてはならない場合」や「短納期でシステムの開発から導入までを行わなければならない場合」などが挙げられます。
こういった場合には、予算不足で通常よりも少ない人員で開発を行う必要が出てきたり、タイトなスケジュールで納品まで対応する必要があるため、「プロジェクト」が立ち上がった当初から1人あたりの負荷が大きく、残業で対応しなければならない状況に繋がりやすくなります。
【要因②】「納期は絶対厳守」な仕事スタイル
要因の2つ目として「納期は絶対厳守」な仕事スタイルがあります。
納期を守るのはどの業界でも同じだとは思いますが、顧客からお金を貰って仕事をしている以上、IT業界でも納期は絶対厳守です。
エンジニアが作り出すソフトウェアなどのシステムは、ハードウェアと違って実体がなく無形のものですが、IT業界も製造業と同様にシステムという「モノづくり」を行っている以上、要望に応じた納期内で製品の開発と納品を行います。
「納期厳守」と言われると当然のことのように思われがちですが、「プロジェクト」の条件によってはタイトなスケジュールで作業を行う必要があるため、一番最初に行われる要件定義やスケジュールの立案をいかに効率良く行えるかが重要なポイントとなってきます。
スケジュールに組込む「作業ボリュームの見積もりが甘かった」場合や、「顧客要望の変更」「認識間違いによる仕様変更」が発生した場合には、作業の進捗に大幅な遅れを発生させることになりますが、最初に宣言した「プロジェクト」の終了時期はよっぽどのことが無い限り変更できません。
このため、納期が間近となった進捗に大幅な遅れがある「プロジェクト」は、プロジェクトメンバーが過酷な残業を行ったり、大量の追加人員を投入してなんとか納期内に作業を終えるために尽力します。
あまりにも進捗が上手く進んでいない「プロジェクト」の場合は、急いで設計書とプログラムの修正をしたことでバグやデグレードが発生してしまったり、不眠不休で働くデスマーチと呼ばれる状況を引き起こすなど、悪循環が続いてしまう場合があり、エンジニアが激務となるイメージを作り上げる原因となっています。
【要因③】「出来る人」に仕事が集中する傾向がある
要因の3つ目として、エンジニアの仕事は「出来る人」に作業量が集中してしまうことが挙げられます。
「出来る人には仕事が集中する」というのはIT業界の仕事に限った話ではありませんが、ここで言う「出来る」というのは開発技術だけではなく、顧客先の「業務に関する知識の有識者」という意味も含んでいます。
ITエンジニアは「技術力が高ければ問題ないのでは？」と思う方も多いかもしれませんが、一つのシステムを作り上げる際には、顧客の要望に合わせたベストな仕様を見極めて開発を行う必要があります。
そういった状況で的確な判断を行うためには、高い技術力を持つだけでなく、顧客先の業務に精通したエンジニアの存在が必要不可欠です。
金融や製造、流通といった業界特有の業務知識は一朝一夕で養われるものではないため、特定の業務知識に長けた「有識者」は非常に貴重な人材です。
高い業務知識を持つ「有識者」は顧客の信頼を得やすいため多くの打合せに参加したり、仕様に関する重要な決定を下す状況では意見を求められる機会も必然的に多くなります。
そのため、繁忙期になればなるほど、替えの利かない「有識者」に仕事が集中する傾向があります。
このように「繁忙期こそ特定の個人に作業が集中してしまう」事態があることも、ハードワークなイメージを持たれてしまう一つの要因となっています。
【要因④】「元受け企業」から仕事を受注する、ピラミッド型の業界構造
要因の4つ目は、IT業界のピラミッド型の業界構造です。
IT業界の一部の業界は、大手のゼネコンに似た業界構造が存在する事から、「IT土方」や「ITゼネコン」と呼ばれることがあります。
この呼び名は、元受けとなる企業が顧客からの受注を取り、以降の作業は2次受けや3次受けの企業に依頼する、元受け企業を頂点とした「ピラミッド型の業界構造」が、ゼネコン(建設業)の業界構造と共通していることが由来です。
IT業界の場合では、NTTや富士通、日立などの大手グループが活躍している「情報処理業界 (SI業界) 」がその典型例となっています。
このタイプの業界構造では一般的に、親会社である「元受け企業」が顧客調整と作業スケジュールの管理、要件定義などの上流工程を担当します。
それ以降の下流工程の作業は、グループ内の子会社など2次受け、3次受けの企業に振分ける事で、作業ボリュームが大きい「大規模プロジェクト」への対応を行います。
通常、「プロジェクト」の進捗がスケジュール通りに進めば大きな問題は出てないはずです。
しかし、仕様変更やスケジュールに変更が発生した場合には、情報の伝達ミスや遅れによって組織間での認識違いが発生したり、一度完了した開発を再度やり直す必要が出てきたりと、2次受けや3次受けをしている下請け企業が上位の組織に振り回されてしまう結果となります。
このピラミッド型の業界構造では「大規模な仕事にも一丸となって対応出来る」のが特徴ですが、「プロジェクト」に参加する企業が増えるほどに情報が錯綜するリスクもあり、結果的に非常にタイトなスケジュールで作業をこなさなければならない状況に陥る事もあるのが特徴です。
■ピラミッド型の業界構造イメージ図
【要因⑤】夜間や休日などの「緊急対応」が必要なケースがある
要因の5つ目は、夜間や休日などの緊急対応が必要となる場合があることです。
ITエンジニアが請け負う仕事は開発作業だけではなく、顧客先のシステムやサーバーの保守作業をしたり、サポートデスクとして問題があった場合の対応を行う場合もあります。
サポートを行う範囲は、保守対象のシステムの種類や、取り交わしたサポート契約の内容によっても左右されますが、中には1年中稼働し続ける事が前提条件とされるような、重要な情報を扱うシステムも存在するため、夜間や休日でも緊急対応を行う必要があります。
こういった常時稼働が義務付けられているシステムの場合は、担当メンバーが交代制で対応を行う事が多く、担当者一人一人が十分な休息を取れるように配慮が行われています。
しかし、深夜や休みの日にも呼び出される可能性があり、いつ問題が発生するか分からない状況に置かれるという意味では、他業界の仕事と比べて非常に大きなプレッシャーが掛かってきます。
このような常に稼働しているシステムの保守を行うことも、IT業界が激務というイメージに繋がる要因の一つとなっています。
まとめ
今回は、ITエンジニアの「残業時間」と「良くないイメージ」についてご紹介してきました。
今回ご紹介した通り、世間では激務なイメージを持たれがちなIT企業は、実は通常時は残業を行う事も少なく、一般的にイメージされているほどの激務になることはほとんどありません。
一方で、仕事の繁忙期や緊急時には、担当する仕事によっては仕事量が集中してしまったり、長時間の労働を行うケースも少なからず出てきます。
ハードワークを気にしてエンジニアになるのを躊躇している人は、一度希望する転職先企業の「残業時間」の情報や、担当する業務内容はどんなものなのか調べてみるとよいでしょう。
