ソフトウェアエンジニアが労働について情報発信するブログ

ブラック労働からホワイト労働まで経験したソフトウェアエンジニアが世の中にとって役立つことを情報発信していく。

ブラック労働経験から得る、破綻するシステム開発プロジェクトにおける予兆検知のポイント

私はソフトウェアエンジニアとして「ブラック労働」から「ホワイト労働」まで経験してきた。

その中の一つのシステム開発プロジェクトで、大手半導体メーカー企業の孫請け企業に派遣され「ブラック労働」を経験したときの話と、それを見抜くための予兆、当該開発現場における改善ポイントについてまとめた。

同様の環境に身を置いている方には、この記事の内容をインプットしていただき、場合によっては転職を検討するなど、自分の身を守っていただきたいと考えている。

目次


1.ブラック労働となったプロジェクト状況

顧客W社は大規模システムを大手半導体メーカーX社に発注し、X社はグループ会社のY社に、Y社は同じくグループ会社のZ社に開発を依頼した。Z社がY社より受注したプロジェクトを、以降「プロジェクトP」と記載する。プロジェクトP進行のため、Z社には私を含む数名が派遣エンジニアとして投入された。Z社の体制は、プロジェクトリーダー(Z社社員)をはじめ、メンバーはZ社社員と、派遣エンジニアで構成される。また、Z社はY社窓口とやりとりをする形であった。

【概要】
W社:顧客
X社:元請け、大手半導体メーカー
Y社:下請け、グループ会社、「プロジェクトP」発注
Z社:孫受け、グループ会社、「プロジェクトP」受注

私は3か月の派遣契約で、Z社に投入された。私と同じくZ社に派遣契約で投入されたメンバA氏はさらに契約期間が長かった。

私の契約期間がが3か月である理由は2つある。一つは派遣元企業におけるプロジェクト要員アサイン計画上の都合、もう一つは開発開始3か月経過後には設計・実装工程が完了しテスト工程が中心となるため体制を縮小するというZ社側の意向であった。

この3か月間の私の残業時間の推移としては、一月目、二月目と増加傾向にあり、三月目には過労死基準寸前という程度であった。他のメンバーも同様かそれを少し上回る程度だった。そして3か月が経過し、私が派遣契約を終了してからは、Z社のリーダーは徹夜・休日出勤するようになり、このプロジェクトは破綻したそうだ。(詳細は不明)

2.プロジェクト期間中に感じたブラック労働の予兆

ブラック労働に至る予兆は細かい部分に現れる。自身がソフトウェア開発作業において不快感ややりにくさを感じたならそれは危険信号である。

ここでは、Z社のプロジェクトPの開発期間中に感じたブラック労働の予兆で、代表的なものを挙げる。ここに挙げているものが全てではない。また、Z社へ発注しているY社に原因があるものもある。

2-1.設計ドキュメントが機能していない

設計ドキュメントが細かく分かりにくい。慣れない用語や曖昧さがある。

その製品開発における過去のプロジェクトに携わり、システム全体の知識を持った人がさらに詳細を理解することを目的とするならば、不便の無いドキュメントであると思われる。

しかし、いきなりプロジェクトPに投入され、全体を知らない人が読むドキュメントとしては情報量が多すぎて、知りたいことをすぐに引き出せないのである。これでは、ドキュメントとして十分機能していない。

ここまでなら、他社でも普通に起こりうる話であるが、プロジェクトPが違うのはここから先である。

優良企業であれば、不慣れな人が慣れるのに時間がかかることを想定して十分な工数を取り、設計ドキュメントのみでは理解できないところを丁寧に補っていく。そしてドキュメント自体の改善に繋げる。一方、プロジェクトPでは、あたかも設計ドキュメントを理解する側のスキル不足とみなしてマウントを取ることが当たり前に行われる。

  • 「◯◯に書いてありますよね。」
  • 「当たり前ですよね。」
  • 「○○の意味と捉えるのが普通ですよね。」

「当たり前」「普通」・・・。誰にとっての「当たり前」「普通」なのか?

Z社では「当たり前」「普通」なのかも知れない。でも、他の考え方もある。Z社にとっての「当たり前」に当てはまらない経験をした人もいる。Z社の「当たり前」は世間にとっての「当たり前」とは限らない。

また、

「設計ドキュメントがあるから、早くできる。」

などと称し、短いスケジュールを設定することがある。しかし、情報量が多すぎて理解に時間がかかったり、過去製品の開発当時は必要な情報でも、次製品の開発時に過去製品の情報を調査する場合には不要な情報もあり、これらが入り混じっている。

まず、自分自身がスキル不足でもないのに、過去製品の設計ドキュメントをスムーズに理解できない状況で、かつそれを読み手のせいにしてマウントを取る開発現場はヤバいと考えた方が良い。

  • 設計ドキュメントの情報量が不足している
  • 設計ドキュメントの情報量が多すぎる
  • 知りたい情報がすぐに見つからない
  • ソースコードとドキュメントのアンマッチ

このような前段に問題があることに着目せず、そのまま放置していることの裏付けとなる。

また残念なのは、派遣契約の場合派遣先の指示に従わないといけない。派遣先企業Z社のプロジェクトPにおける開発プロセスがどんなに粗悪なものであってもである。プロセスを変える権限等ないため、優秀な派遣エンジニアにとっては非常にもったいない状況となる。

2-2.一部の人間が上から目線でマウントを取ろうとする

先程の内容と一部重複する。

設計の内容や当該開発現場でのプロセスについてこちらが質問したところ、普通はその内容について必要な回答のみをすれば良いわけである。

しかし、それに「当たり前です」「当然です」といった余計な言葉が付き、不快感を感じることがある。質問者は必要な回答のみが得られれば良く、それが「当たり前」かどうかはどうでも良いのである。

「当たり前」「当然」とは、「誰にとって当たり前」なのか、回答する側の人や組織の主観にすぎない。

ある人にとっては「当たり前」でも、別の人にとっては「当たり前」ではないかもしれない。各個人の、経験、価値観によって変わるところであるが、自分たちの価値観に従え、マウントを取ろうとしていることの現れであると見抜く必要がある。

また、質問者の「欲しい情報」「必要な回答」よりも、「回答者の言いたいこと」が前面に出てしまっているケースが見受けられる。このような回答者はコミュニケーションに問題がある可能性があるため、慎重に見極めておきたい。

コミュニケーションの面で何となく自分が不快感を感じたときは、何か問題がある予兆であると同時に、素直にどこに不快感を感じたのか具体的にしておくと良い。

このような無駄にマウントを取ろうとする行為が、相手側を不快にさせ、余計な消耗を生み、生産性が下がる。ブラック労働になっていく予兆だ。

2-3.進捗遅れが少しずつ顕在化し、「見積の適切性」に疑問を感じる

進捗遅れの要因が、これといった明確なケースがある場合と、そうでないケースがある。明確なケースはその点を対処すれば良い。しかし、この現場は後者の方である。この開発現場では冒頭でも示したように、月ごとに徐々に残業時間が増え、プロジェクト開始3カ月目で早くも月残業時間が過労死基準の手前まで跳ね上がるといった状況である。

また、特定のエンジニアのスキル不足ということも考えられるが、この現場のプロジェクトではメンバ全員の進捗が一律に予定より遅れていることから、この可能性は極めて低いと判断される。

そもそも「進捗遅れ」と称するところが適切とは考えられず、プロジェクトPにおける元々の計画自体が破綻しており、「見積り・スケジュールの適切性」が全く議論されていない状況である。

2-4.使用するパソコンのトラブルが多い

この開発現場も然りだが、長時間労働になりやすい開発現場は、パソコンのトラブルが多発する傾向にある。具体的には、使用するツールの動作が遅く、パソコンがフリーズする等、業務効率に致命的な影響を与える。

それにも関わらず、その開発現場で作業する社員や派遣要員に、経費をケチって粗悪なスペックのパソコンで作業させることがある。

これによる作業の遅延や低効率の状況でも

  • 「言い訳をするな」
  • 「環境のせいにするな」

のような根性論を吹き込む未熟者を時々見かけたことがあるが、

  • 「環境が大事であること」
  • 「IT・システム開発企業として恥ずかしいこと」

と認識すべきである。

2-5.パワハラが行われる

下記の3記事はプロジェクトPにおける、発注元のY社窓口の要員を加害者とするパワハラ事例である。
o08usyu7231.hatenablog.com
o08usyu7231.hatenablog.com
o08usyu7231.hatenablog.com
受注側Z社リーダー要員もこれを受け入れており、発注元Y社を是正しようとする気が無く、同調している。

一方、Y社窓口の要員は、私と一緒にプロジェクトPを進めてきたA氏からも評判が悪かった。受け手が不快感を感じるような嫌味、揚げ足取りは、パワハラとなりうる。

パワハラが発生すれば、組織の生産性が下がることは周知の事実であり、ブラック労働に直結するリスクは大きい。

2-6.ソフトウェア開発を簡単そうに語る

「ソフトウェア開発を簡単そうに語る」

姿を見ると、素人なら

「この人はそんなにすごい技術を持っているのか」

というイメージを持ち、圧倒されてしまいそうである。しかし、現実はそうではない。冷静に見るべきだ。

本当にソフトウェア開発に関する技術や経験のある人は、ソフトウェア開発の難しさを知っている。

「ソフトウェア開発を簡単そうに語る」人は、

  • ソフトウェア開発を下請けに丸投げして、自身はソフトウェアをわかっていないことに気づかないまま、発注者側が偉いと勘違いしている
  • 本当に技術があったとしても、他の人が行き詰まる点を掴めず、ソフトウェア開発を組織として円滑に進めることができないマネジメントの未熟者

のいずれかである。

私が様々な企業を見てきて掴んだ傾向は、

「トラブルを想定していない企業ほどトラブルが多い」

ことである。プロジェクトPもこれに当てはまる。
o08usyu7231.hatenablog.com

2-7.多重下請け構造である

多重下請け構造の下位層にいる企業は、構造上の問題からブラック労働になりやすい。

詳細は別記事で紹介しているのでそちらを参照いただきたいが、予兆検知のポイントとして捉えておきたい。
o08usyu7231.hatenablog.com
o08usyu7231.hatenablog.com

エンジニア個人で解決できる問題ではないので、多重下請け構造のプロジェクトは受注しないのが賢いと言える。

3.長時間のブラック労働がエンジニア個人のスキル不足ではないと確定

これまでの予兆を捉えつつプロジェクトPを進めていった結果、ブラック労働が顕在化し、プロジェクト開始三月目には過労死基準寸前の残業時間となった。

情弱なエンジニアであれば

「自分のスキル不足で、ソフトウェア開発の進捗が遅れ、周囲に迷惑をかけている」

と思い込むかもしれない。

自身で改善できることは改善しなければならない。しかし、無理が祟り精神を壊さないためにも、ブラック労働に至る「前段」に着目し、

  • 無理な要求により長時間労働が常態化
  • プロジェクト規模・内容とスケジュールがミスマッチで異常
  • パワハラ体質
  • 根性でやり遂げようとする
  • ソフトウェアエンジニアの犠牲でもってプロジェクトが成立している
  • 困難な内容を簡単そうに語られる

といった、エンジニア個人で解決不可能な「前段の粗悪さ」を正しく見抜く必要がある。

「粗悪さ」≠「厳しさ」であるため、これらの見極めが必要である。
o08usyu7231.hatenablog.com

ここでは、「前段の粗悪さ」を正しく見抜いた決定的な根拠があるので、それを紹介したい。

3-1.発注元Y社社員の立ち話によりそもそも無理なプロジェクトであることが判明

Z社内で私と一緒にプロジェクトPを進めてきたA氏が、開発したシステムのテストの都合上、Y社へ出向く時期があった。このときにY社内でY社社員同士の立ち話を耳にし、その情報をA氏が私へ教えてくれたのである。

  • 「プロジェクトPは終わっている」
  • 「どう考えてもあのスケジュールは無理だろう」
  • 「あのような無茶な依頼をよくZ社に発注するよな」
  • 「Z社も気の毒だ」

本来Y社としては社外に聞かれたくない情報だったかも知れない。

プロジェクトPのY社窓口社員は立場上このような意向を表向きには出さないが、Y社の中にもこのように考える人がいることが判明した。

3-2.他社での実績と他社現場との徹底比較の結果明らかに違和感

私はZ社でのプロジェクトP以前にも、「ブラック労働」「ホワイト労働」両方を経験しており、過去のソフトウェア開発において多大な実績を挙げ、各々の開発現場さらにその先に貢献してきたと自負している。

一方で、過去のブラック労働によって健康面に影響した経験もある。

このような様々な経験を積んできたからこそ、他社との比較ができる。

  • 「自分のせいでプロジェクトPの進捗が遅れている」
  • 「自分が周囲に迷惑をかけている」
  • 「自分がいくら努力しても追いつかない」
  • 「自分は能力不足かもしれない」

プロジェクトPではこのように自分を責めることがなかったため、体力的な疲労はあるものの、鬱病などのように精神を壊すことはなかった。
o08usyu7231.hatenablog.com
o08usyu7231.hatenablog.com

何かおかしなことがあれば、判断基準を(他社や世間等)当該組織の外に置くことが重要である。そのようにすることで、当該組織を一歩引いた目線から俯瞰して見ることができ、問題点の発見に至ることがある。
o08usyu7231.hatenablog.com

4.ブラック労働が顕在化したプロジェクトの結末とその後、および補足

最後にプロジェクトPがどうなったか、プロジェクトPに関わっていたメンバーはどうなったか、その後の私のキャリアはどうなったか、その他諸々を述べてこのお話を締めたい。

まず、私は予定通りZ社との派遣契約を終了し、プロジェクトPから離脱した。これまで一緒に開発をしてきたメンバA氏は引き続きZ社内でプロジェクトPに携わることとなる。冒頭にも述べたように、私が派遣契約を終了してからは、Z社のリーダーは徹夜・休日出勤するようになり、このプロジェクトは破綻したそうだ。(詳細は不明)

更に、プロジェクトPに関わった人たちがY社、Z社を問わず退職者が相次いだ。中にはZ社のマネージャクラスの人も含まれている。Z社のプロジェクトPのリーダー、およびY社プロジェクトP窓口社員が退職したという情報は無い。憶測が入る形ではあるが、プロジェクトPにおけるブラック労働の加害者は各企業に残り続け、被害者が退職する形になったようだ。

私自身は、Z社での派遣契約を終了後、別業務を経験後、転職活動の末、大手企業へ転職。転職後もソフトウェアエンジニアである。プロジェクトPにおける反面教師がその後のプロジェクトに活かされ、転職にも活かされた。

ブラック企業ではなくても、ブラック労働の予兆を掴むことは、本記事で紹介した通り可能である。ブラック企業でないからといって、全ての部門、全ての業務、全てのプロジェクトがブラックでないとは限らない。経験と勘によるところもあるが、情報収集と転職などの準備は大切である。自分の生活、自分の健康、自分のキャリアを守るためにも、まずは転職サイトに登録することをお勧めする。









最後に、Z社の良かった点を挙げておく。

Z社のマネージャは、プロジェクトPのリーダーとは違い、プロジェクトP初期の頃に

「ウチの会社は他と比べてどうですか?」

と私に聞いてきたのである。

私は派遣だったので、悪い回答はできなかった。実際、プロジェクトPの開発初期の頃の残業時間は普通程度だったし、そこから段々と増えてきたのが事実である。

しかし、私が良いと感じたのは

「派遣要員から見た他社との比較結果を気にしている」

点である。このような視座が持てない管理職が少なくない中、大切にしたい姿勢であると感じている。

もう一つは私と一緒に仕事をしてきたA氏だ。

A氏はプロジェクトPの長時間労働に関する愚痴が多くみられるのだが、私は全く不快感を感じることなく共感できた。

それどころか、IT業界にいて人間らしい感覚を持った人材であると魅力を感じたほどであった。ブラック労働に同調する社畜とは全く違う。IT業界・エンジニア・ビジネスパーソンとして・・・のみではなく、人間としてどうあるべきかを改めて考えさせられる機会だった。