私はソフトウェアエンジニアとして「ブラック労働」から「ホワイト労働」まで経験してきた。
その中の一つのシステム開発プロジェクトで、大手半導体メーカー企業の孫請け企業に派遣され「ブラック労働」を経験したときの話と、それを見抜くための予兆、当該開発現場における改善ポイントについてまとめた。
同様の環境に身を置いている方には、この記事の内容をインプットしていただき、場合によっては転職を検討するなど、自分の身を守っていただきたいと考えている。
1.ブラック労働となったプロジェクト状況
顧客Ｗ社は大規模システムを大手半導体メーカーＸ社に発注し、Ｘ社はグループ会社のＹ社に、Ｙ社は同じくグループ会社のＺ社に開発を依頼した。Ｚ社がＹ社より受注したプロジェクトを、以降「プロジェクトＰ」と記載する。プロジェクトＰ進行のため、Ｚ社には私を含む数名が派遣エンジニアとして投入された。Ｚ社の体制は、プロジェクトリーダー（Ｚ社社員）をはじめ、メンバーはＺ社社員と、派遣エンジニアで構成される。また、Ｚ社はＹ社窓口とやりとりをする形であった。
私は３か月の派遣契約で、Ｚ社に投入された。私と同じくＺ社に派遣契約で投入されたメンバＡ氏はさらに契約期間が長かった。
私の契約期間が３か月である理由は２つある。一つは派遣元企業におけるプロジェクト要員アサイン計画上の都合、もう一つは開発開始３か月経過後には設計・実装工程が完了しテスト工程が中心となるため体制を縮小するというＺ社側の意向であった。
この３か月間の私の残業時間の推移としては、一月目、二月目と増加傾向にあり、三月目には過労死基準寸前という程度であった。他のメンバーも同様かそれを少し上回る程度だった。そして３か月が経過し、私が派遣契約を終了してからは、Ｚ社のリーダーは徹夜・休日出勤するようになり、このプロジェクトは破綻したそうだ。（詳細は不明）
2.プロジェクト期間中に感じたブラック労働の予兆
ブラック労働に至る予兆は細かい部分に現れる。
自身がソフトウェア開発作業において不快感ややりにくさを感じたならそれは危険信号である。
ここでは、Ｚ社のプロジェクトＰの開発期間中に感じたブラック労働の予兆で、代表的なものを挙げる。ここに挙げているものが全てではない。また、Ｚ社へ発注しているＹ社に原因があるものもある。
2-1.設計ドキュメントが機能していない
設計ドキュメントが細かすぎて分かりにくい。慣れない用語や曖昧さがある。
その製品開発における過去のプロジェクトに携わり、システム全体の知識を持った人がさらに詳細を理解することを目的とするならば、不便の無いドキュメントであると思われる。
しかし、いきなりプロジェクトＰに投入され、全体を知らない人が読むドキュメントとしては情報量が多すぎて、知りたいことをすぐに引き出せないのである。これでは、ドキュメントとして十分機能していない。
ここまでなら、他社でも普通に起こりうる話であるが、プロジェクトＰが違うのはここから先である。
優良企業であれば、不慣れな人が慣れるのに時間がかかることを想定して十分な工数を取り、設計ドキュメントのみでは理解できないところを丁寧に補っていく。そしてドキュメント自体の改善に繋げる。一方、プロジェクトＰでは、あたかも設計ドキュメントを理解する側のスキル不足とみなしてマウントを取ることが当たり前に行われる。
- 「◯◯に書いてありますよね。」
- 「当たり前ですよね。」
- 「○○の意味と捉えるのが普通ですよね。」
「当たり前」「普通」・・・。誰にとっての「当たり前」「普通」なのか？
Ｚ社では「当たり前」「普通」なのかも知れない。でも、他の考え方もある。Ｚ社にとっての「当たり前」に当てはまらない経験をした人もいる。Ｚ社の「当たり前」は世間にとっての「当たり前」とは限らない。
また、
「設計ドキュメントがあるから、早くできる。」
などと称し、短いスケジュールを設定することがある。
しかし、情報量が多すぎて理解に時間がかかったり、過去製品の開発当時は必要な情報でも、次製品の開発時に過去製品の情報を調査する場合には不要な情報もあり、これらが入り混じっている。
まず、自分自身がスキル不足でもないのに、過去製品の設計ドキュメントをスムーズに理解できない状況で、それを読み手のせいにしてマウントを取る開発現場はヤバいと考えた方が良い。
- 設計ドキュメントの情報量が不足している
- 設計ドキュメントの情報量が多すぎる
- 知りたい情報がすぐに見つからない
- ソースコードとドキュメントのアンマッチ
このような前段と向き合わず、そのまま放置していると、以降も同じことを繰り返す。読み手のスキルではない。
また残念なのは、派遣契約の場合、派遣要員は派遣先の指示に従わないといけない。派遣先企業Ｚ社のプロジェクトＰにおける開発プロセスがどんなに粗悪なものであってもである。派遣要員がプロセスを変える権限等ないため、優秀な派遣エンジニアにとっては非常にもったいない状況となる。
2-2.一部の人間が上から目線でマウントを取ろうとする
先程の内容と一部重複する。
設計の内容や当該開発現場でのプロセスについてこちらが質問したところ、普通はその内容について必要な回答のみをすれば良いわけである。
しかし、それに「当たり前です」「当然です」といった余計な言葉が付き、不快感を感じることがある。質問者は必要な回答のみが得られれば良く、それが「当たり前」かどうかはどうでも良いのである。
「当たり前」「当然」とは、「誰にとって当たり前」なのか、回答する側の人や組織の主観にすぎない。
ある人にとっては「当たり前」でも、別の人にとっては「当たり前」ではないかもしれない。各個人の、経験、価値観によって変わるところであるが、自分たちの価値観に従え、マウントを取ろうとしていることの現れであると見抜く必要がある。
また、質問者の「欲しい情報」「必要な回答」よりも、「回答者の言いたいこと」が前面に出てしまっているケースが見受けられる。このような回答者はコミュニケーションに問題がある可能性があるため、慎重に見極めておきたい。
コミュニケーションの面で何となく自分が不快感を感じたときは、何か問題がある予兆であると同時に、素直にどこに不快感を感じたのか具体的にしておくと良い。
このような無駄にマウントを取ろうとする行為が、相手側を不快にさせ、余計な消耗を生み、生産性が下がる。ブラック労働になっていく予兆だ。
2-3.進捗遅れが少しずつ顕在化し、「見積の適切性」に疑問を感じる
進捗遅れの要因が、これといった明確なケースがある場合と、そうでないケースがある。明確なケースはその点を対処すれば良い。しかし、この現場は後者の方である。この開発現場では冒頭でも示したように、月ごとに徐々に残業時間が増え、プロジェクト開始３カ月目で早くも月残業時間が過労死基準の手前まで跳ね上がるといった状況である。
また、特定のエンジニアのスキル不足ということも考えられるが、この現場のプロジェクトではメンバ全員の進捗が一律に予定より遅れていることから、この可能性は極めて低いと判断される。
そもそも「進捗遅れ」と称する時点で、見積が適切である前提で話が進められている。見積が不適切であっても、そのことは議論もされず、気付きが遅れる。現時点で見積が不適切であるということは、この先予定している作業の見積もりも同じように不適切である可能性が高い。プロジェクトＰがかなり進んだ時点で、元々の計画自体が破綻していることに気付いても、もう手遅れである。
2-4.使用するパソコンのトラブルが多い
この開発現場も然りだが、長時間労働になりやすい開発現場は、パソコンのトラブルが多発する傾向にある。具体的には、使用するツールの動作が遅く、パソコンがフリーズする等、業務効率に致命的な影響を与える。
それにも関わらず、その開発現場で作業する社員や派遣要員に、経費をケチって粗悪なスペックのパソコンで作業させることがある。
これによる作業の遅延や低効率の状況でも
- 「言い訳をするな」
- 「環境のせいにするな」
のような根性論を吹き込む未熟者を時々見かけたことがある。
IT・システム開発企業として恥ずかしいことと認識すべきである。
2-5.パワハラが行われる
下記の３記事はプロジェクトＰにおける、発注元のＹ社窓口の要員を加害者とするパワハラ事例である。
o08usyu7231.hatenablog.com
o08usyu7231.hatenablog.com
o08usyu7231.hatenablog.com
受注側Ｚ社リーダー要員もこれを受け入れており、発注元Ｙ社を是正しようとする気が無く、同調している。
一方、Ｙ社窓口の要員は、私と一緒にプロジェクトＰを進めてきたＡ氏からも評判が悪かった。受け手が不快感を感じるような嫌味、揚げ足取りは、パワハラとなりうる。
パワハラが発生すれば、組織の生産性が下がることは周知の事実であり、ブラック労働に直結するリスクは大きい。
2-6.ソフトウェア開発を簡単そうに語る
「ソフトウェア開発を簡単そうに語る」
姿を見ると、素人なら
「この人はそんなにすごい技術を持っているのか」
というイメージを持ち、圧倒されてしまいそうである。
しかし、現実はそうではない。冷静に考えると全く逆だ。
本当にソフトウェア開発に関する技術や経験のある人は、ソフトウェア開発の難しさを知っている。
「ソフトウェア開発を簡単そうに語る」人は、
- ソフトウェア開発を下請けに丸投げして、自身はソフトウェアをわかっていないことに気づかないまま、発注者側が偉いと勘違いしている
- 本当に技術があったとしても、他の人が行き詰まる点を掴めず、ソフトウェア開発を組織として円滑に進めることができないマネジメントの未熟者
のいずれかである。
私が様々な企業を見てきて掴んだ傾向は、
「トラブルを想定していない企業ほどトラブルが多い」
ことである。プロジェクトＰもこれに当てはまる。
o08usyu7231.hatenablog.com
2-7.多重下請け構造である
多重下請け構造の下位層にいる企業は、構造上の問題からブラック労働になりやすい。
詳細は別記事で紹介しているのでそちらを参照いただきたいが、予兆検知のポイントとして捉えておきたい。
o08usyu7231.hatenablog.com
o08usyu7231.hatenablog.com
エンジニア個人で解決できる問題ではないので、多重下請け構造のプロジェクトは受注しないのが賢いと言える。
3.長時間のブラック労働がエンジニア個人のスキル不足ではないと確定
これまでの予兆を捉えつつプロジェクトＰを進めていった結果、ブラック労働が顕在化し、プロジェクト開始三月目には過労死基準寸前の残業時間となった。
情弱なエンジニアであれば
「自分のスキル不足で、ソフトウェア開発の進捗が遅れ、周囲に迷惑をかけている」
と思い込むかもしれない。
自身で改善できることは改善しなければならない。
しかし、無理が祟り精神を壊さないためにも、ブラック労働に至る「前段」に着目し、
- 無理な要求により長時間労働が常態化
- プロジェクト規模・内容とスケジュールがミスマッチで異常
- パワハラ体質
- 根性でやり遂げようとする
- ソフトウェアエンジニアの犠牲でもってプロジェクトが成立している
- 困難な内容を簡単そうに語られる
といった、エンジニア個人で解決不可能な「前段の粗悪さ」を正しく見抜く必要がある。
「粗悪さ」≠「厳しさ」であるため、これらの見極めが必要である。
o08usyu7231.hatenablog.com
ここでは、「前段の粗悪さ」を正しく見抜いた決定的な根拠があるので、それを紹介したい。
3-1.発注元社員同士の立ち話によりそもそも無理なプロジェクトであることが判明
Ｚ社内で私と一緒にプロジェクトＰを進めてきたＡ氏が、開発したシステムのテストの都合上、Ｙ社へ出向く時期があった。このときにＹ社内でＹ社社員同士の立ち話を耳にし、その情報をＡ氏が私へ教えてくれたのである。
- 「プロジェクトＰは終わっている」
- 「どう考えてもあのスケジュールは無理だろう」
- 「あのような無茶な依頼をよくＺ社に発注するよな」
- 「Ｚ社も気の毒だ」
本来Ｙ社としては社外に聞かれたくない情報だったかも知れない。
プロジェクトＰのＹ社窓口社員は立場上このような意向を表向きには出さないが、Ｙ社の中にもこのように考える人がいることが判明した。
3-2.他社での実績と他社現場との徹底比較の結果明らかに違和感
私はＺ社でのプロジェクトＰ以前にも、「ブラック労働」「ホワイト労働」両方を経験しており、過去のソフトウェア開発において多大な実績を挙げ、各々の開発現場さらにその先に貢献してきたと自負している。
一方で、過去のブラック労働によって健康面に影響した経験もある。
このような様々な経験を積んできたからこそ、他社との比較ができる。
- 「自分のせいでプロジェクトＰの進捗が遅れている」
- 「自分が周囲に迷惑をかけている」
- 「自分がいくら努力しても追いつかない」
- 「自分は能力不足かもしれない」
プロジェクトＰではこのように自分を責めることがなかったため、体力的な疲労はあるものの、鬱病などのように精神を壊すことはなかった。
o08usyu7231.hatenablog.com
o08usyu7231.hatenablog.com
何かおかしなことがあれば、判断基準を（他社や世間等）当該組織の外に置くことが重要である。そのようにすることで、当該組織を一歩引いた目線から俯瞰して見ることができ、問題点の発見に至ることがある。
o08usyu7231.hatenablog.com
4.ブラック労働が顕在化したプロジェクトの結末とその後、および補足
最後にプロジェクトＰがどうなったか、プロジェクトＰに関わっていたメンバーはどうなったか、その後の私のキャリアはどうなったか、その他諸々を述べてこのお話を締めたい。
まず、私は予定通りＺ社との派遣契約を終了し、プロジェクトＰから離脱した。これまで一緒に開発をしてきたメンバＡ氏は引き続きＺ社内でプロジェクトＰに携わることとなる。冒頭にも述べたように、私が派遣契約を終了してからは、Ｚ社のリーダーは徹夜・休日出勤するようになり、このプロジェクトは破綻したそうだ。（詳細は不明）
更に、プロジェクトＰに関わった人たちがＹ社、Ｚ社を問わず退職者が相次いだ。中にはＺ社のマネージャクラスの人も含まれている。Ｚ社のプロジェクトＰのリーダー、およびＹ社プロジェクトＰ窓口社員が退職したという情報は無い。憶測が入る形ではあるが、プロジェクトＰにおけるブラック労働の加害者は各企業に残り続け、被害者が退職する形になったようだ。
私自身は、Ｚ社での派遣契約を終了後、別業務を経験後、転職活動の末、大手企業へ転職。転職後もソフトウェアエンジニアである。プロジェクトＰにおける反面教師がその後のプロジェクトに活かされ、転職にも活かされた。
ブラック企業ではなくても、ブラック労働の予兆を掴むことは、本記事で紹介した通り可能である。ブラック企業でないからといって、全ての部門、全ての業務、全てのプロジェクトがブラックでないとは限らない。経験と勘によるところもあるが、情報収集と転職などの準備は大切である。自分の生活、自分の健康、自分のキャリアを守るためにも、まずは転職サイトに登録することをお勧めする。
30代後半〜40代前半は、キャリアチェンジも容易ではなく、かつ家庭がある方が多く、自由度が低い、リスクが取りにくい、といったキャリアを築く上では、あまりに大きな課題を抱えています。RYOMEIのトレーナーも同じ世代であり、自身も子育てと仕事の両立に試行錯誤していたり、順風満帆にキャリアを築いているわけではないからこそ、受講者の痛みに共感しながら、一緒に考えていくことができます。
困難な状況にある方こそ、お勧めできるサービスです。是非、一歩踏み出し、人生を変えてみませんか？
最後に、Ｚ社の良かった点を挙げておく。
Ｚ社のマネージャは、プロジェクトＰのリーダーとは違い、プロジェクトＰ初期の頃に
「ウチの会社は他と比べてどうですか？」
と私に聞いてきたのである。
私は派遣だったので、悪い回答はできなかった。実際、プロジェクトＰの開発初期の頃の残業時間は普通程度だったし、そこから段々と増えてきたのが事実である。
しかし、私が良いと感じたのは
「派遣要員から見た他社との比較結果を気にしている」
点である。このような視座が持てない管理職が少なくない中、大切にしたい姿勢であると感じている。
もう一つは私と一緒に仕事をしてきたＡ氏だ。
Ａ氏はプロジェクトＰの長時間労働に関する愚痴が多くみられるのだが、私は全く不快感を感じることなく共感できた。
それどころか、IT業界にいて人間らしい感覚を持った人材であると魅力を感じたほどであった。ブラック労働に同調する社畜とは全く違う。IT業界・エンジニア・ビジネスパーソンとして・・・のみではなく、人間としてどうあるべきかを改めて考えさせられる機会だった。
