プログラマーと聞いてどんなイメージを持っていますか？
IT業界の「新3K（きつい、帰れない、給料が安い）」という言葉を聞いたことがある人は、プログラマーは寝る暇もないくらい忙しい、そんなイメージを持っている人もいるかもしれません。
ただ「働き方改革」により、昔よりあきらかに働きやすい環境に変わっています。
本記事では、IT業界で約20年間働いている管理人の経験から「プログラマーは本当に激務なのか？」というテーマについて記事にしています。
目次
プログラマーは忙しい？管理人の経験からわかること
昔は本当に激務だった
僕が新人のとき、一緒に仕事をしていた先輩が何日間も泊まり込みで仕事をしていたことがあり、それが原因で体調を崩したという話を聞いたことがあります。
ただ、その先輩は「今はそこまで働かされないから大丈夫だよ」と話してくれました。とても優しい先輩でしたが、体調を崩しているためよく会社を休んでおり、数年後に退職しました。
今はそこまで働かされないから大丈夫かな？と安心していた僕ですが、20代後半でついに炎上案件を経験します。
毎日終電まで働き、休日出勤は当たり前と完全に感覚がマヒしている現場でした。
この炎上案件の怖いところは「終電 + 休日出勤あり」という働き方が1年以上も続いたことです。22時くらいから打ち合わせを行うことも珍しくなく、多いときは残業時間が100時間を超えることも。
厚生労働省が定義している過労死ライン、このラインぎりぎりで働いていました。
- 発症前2か月間ないし6か月間にわたって1か月当たりの時間外労働が80時間を超えること
- 発症前1か月間に1か月当たりの時間外労働が100時間を超えること
これだけ忙しい現場です。体調を崩し休職した人、会社を辞めた人をたくさん見てきました。そして、現場の責任者だった課長が休職したときは驚きました。
本当にしんどかったです・・・。
「働き方改革」により働き方が大きく変わった
2019年4月1日に実施された「働き方改革」により、働き方が大きく見直されました。特に「36協定」が大きく変わりました。
36協定とは、会社が法定労働時間（1日8時間、週40時間）を超える時間外労働及び休日勤務などを命じる場合、労働組合や労働者の過半数代表者などと書面による協定を結び、労働基準監督署に届け出ることが義務付けられた「時間外・休日労働に関する協定届」のことです。
2019年4月1日に実施された「働き方改革」により、時間外労働の上限時間が定められました。この「36協定」の上限を超えて残業はできません。
「働き方改革」の前は特別条項に上限の設定がなかったため、事実上、無制限の残業が可能（6ヵ月間は上限時間なしでの就労が可能）になっていることが問題になっていました。
そのため、炎上している激務の現場にいくと、とにかく働かされることがありましたが、現在は「36協定」の上限があるため、健全な会社であれば「36協定」を超えてないように調整してくれます。
「36協定」は会社ごとに上限値が違います。自分の会社の「36協定」の上限値は把握しておきましょう。
ちなみに僕の会社は、通常は月45時間まで、特別条項で年に6回 月75時間まで残業が可能になっています。
「36協定」を知らない人もいるので、僕は部下に「36協定」を説明し、超えそうな場合は調整するので教えてくださいとお願いしています。
（基本、45時間を超えないようにお願いしています。）
ブラック企業に勤めている人はすぐ転職するべき
昔は「36協定」の特別条項に上限がなかったため、6ヵ月間は上限時間なしでの就労が可能でしたが、今は上限が設定されています。
そのため、健全な企業であれば「36協定」の上限を超えないように調整してくれます。超えそうになると、会社から「超えないよう気をつけてください。」と注意されるのが普通です。
しかし、なかには「残業をつけさせてくれない会社」「みなし残業制（固定残業代制）の範囲を大幅に超えて残業させられる会社」が存在します。ブラック企業と呼ばれる会社です。
IT業界は売り手市場であり、人手不足が続いています。（経済産業省のレポートによると、2030年までに最大で79万人のIT人材が不足する可能性があると記載されている）
そのため、転職しやすい時期です。もしブラック企業に勤めている人がいれば、今すぐ転職することをお勧めします。
プログラマーが忙しくなる理由
「36協定」に上限値が設定されたことで、昔より働きやすい環境になりましたが、プログラマーは残業が多いです。もちろん残業なしの現場もありますが、残業が当たり前になっている現場の方が多いように感じます。
「毎日必ず定時で帰る」、これは相当安定した現場 もしくは 残業させないという決まりがある現場くらいしか経験したことがありません。
プログラマーが忙しくなる理由には、特に次の2つが挙げられます。
- 納期に間に合わないので稼働を上げて対応する
- 本番リリース後の障害対応
納期に間に合わないので稼働を上げて対応する
IT業界はモノ作りの仕事です。作成するシステムには納期が決まっています。
この納期に間に合うようにシステム開発（要件定義・設計・開発・試験）を行う必要があります。
システム開発は次の流れで行います。
- 要件定義：お客様の要望を聞き「何をどうシステム化するのか」これを明確にする。
- 設計：要件定義の内容から設計書を作る。
- 開発：設計書を見ながらプログラミング言語を使いプログラムを作る。
- 試験：開発したプログラムが設計書のとおりに動作するか確認する。
システム開発を始める前にスケジュールを立てるのですが、予定通りに進むとは限りません。
スケジュールに遅れが発生すると、それをカバーするために増員したり、残業したりして対応します。
ではなぜ、スケジュールどおりに作業できないのか、それは主に次のようなことが原因です。
- もともとのスケジュールに無理があった（見積もりが適切ではなかった）
- 開発メンバーの実力不足
- レビューを疎かにしている
- 試験工程を甘く見ている
- 途中でお客様から仕様変更や機能追加を依頼されているにもかかわらず、スケジュールが変わっていない
もともとのスケジュールに無理がある場合は、忙しくなるのが目に見えています。見積段階で失敗しているのです。
「途中でお客様から仕様変更や機能追加を依頼されているにもかかわらず、スケジュールが変わっていない」、これも大問題です。スケジュールを作ったときになかった作業を追加で依頼されたのであれば、スケジュールを見直すべきです。
スケジュールの見直しが難しい場合は、追加で人を入れて対応できればよいですが、それも出来ない場合は、既存メンバーの稼働を上げて対応するしかありません。
そして、よくあるのが「開発メンバーの実力不足」「レビューを疎かにしている」「試験工程を甘く見ている」この3つです。
開発メンバーに数名の有識者（実力のあるエンジニア）がいないとかなり厳しいです。有識者であれば1週間で作れるものを、経験が少ないエンジニアの場合、2週間、最悪3週間かかることもあります。
昔、炎上している案件があり、その案件の助っ人として途中参加した経験があるのですが、その案件は「React」と「TypeScript」を使っていました。しかしその現場には「React」と「TypeScript」の経験者がいなかったのです。「そりゃ炎上する訳だ・・・」、完全に開発メンバーの実力不足が原因です。
またシステム開発にはレビューが必要です。「設計書レビュー」「コードレビュー」「試験書レビュー」と作ったものに問題がないか、有識者に確認してもらうことで、品質が上がります。このレビューを疎かにすると、あとで痛い目にあいます。（仕様漏れなどに気づけない）
そして、当たり前のことですが、作ったプログラムが設計書どおりに動作するか確認する試験、これをしっかりやることが大切です。
試験工程を甘く見ていると、レビュー同様、あとで痛い目にあいます。（お客様試験などで、バグが頻発する）
このようなことが原因で、スケジュールどおりに作業が進まないことがよくあります。
スケジュールどおりに作業が進まないと、それをカバーするために稼働を上げて対応する必要がでてきます。その結果、残業が多くなってしまうのです。
本番リリース後の障害対応
普段、仕事をしていると泊まり込みで仕事することはありません。
しかし、本番リリース後に大きなバグが発生し、すぐ対応しなければならない場合、最悪泊まり込みで対応することもあります。
例えば、お金に直結するシステムで、バグを直さないと大変なことになる、一般的に普及している大きなシステムで、バグを直さないと、会社の信頼性ダウンにつながるなど、システムが大きいほど、本番リリース後のバグは致命的です。
本番リリース後のバグはすぐ対応する必要があるため、どうしても高稼働になってしまいます。
本番リリース後に大きなバグが発生しないようにするためにも「レビューをしっかり実施する」「試験をしっかり実施する」ことが大切です。
またお客様との認識祖語がないように、ちょっとしたことでも仕様の確認はしっかり行うことが大切です。