【ボンブの戯言】ITエンジニアが徹夜してでも間に合わせる理由

ボンブの戯言9回目です。

タイトルでは徹夜と記載しましたが、ITエンジニアは「徹夜」「残業」「休日出勤」など、ありとあらゆる手段を使って仕事を完遂します。

最近、炎上一歩手間に足を突っ込んでしまい、家族の時間も自分の時間も大いに犠牲にしている私です。若かりし頃は徹夜上等の生活でしたが、過去と現在を振り返り「はて?なんでこんなに頑張っているんだろうか?」と思ったので、自分なりに「ITエンジニアが徹夜してでも仕事を完遂を目指してしまう理由」についての戯言です。

 

ITエンジニアの労働時間の現実

私だけがこんなに徹夜や残業をしまくっているはずがありません。周りのエンジニアを見ても長時間労働をしている人は多くいます。

ということで一般的な資料である下記を見つけました。

情報労連 「ITエンジニアの労働実態調査」 からみるITエンジニアの労働と課題

読んでいて、びっくりしてしまったのが、ITエンジニアが多く所属するであろう「情報サービス産業」の年間労働時間は、2017年以降一般労働者(事業所規模5人以上)よりも短く、特段長いとも言えないというので驚きです。

しかし、下記のようにも述べられておりITエンジニアが長時間労働の職業に該当するという認識は間違っていないようです。

(2) 長時間労働の偏在

ただし長時間労働をしているITエンジニアは多くの企業にみられる。2018年調査では、企業内のITエンジニアのなかでもっとも長かった人の月時間外労働時間をたずねている。もっとも長かった人の時間外労働時間が36協定の上限時間(月45時間)の範囲に収まる「45時間以下」(9.5%)という企業は1割に過ぎない。

 

約束された納期の日

そもそも、「仕事を間に合わせる」という定義からはじめましょう。仕事の期限もお客様やビジネスパートナー、社内向けなど色々ありますが、ITエンジニアが一番気にするのが「納期」の存在です。

納期は、商品などを納入する時期・期日のことです。ITのプロジェクトも数か月から数年単位など期間の長さは様々ですが、プロジェクト開始時に納期を決定しておきます。「システムを〇〇月××日に本番稼働する日」と考えればわかりやすいかもしれません。いうなればプロジェクトのデッドラインです。「納期」は神のような存在で絶対的な力があります。デッドラインなので死守しなければいけない最終防衛ラインになります。

私たちITエンジニアは、「納期に間に合わせる」ために日々の仕事で残業をしたり、徹夜をしてしまうのです。

納期以外の期限としてマイルストーンがあります。マイルストーンは、納期までに各種行っていなければいけない中間の目標地点もしくは節目のようなものです。マイルストーンも死守しなければいけないため、残業・徹夜の要因にはなりますが納期までに挽回できる場合もあります。

 

なぜ間に合わせてしまうのか

残業や徹夜をする理由が「納期に間に合わない」なら、そもそも納期を変えてしまえばいいのです。一か月後にできないのであれば二か月後にしてしまえばいいのです。そうすれば過度な残業や徹夜をせずに人間らしい生活を送りながら幸せな生活を送れることでしょう。

しかし、「納期を変更する(延ばす)」ことが可能であったとしても、その弊害は凄まじいものです。納期を変更することにより、多大なデメリットもあるためITエンジニアは、必死に納期(デッドライン)を守り仕事を間に合わせてしまうのです。

 

納期を変更(延ばす)する理想と現実

理想の場合です。あなた1人とお客様1人もしくはプロジェクトに関する人たちが少数の場合です。

あなた「納期に間に合わないから許してね」

お客様「しゃなーないな!納期を延ばして対応しようぜ!」

優しい世界です。幸せな日常風景のようにも見受けられてしまいます。しかし、現実はそんな甘くはないのです・・・・。

 

 

むかしむかしであれば理想の世界も望める場合がありました。しかし、現代ではシステムが大規模化・複雑化・高度化し少人数プロジェクトは少なくなっています。複数社で連携し、1社でも数名~数十名の関係者がいるプロジェクトも珍しいことではありません。

そんな環境の中で、あなたの担う部分が間に合わないとなると、その影響は波紋のように各所に広がり、怒りを買ってしまいます。下手をすると自身の会社の上司・同僚の怒りの矛先となってしまうのです。

また、直接的な叱咤などがなかったとしても、よほどの理由がない限り自社の技術不足・管理能力に疑問符を付けられ信頼が下がってしまうと今後の案件受注にも影響してしまいます。

 

案件並行の地獄

よほど大規模でもない限り、1案件に専属して張り付くエンジニアは少ないのではないでしょうか?上図のように、プロジェクトの開始と納期を計算しつつ2案件~3案件ほどを並行して対応することが多いと思います。

これは、予定通り納期に対して終わった場合のスケジュールですね。

 

もし、納期を延ばすのに寛容な世界だったとして、あれも終わらないこれも終わらないで各プロジェクトの納期がずれると上図のように並行する案件がどんどん増えていきます。

案件毎にお客様は異なるので、どれだけ並行しようとお客様には関係ありません。しかし、エンジニア本人からすると並行案件が多くなるということは地獄へ突き進んでいることを意味します。1日という限られた時間の中で、並行する数には限度があるのです。

そのため、将来の自分が苦しまないように、納期に間に合わせて後々の案件が始まった後も苦しまないように、「今」がんばって必死に終わらせようとします。

 

検収と評価

納期を切っても切り離せない重要なことが「検収」です。あまり聞きなれない人もいるかもしれませんが、weblioでは下記のように説明されています。

weblio辞書

検収とは、商取引において、納品された品物が発注した通りの数量あるいは仕様で間違いないことを確かめ、その上で品物を受け取ることである。

簡単に言うと以下のようなやり取りになります。

あなた「納期を守ってシステム納品したよ!契約・設計内容通り(お客様の要望通り)に動いてるよね?」

お客様「うんうん、確認したよ。ちゃんと要望通りに動いてるよ。」

あなた「それじゃ、検収あげるね。」

検収の仕方は特段定めがあるわけではありませんが、検収書にお客様のサインや押印をいただくパターンが多いのではないでしょうか。

ここで重要なのは検収があがることにより、お客様に請求が行えるということです。特に重要なのは、検収をあげることによって、あなたの会社の売上に計上できる点です。

会社は売上計画などを立てています。会社の売上計画には、部署単位や課単位でも設定されるでしょう。検収が遅れる(納期をずらす)ということは予定していた売上が翌月以降にずれてしまい予定の売上計画からずれてしまいます。つまり目標未達になってしまうのです。そんのため月末や特に決算期末などには、検収をあげることにみんな躍起になります。

個人のあなたには影響ないと思いますか?自分の部署が目標に達成できていないことは、お給与の評価項目としても含まれます。

あなたが原因で、目標未達になってしまったとなっては、あなた自身の評価にも直結してしまうのです。

 

会社が潰れる

検収に関連することです。検収があがらないということは、お客様に請求が行えない=会社にお金が入ってこないということです。

内部保留やその他資産が潤沢な大きな会社であれば、多少の入金なし状態でも問題ないでしょう。しかし、自転車操業状態の中小企業規模では、納期がずれる→請求できない→会社運営のお金が不足することによって、倒産に追い込まれるケースもあります。

資金不足の倒産ですから、あなたのお給与も支払われない可能性が高いです。

 

IT業界の悪しき風習

これは個人的な見解ですが、日本独自の2つの悪しき風旧も関係していると感じてします。

1つ目として、SIerを筆頭とするお客様のシステムを外注する文化および多重請負の業界構造です。日本でITのシステムを導入するとなると、SIerなどのが先頭にたち、その配下に複数の会社が参加し、さらにその下に別の会社が参加しという多重請負が多くみられます。

この多重請負により、ステークホルダーが爆発的に増えてしまいます。納期などの何かしらの変更があった場合に影響(主にスケジュール調整とお金に関すること)が大きなものになってしまっているため、「変更」という事象に対して、フットワーク軽く対応できないのです。

SIer自体を否定しているわけではありません。SIer存在のメリットもお客様視点もしくはエンジニア視点からも多くあることは承知していますが、納期(スケジュール)と多数の会社が関与することによる調整の複雑化の観点から悪しき風習として取り上げました。

 

2つ目として、頑張って終わらせることへの美徳感と実績です。IT業界だけではありませんが、日本の国民性として「約束を守る」「頑張って終わらせる」点において、潜在的に美意識を感じるのではないでしょうか。そんな勤勉な国民性もあり、IT業界は古くからどのような困難な問題も、残業・徹夜など頑張り続け終わらせる文化があるように考えています。元々コンピュータが好きなギークな業界だったこともあり、当時はそれでも楽しい部分もありましたが、現代は多種多様な人はIT業界で働くようになり、即していないと感じるのです。

「納期」に対して頑張っておらせるというのは日本だけではありません。「Apple」「Intel」や「UNIX」など誕生からその歴史の遷移を見ていると、期限に対して頑張って終わらせたお話は海外でもたくさんあります。しかし、それと比較しても日本の「頑張る」は少し異質に感じるのです。

 

残業規制のジレンマ

近年は「働き方改革」などにより、残業時間の上限規制がどんどん強化されホワイト化していると聞くIT業界ですが、いいことばかりでしょうか。

もちろん、残業規制により良い方向に向かっているとは感じます。しかし、納期に間に合わせなければならないことを考えると、短期間の残業時間の大幅な増加、徹夜してでも対応しなければいけないパターンは依然として存在します。

そのような関係もあり、短時間で最高の効率で成果を出さなければい成果主義が望まれる世の中になってきてしまいました。

私のような、頭の回転もおそく覚えることも考えることも時間を要する人種にとっては、非常に苦しい時代になってきたなと思うばかりです。

 

さいごに

私が仕事をする上で、一番気になるのは納期と予算です。IT技術を学べるとか成長できるなどは二の次三の次です。お客様の予算と決まった納期の中で、確実に終わらせることを第一に考えます。これはお客様を大事にしたいというより、怒られなくないというネガティブな考え方からですが・・・・。

そして、仕事の中で一番苦しむのもやはり納期です。潤沢な日数があればよいのですが、そんな仕事は稀で、普通以下のスケジュールが多いように感じます。その中で予期せぬトラブルや不具合が発生すると、たちまち残業&休日出勤&徹夜になってしまいます。

現在の私が、どんなに苦しい状況でも避けているのが「徹夜」です。若いころは3徹しても1日休めば回復していましたが、年齢のせいか1日徹夜しても、数日ダメージが残るうえに頭の回転が理解度が急激に落ちてしまうため、避けるようになりました。

といいつつ、先日大きな問題があり、徹夜が連チャンであり本記事の執筆にいたりました。

これは、すべてのITエンジニアに、徹夜などない楽しいエンジニアワークが送れるIT業界になることを祈っております。

関連記事

  1. 【ボンブの戯言】サーバーって何なの(オンプレに限る)

  2. Dell 14 ポータブル モニター – P1424Hを貰ったので、忖度せずThinkV…

  3. 【ボンブの戯言】フリーランスの実態調査をITエンジニアフリーランスの視点から見てみる

  4. 【ボンブの戯言】ITエンジニアは、なぜうつ病になるのか

  5. 【ボンブの戯言】はじめました。

  6. 【ボンブの戯言】フリーランスが払う税金など6選!私たちはこんなに支払っている!

  7. 【ボンブの戯言】フリーランスのメリットを全否定してみた

  8. 【ボンブの戯言】ITエンジニアがフリーランスになる理由

  9. 【ボンブの戯言】ITエンジニアがフリーランスになるときに考える・準備すること

コメント

    • ナマズ
    • 2022年 5月 17日 11:30pm

    ITは人類には早すぎた

    • 匿名
    • 2022年 7月 23日 7:57pm

    わかりやすくて助かる

    • zawaha_
    • 2023年 7月 26日 9:58pm

    SIer なら、納期は厳守だし、プライム案件だったとしても、やはり信頼を得る必要がありますよね。結果的にそんなこんなで、死に物狂いでシステムを構築して納品するのが慣習でした。
    クラウド化やローコードなど、インフラやソフトウェアのセットアップなどの部分がだいぶ簡略化されたと思います。しかしながら、徹夜してでも、36協定抵触してでも、やんなきゃいけないときがあるんですよね。
    人がいても早く開発できるわけではないので、お客様とちゃんと握ることが求められるように思います。

  1. この記事へのトラックバックはありません。

最近の人気記事

おすすめ記事

新着記事

  1. 閉鎖のお知らせ
  2. SES社長だけど質問ある?
  3. windowsにAI搭載するとか言ってるけどさぁ
  4. 新卒エンジニア僕、資格勉強する気が起きない
  5. 文系学部卒一般企業志望の君の進路はここから選んでもらうぞ!→ 営業・販売・未経験…

ボンブの戯言

  1. 【ボンブの戯言】フリーランスのメリットを全否定してみた
  2. 【ボンブの戯言】はじめました。
  3. 【ボンブの戯言】サーバーって何なの(オンプレに限る)
  4. 【ボンブの戯言】ITエンジニアは、なぜうつ病になるのか
  5. 【ボンブの戯言】ITエンジニアがフリーランスになるときに考える・準備すること
PAGE TOP