「ホワイト労働」「ブラック労働」の両方を経験した私が、両者を徹底比較してきた結果をお伝えする。かなりの違いがある印象を受けている。一個人が経験したことであるため、これから記載する内容が全てをカバーしているものではないし、中には主観的な部分もあることを了承願いたい。
以下、「表題」「ホワイト」「ブラック」の順に記載していく。「表題」の件について、「ホワイト」なケースと「ブラック」なケースについて、対比しながら言及していく。皆さんの職場環境がどのようなものか、見極めの参考にしてほしい。
「ホワイト」とは、「ホワイト企業」「優良企業」「ホワイトな開発現場（職場環境）」「ホワイトな人材」「ホワイトな考え方」「ホワイトな出来事」のいずれかを指す。
「ブラック」とは、「ブラック企業」「粗悪な企業」「ブラックな開発現場（職場環境）」「ブラックな人材」「ブラックな考え方」「ブラックな出来事」のいずれかを指す。
見積り・スケジュール
○「ホワイト」
残業しないことを前提としたスケジュールを設定する。トラブルが起きるリスクも考慮し、スケジュールにはバッファを持たせておく。作業工数が読めない場合は、長めに設定するか、読めない旨を説明しスケジュール調整を要請する可能性がある旨を伝えておく。長時間労働の未然防止のためにあらゆる手段を尽くし、開発要員に負担をかけないように最大限配慮する。
●「ブラック」
余裕を持ったスケジュールを設定しようとすれば、「なぜそんなにかかるのか。○日あれば十分だろう。」と詰問される。特に、要求側は「根拠を説明してほしい。」と迫ってくるが、根拠の説明は建前であり、本音は短いスケジュールを約束させたい意図がある。そもそも発注元は発注先にソフトウェア開発を丸投げしているケースが多く、発注先が開発工数を要する根拠を説明しても、発注元が理解できるだけの能力や姿勢に欠けており、何を説明しても時間の無駄でしかない。結局力関係を背景に、短い日程での完成を約束させられる。（パワハラ６類型の「過大な要求」に該当する可能性がある。） また、その執拗さが半端なく異常。長時間労働の未然防止の妨害行為が見られる。ハラスメントにあたるので、このような依頼はお断りするのが正解。
o08usyu7231.hatenablog.com
派生開発におけるベース製品の仕様書・設計書
○「ホワイト」
仕様書・設計書が完璧で全く滞りなくスムーズに理解できるケースの方が少ない。時々、ベース製品のソースコードの方が新しく仕様書・設計書が一部最新の状態に更新されていないことがある。ある程度の情報はあるため、ソースコードと合わせて、不明点を有識者の協力を得ながら解決することで理解が進んでいく。また、ある程度理解するまで時間がかかることをあらかじめ想定している。
●「ブラック」
ある程度の情報はあるものの、その仕様書・設計書を読んで理解できるだけの前提知識がない状態で、依頼者はドキュメントだけを丸投げし、「読めばわかる」の一言を言い放つ。ドキュメントに不備があっても、作業者がスムーズに理解が進まないと、あたかも作業者がスキル不足であるかのような扱いをする。仕様書・設計書には、前提知識がわかる人が読めば、更に詳細を思い出せる程度の情報はあるが、前提知識のない人が読んでも理解できるドキュメントになっていない。依頼者はそのことに気付かない。
派生開発プロセス
○「ホワイト」
派生開発特有の難しさを理解しており、派生開発プロセスについて学び、プロセスの見直しが行われている。
●「ブラック」
派生開発特有の難しさを理解しておらず、新規開発と同じプロセスでやろうとする。これを「新規開発崩し」という。
他製品からの仕様横展開、他製品からのソフトウェア移植
○「ホワイト」
他製品からの移植といえども、ソフトウェアをそのまま移植できる場合とできない場合があること、移植だけで移植先の製品の品質が担保できるかどうかを考える姿勢、移植か否かによらない設計・検証の観点やノウハウを備えている。移植といえども誤りやすい点を理解しており、移植だからといって気を抜かない。
●「ブラック」
依頼者は作業者に対して「移植するだけ」「持ってくるだけ」「簡単」「○日あれば余裕でできる」などと、いかにも簡単に実現できるかのような印象操作をしておき、短いスケジュールでの完成を約束させようとする。また、その執拗さが半端なく異常。詐欺商法の手口と全く同じ。
作業者が多忙で業務負荷が高い
○「ホワイト」
依頼者が作業者に対して、「様々な業務を依頼しているため、業務負荷が高くなり申し訳ない」と思っている。しかし、作業者は忙しいにしても「申し訳ない」と思われる程負荷が高いとは思っていない。作業者はむしろ成長に繋がる業務量だと思っていることもある。依頼者は作業者の立場を考慮し、相手目線を忘れていない。
●「ブラック」
作業者は業務負荷が高すぎたり、無理なスケジュールで要求されていることに悲鳴をあげている状態にも関わらず、依頼者は「そこまで負荷が高いとは思っていない。無理を強いているつもりはない。」と、作業者のコンディションを気にかけることすらしない。依頼者は相手目線に立つことができず、常に自分目線。「無理を強いている状態」か否かは作業者が判断することであるにも関わらず、依頼者はそのことを理解できない。
o08usyu7231.hatenablog.com
高負荷の作業者にうつ病のような症状が出ているにも関わらず体調不良を訴えても上司が大ごととはとらえず、作業者の体調が更に悪化した事例あり。上司のマネジメントに問題あり。
o08usyu7231.hatenablog.com
依頼者においては、無意識に過負荷をかけてしまっているなら「無能」、意図的に過負荷をかけているのなら「悪質」、いずれにしても「ブラック」。
過重労働で作業者が体調不良によりドクターストップ
○「ホワイト」
マネジメントが十分行き届いており、そもそも発生したためしがない。予兆があれば十分に配慮。
●「ブラック」
ドクターストップを受けているにも関わらず、業務引き継ぎのために、作業者の上司は作業者を出社させる。作業者の健康より業務の引き継ぎの方が重要なのか？ また、上司のマネジメントが未熟であることに気付いていない。
o08usyu7231.hatenablog.com
他の開発現場経験者の受け入れ
○「ホワイト」
その人が持つ他の開発現場での経験やノウハウを吸い上げて有効に活用する。一方、開発現場、開発プロジェクト特有の内容については丁寧にフォローする。両者の切り分けがうまい。
●「ブラック」
自分達のやり方に従わせようとする。自分達にとって都合の良いように事を運び、主従関係を明確にしようとマウントするケースもある。
プロジェクトに不慣れな人に対する扱い
○「ホワイト」
その人が持つ他の開発現場での経験やノウハウを吸い上げて有効に活用する。一方、開発現場、開発プロジェクト特有の内容については丁寧にフォローする。両者の切り分けがうまい。
●「ブラック」
「不慣れ」と「スキル不足」を勘違いする。ある開発現場で優秀な実績を残した人が、他の場所へ移るとなかなか成果が出ないということがある。「慣れた人」が優秀な人材、「不慣れな人」をあまり出来が良くない人材と勘違いし、マウントを取る。
システム評価要員の作業状況
○「ホワイト」
十分余裕を持ったスケジュールで早い段階からテスト要員がプロジェクトに参画し、システム全般の理解、仕様把握作業等、前倒しで進める。不明点は早い段階で解決する。不明点の解決に時間を要する場合でも早い段階から着手しているためスケジュールに余裕があり、心理的余裕もあるため、かえって順調に進むことが多い。
●「ブラック」
いきなりテスト行程にメンバーを投入する。システムの仕様書も不備あり、仕様の理解も十分ではない。テスト作業中トラブルに遭遇したとき、テスト仕様書の不備なのか、要求仕様書の不備なのか、ソフトウェアの不具合なのか、テスト環境の問題なのか、テスト方法の問題なのか、テストで使用するツールの設定ファイルの問題なのか、わからない。トラブル解決に多大な工数を要し、とてつもない労力を費やす割には、プロジェクトの進捗はほとんどない。
使用するPCのスペックやネットワーク環境
○「ホワイト」
企業にもよるが、そこそこのスペックのPCを与えられ業務に支障なし。特定のツール等使用するときに限り、少し動作が重たくなるくらいだが、許容範囲。本来高スペックPCが与えられれば、更に業務効率が上がるという考え方を持っている。
●「ブラック」
低スペックPCを与えられ、作業中イライラする。ひどい場合は、サーバ上のエクセルファイルを開くだけで数分かかる。サーバ内のフォルダ一つ移動するだけで、数分かかる。更に、ネットワークも含め、PCトラブルが多いことも、共通の特徴として挙げられる。これが本当にIT企業なのかと呆れる。
ソフトウェア設計におけるレビュー指摘
○「ホワイト」
レビューアとレビューイが、事前に設計などすりあわせした上で作業を進めるため、あまり指摘件数が多くならない。指摘内容については重要な点をわかりやすく、作成者の意図を尊重しながら説明し、対応の方向性をすりあわせる。レビューを通してメンバーは成長していく。
●「ブラック」
レビューアはレビューイに対して、作業を丸投げしておきながら、重箱の隅をつつきマウントを取る。「普通はこうやるだろ・・・」の「普通」が勝手に出来上がっている。レビューを通してメンバーは嫌気がさす。
o08usyu7231.hatenablog.com
o08usyu7231.hatenablog.com
ソースコードの変更行数が数行
○「ホワイト」
ソースコードの変更行数が数行であっても、満たしたい機能に対して、「その変更箇所だけで良いのか？」「他に影響を与えることはないか？」など、様々な観点から設計検証をした結果、最終的にソースコードの変更行数が数行で済んだという位置付け。
ソースコードの変更作業だけなら、5分程度でできる作業でも、その変更で良いという結論に辿り着くまでの道のりは長く、数日レベルになることもある。
これらのことを、作業者、依頼者、上位者がしっかり理解している状態。
●「ブラック」
「ソースコード数行の変更にどれだけかかっているんだ！ 俺だったら5分でできるぞ！」と理不尽な言葉を浴びせる。ソースコードの変更作業にのみ着目し、そこに辿り着くまでのプロセスをまるごと見落とし。見落としにも関わらず、何も問題と思わないくらい無知もしくは理解のない人間が、プロジェクトの旗振りをしていることがあり、メンバーに迷惑がかかる。スケジュール見積りをこの感覚でやると、即長時間労働になる。
最後に
これらの比較結果を参考に、ブラックな予兆を確認できたならば、転職の準備をお薦めする。いざというとき、会社は労働者を守ってくれない。今の時代は転職が当たり前、無理して一つの会社に一生居る必要はない。自分の身は自分で守り、悔いのない人生を！
30代後半〜40代前半は、キャリアチェンジも容易ではなく、かつ家庭がある方が多く、自由度が低い、リスクが取りにくい、といったキャリアを築く上では、あまりに大きな課題を抱えています。RYOMEIのトレーナーも同じ世代であり、自身も子育てと仕事の両立に試行錯誤していたり、順風満帆にキャリアを築いているわけではないからこそ、受講者の痛みに共感しながら、一緒に考えていくことができます。
困難な状況にある方こそ、お勧めできるサービスです。是非、一歩踏み出し、人生を変えてみませんか？
