はじめに
本記事は、SE(システムエンジニア)と聞いて、
- なんでSEはいつも忙しく残業が多いの?
- SEになりたいけど、どういう理由でブラック化するのか知りたい
という方への解説記事です。
実際にSEの開発担当として働いた実体験に基づいた内容なので、SEについて興味ある方は読んでみてください!
(すべてのSEに当てはまることではないでご了承を、、、)
①トラブルが必ず発生する
どの開発プロジェクトでもトラブル防止策として、マニュアルの作成やレビュー方法の徹底がなされていますが、どうしても人為的ミスが起きてしまいます。
本来であれば、トラブルがどうしても起きてしまうことを踏まえスケジュールや納期が設定されるべきですが、
以下を理由にトラブル発生が加味されていないスケジュール設定になってしまうことが多いです。
クライアントへの説明が難しい
SEの「トラブルが絶対に起きるので、余裕を持ったスケジュールにしてください」の言い分は、クライアントにとっては「トラブル防止策を徹底して遅延を防げ」の返答に尽きてしまいます。
(クライアントととしては納期が伸びる分、システム開発の費用増加なので、SEは強く言い返すことはできないのは実状です。)
潜在的なトラブルがスケジュール設定時に把握しにくい
突然のプロジェクトメンバーの離任に伴う新たな人員確保・育成や、テストで発覚する仕様ミスにより開発や設計などの前工程への差し戻しなど、そういったトラブルは目に見えずスケジュール化をすることができません。(もしスケジュールにこれらを加味するとしたら、スケジュール作成だけで途方もない時間がかかってしまいますね、、、)
これらを理由ににSEが夜遅くまでの残業、休日出勤を強いられことになり、ブラック化してしまいます。
プロジェクトが大きくなればなるほど潜在的なトラブルの数や、それによる影響が大きいため数千人規模のプロジェクトはブラック化・炎上がしやすくなってしまいます。
②クライアントとマネージャーの開発現場の理解不足
システムの概要を決定していくクライアントとマネージャーは、どうしてもプログラムレベルでの開発現場を理解することが難しいです。
その結果、トラブルが起きた場合や、急な仕様変更が必要となった場合、
クライアントはシステム開発の現場まで認識できていないこと、マネージャーはできるorできないのゼロイチで判断しないといけないことにより、
「納期はこのままでも(残業や休日出勤をすれば)できるだろう」と、現場の状況を加味されない判断になってしまいます。
③人手不足
SEの業界は何十万もの人手が常に不足であり、少ない人数に仕事が集中します。
そのため、そもそもトラブルや仕様変更がなかったとしても、常にSEは残業や休日出勤が強いられてしまいます。
なので、SEは多忙により健康不慮やうつ病が多く、たとえスケジュール通りでもブラック化しやすいのです。
④スキルやノウハウの共有不足
プロジェクトの当初は、SE間のスキルやノウハウを統一できるようなマニュアルを用意しますが、プロジェクトが進むにつれマニュアルではカバーしきれないため、
結果的にマニュアルに記載されていないことは属人的に対応することになってしまいます。
本来そうなった場合は、都度マニュアルを更新していくべきですが、実状SEは忙しいため、属人的なまま放置されることが多いです。
その結果
- 特定の一人に仕事が殺到する
- 離任した場合、引き継ぎ作業や新たな人員の確保・育成が必要となる
など、スケジュール外の作業が発生してしまいます。
まとめ
- トラブルは必ず発生するが、それをスケジュールに加味できず、結果的に時間外で対応を迫られる
- 開発現場の状況を加味されない判断がされやすい
- 人で不足のため、トラブル無くスケジュール通りだとしても、残業や休日出勤は強いられることが多い