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

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

パワハラの定義と身近に起きたグレーゾーンを含む事例解説(18)

目次

f:id:o08Usyu7231:20210605173638p:plain

【最初に】パワハラの定義と6つの類型

パワハラはご存知の通り「パワーハラスメント」の略であり、権力や地位を利用した嫌がらせという意味である。2001年に株式会社クオレ・シー・キューブによる造語である。ただ、その定義は曖昧で指導との区別が困難である現実を抱えていた。2020年6月にパワハラ防止法が適用され(中小企業は2022年4月より適用)、同時に厚生労働省による定義が明確になった。

パワハラの定義とは、

職場において行われる
 ①優越的な関係を背景とした言動であって、
 ②業務上必要かつ相当な範囲を超えたものにより、
 ③労働者の就業環境が害されるものであり、

①から③までの3つの要素を全て満たすものをいう。
なお、客観的にみて、業務上必要かつ相当な範囲で行われる適正な業務指示や指導については、職場におけるパワーハラスメントには該当しない。

詳しくはこちらを見てほしい。
www.no-harassment.mhlw.go.jp

続いて、パワハラの6類型(パターン)を項目だけ紹介しておく。

 (1)身体的な攻撃
 (2)精神的な攻撃
 (3)人間関係からの切り離し
 (4)過大な要求
 (5)過小な要求
 (6)個の侵害

詳しくはこちらを見てほしい。
www.no-harassment.mhlw.go.jp

ニュースで取り上げられているものや、裁判になったものは組織内で解決できなかった手遅れ案件である。また、世間の目も段々厳しくなってきており、損害賠償の相場も数百万単位(被害者が死亡の場合は数千万単位)に上がってきているという情報もある。いくら正論であっても、相手が嫌がるやり方であれば、法律に触れることになる。
ただでさえニュースで見ることが多くなってきているのだが、これらは氷山の一角であり、水面下には程度の大小を問わずさらに多くの案件が潜んでいる。上述の定義や類型を基に、私が実際に見たことがある事例を紹介し、定義や類型を元に解説する。程度や被害の大小は様々である。

・グレーゾーンであるもの、パワハラと断言できないもの
・「こんなのがパワハラになるのか?」というもの
・出来事が起きた当時はあまり意識しなかったものの今考えると「あのときのあの出来事はもしかするとパワハラにあたるのでは?自分も加害者にならないように気を付けよう。」と思ったもの

いずれにしても、加害者側に問題があり是正が必要であることは間違いなく言えるので、立場関係なく参考にしていただきたい。その上でパワハラの予兆を見極め、未然防止に繋げることが重要てある。

★関連リンク
なくならない日本のパワハラ問題 - ソフトウェアエンジニアが労働について情報発信するブログ
★事例一覧はこちら↓
パワハラの定義と身近に起きたグレーゾーンを含む事例解説一覧 - ソフトウェアエンジニアが労働について情報発信するブログ

転職成功の秘訣は、サイトに公開されない求人にあった。

【退職代行ガーディアン】

【事例18】レビュー時に自分の価値観押し付け

多重下請け構造の中間搾取企業と末端企業でのシステム開発における、長時間のブラック労働となったプロジェクトでの事例である。多重下請け構造の問題点については別記事を読んでいただきたい。

★関連記事
o08usyu7231.hatenablog.com
o08usyu7231.hatenablog.com

ここでの登場人物は3名である。

A氏:パワハラ被害者、末端企業でソフトウェア開発
   大手メーカーで実績を挙げている優秀な人材
B氏:パワハラ傍観者、末端企業のプロジェクトリーダー
C氏:パワハラ加害者、末端企業に丸投げで業務委託している中間搾取企業の窓口社員


毎日22時までの長時間労働である開発現場で、C氏はB氏を経由してA氏へ、開発中のシステムに搭載する新機能の設計を依頼した。依頼内容は曖昧な要求程度で、細かい内容は丸投げ、手段については「そちらで考えてください」といった感じであった。長時間労働が常態化しているだけあって、この依頼の対応スケジュールは、まともな企業なら数ヶ月程度のものを、2~3週間という半端なく短いものだった。

それでもA氏は、派生開発のベースとなるソフトウェアを解析し、類似製品のソフトウェアを解析し、機能追加に必要な部分を適切にまとめ上げた。

A氏による設計が完了した時点で、B氏、C氏の三者でレビューを行った。設計の内容こそ問題ないものの、設計におけるアウトプット(成果物)が、B氏、C氏には気に入らなかったようだ。

レビュー時、C氏は
「普通は『○○』のやり方をしますよね。なぜ、『○○』のやり方ではないのですか?」
とA氏を問い詰めた。

A氏は、調査結果と派生開発におけるソフトウェアの変更内容をまとめ上げ、ソフトウェア変更に必要な情報は全て揃っている旨をC氏に報告した。即ち、手段については依頼元が想定していたものと異なるが、最終的に目的とする設計は出来ている状態であった。

しかし、それにも関わらずC氏はA氏に執拗に追加資料の作成を依頼し、A氏は余分な作業を強いられることとなった。

ここまでの内容を見ただけでは、パワハラであると思う人は少ないのではないだろうか。暴言は見受けられず、よくある業務上の依頼でしかないように見える。細部に気付く人なら、C氏がB氏経由でA氏に曖昧な要求で丸投げしておきながら、レビュー実施時点で初めて手段にまで踏み込み、A氏の作業方法に問題があるかのような論調で、執拗に余分な作業を強いる様子が伺える。
更に、決定的なのが、このやりとりと背景状況をセットで考えると、ブラック労働であることが確実にわかる。

・上記やりとりがあった月のA氏の残業時間は、ほぼ過労死レベルのものである。B氏はそれを上回る。
・B氏はC氏の言いなり。
・A氏のスキル不足ではないことが既にわかっている。A氏は優良企業やホワイト企業で実績を挙げている優秀か人材である。
・C氏の案件は、過去にも炎上しているとの情報がある。関係者からも呆れられている。
・C氏はA氏に対してのみならず、普段から下請け企業のエンジニアに対して高圧的である。自分の価値観を押し付けることがよくある。


これは、長時間のブラック労働とセットで発生するパワハラの典型である。発注者としての立場を利用し(①)、依頼時点では丸投げで作成された成果物が自身の意図と異なる場合でも、自分の非を認めず、作成者側に責任を押し付け、余分な作業を強いるという、業務に必要相当な範囲を超えた言動により(②)、就労環境を悪化させている(③)ことから、パワハラの定義を満たしている。6類型では、作成者側の責任であるかのような論調とする(2)「精神的な攻撃」、ただでさえ過重労働の状況で余分な作業を執拗に強いる(4)「過大な要求」が該当する。

C氏が改めなければならないのは以下の点だ。
・具体的な手段を指定したいなら、事前に成果物に関するすり合わせが必要である。
・別企業(ホワイト企業)では、このようなとき「想定していた成果物とは異なりますが、目的は満たしており、△△といった細部までこちらが指示しておりませんでしたので、この内容で問題なしとします。」として、A氏の作成した成果物を受け入れる。
・力関係を利用して、余分な作業を強要しない。
・過重労働が常態化している現実を認識し、立場や会社対会社の関係以前に、人間として相手を気遣う
・A氏がなぜこの成果物で問題ないとしているかを丁寧にヒアリングし、C氏自身がA氏から学ぶことがある可能性を加味し、紳士な態度でレビューに臨む

また、B氏においても傍観やC氏への同調ではリーダーとしてNGである。成果物に関する認識違いがないよう調整が必要であると同時に、C氏からの余分な作業指示によってA氏が迷惑を受けていることを認識し、改善措置を取るべきである。

最後に被害者A氏。余分な作業依頼は断ることだ。断るには勇気が必要だ。過重労働の被害に巻き込まれないためにも、ブラック労働やパワハラの予兆を早期に掴み、是正の要求は必要だが、いざというときは抜け出すことも必要だ。


パワハラとは関係ないが、C氏は派生開発プロセスにおいても致命的な過ちをしている。C氏の発言

「普通は『○○』のやり方をしますよね。なぜ、○○のやり方ではないのですか?」

において、『○○』は、

『派生開発であるため、ベースとする仕様書から変更となる部分を見つけ、そこを変更する。次に概略設計書の変更となる部分を見つけ、そこを変更する。次に詳細設計書の変更となる部分を見つけ、そこを変更する。そうすれば、プログラムコードの変更すべき箇所が自動的に見えるため、ここを変更する。』

というものだった。これは、『新規開発崩し』という派生開発プロセスでやってはいけないNG手法である。新規開発のウォーターフォールモデルをそのまま派生開発に当てはめているだけである。この方法では、設計書に記載されていない部分で変更が必要な箇所の変更漏れが発生したり、変更による影響の検討が不十分であったりすることが多い。即ち、ここでのC氏の指摘は間違っていたのである。派生開発に関する書籍やセミナー等で紹介されているが、A氏の方法が正解である。

仮にC氏が普通と考えている『○○』のやり方を追加作業としてA氏へ依頼し、A氏がこの『○○』の作業をしたことで、元々のA氏の設計に不備や漏れがあることが判明したならば、『○○』の作業をした甲斐があったと言える。しかし、『○○』の作業をすることによる不備や漏れは確認されなかった。設計に問題がないことの確認という意味では『○○』の作業は必要かもしれない。過重労働の状況で、投資対効果の低い作業は、A氏の設計には必要性が低く、C氏のレビューのための作業という印象が強い。

前述したように、派生開発において『新規開発崩し』はNGプロセスとされており、プロセスのミスマッチはソフトウェアの品質低下を招いたり、過重労働の温床となるリスクがある。この開発現場は既に過重労働の温床である。この状況で、C氏のように力関係を背景に、価値観を押し付け、他者の責任としている以上、労働環境が改善されることはない。

【最後に】パワハラにおける考え方・まとめ

パワハラは加害者が未熟であることによって発生する。パワハラに関して被害者には非はない。被害者に改めるべき部分があると思えば、改めることは素晴らしいことである。しかし、パワハラを受けたことに対する責任まで取る必要はない。

一方、パワハラ加害者は重い軽いいずれにしてもそれなりの処分と教育を受け、更正してほしい。パワハラの加害者を絶対に昇格させてはいけない。降格するくらいを当たり前にしてほしい。

パワハラ加害者となる可能性が高いリーダー、管理職には、パワハラの重大さを知ったうえで、チーム・組織で成果を最大化するために必要なことを学んでほしい。私は様々なリーダー、管理職を見てきた。技術や能力が高いベテラン社員はある程度いる。しかし、いくら能力が高くてもパワハラ気質なベテラン社員は、管理職にふさわしくないと判断している。組織のメンバーのパフォーマンスの最大化の妨げとなっているからである。チーム・組織で成果を最大化するためにパワハラはいらない。



そして被害者はパワハラを受けた状況にもかかわらず業務において一定のアウトプットを出しているなら、優秀な人材であると考えて良さそうだ。

パワハラがいけないことであるということは皆知っている。しかし、何がパワハラに当たるか、パワハラが発生したときにどのような影響が出るかを理解していないのではないだろうか。パワハラに関する研修や教育は行われているが、最悪命に関わるということを教えていないのではないだろうか。

本来被害者側に要求しなければならないことは社会的に非常に残念ではあり、理不尽ではあるが、パワハラ被害に遭う前から、転職、起業、フリーランス、副業など準備を進めておくことが、被害者個人でできる対策だろう。それくらい日本のハラスメント対策は国際的に見ても遅れている。











パワハラの定義と身近に起きたグレーゾーンを含む事例解説(17)

目次

f:id:o08Usyu7231:20210605173638p:plain

【最初に】パワハラの定義と6つの類型

パワハラはご存知の通り「パワーハラスメント」の略であり、権力や地位を利用した嫌がらせという意味である。2001年に株式会社クオレ・シー・キューブによる造語である。ただ、その定義は曖昧で指導との区別が困難である現実を抱えていた。2020年6月にパワハラ防止法が適用され(中小企業は2022年4月より適用)、同時に厚生労働省による定義が明確になった。

パワハラの定義とは、

職場において行われる
 ①優越的な関係を背景とした言動であって、
 ②業務上必要かつ相当な範囲を超えたものにより、
 ③労働者の就業環境が害されるものであり、

①から③までの3つの要素を全て満たすものをいう。
なお、客観的にみて、業務上必要かつ相当な範囲で行われる適正な業務指示や指導については、職場におけるパワーハラスメントには該当しない。

詳しくはこちらを見てほしい。
www.no-harassment.mhlw.go.jp

続いて、パワハラの6類型(パターン)を項目だけ紹介しておく。

 (1)身体的な攻撃
 (2)精神的な攻撃
 (3)人間関係からの切り離し
 (4)過大な要求
 (5)過小な要求
 (6)個の侵害

詳しくはこちらを見てほしい。
www.no-harassment.mhlw.go.jp

ニュースで取り上げられているものや、裁判になったものは組織内で解決できなかった手遅れ案件である。また、世間の目も段々厳しくなってきており、損害賠償の相場も数百万単位(被害者が死亡の場合は数千万単位)に上がってきているという情報もある。いくら正論であっても、相手が嫌がるやり方であれば、法律に触れることになる。
ただでさえニュースで見ることが多くなってきているのだが、これらは氷山の一角であり、水面下には程度の大小を問わずさらに多くの案件が潜んでいる。上述の定義や類型を基に、私が実際に見たことがある事例を紹介し、定義や類型を元に解説する。程度や被害の大小は様々である。

・グレーゾーンであるもの、パワハラと断言できないもの
・「こんなのがパワハラになるのか?」というもの
・出来事が起きた当時はあまり意識しなかったものの今考えると「あのときのあの出来事はもしかするとパワハラにあたるのでは?自分も加害者にならないように気を付けよう。」と思ったもの

いずれにしても、加害者側に問題があり是正が必要であることは間違いなく言えるので、立場関係なく参考にしていただきたい。その上でパワハラの予兆を見極め、未然防止に繋げることが重要てある。

★関連リンク
なくならない日本のパワハラ問題 - ソフトウェアエンジニアが労働について情報発信するブログ
★事例一覧はこちら↓
パワハラの定義と身近に起きたグレーゾーンを含む事例解説一覧 - ソフトウェアエンジニアが労働について情報発信するブログ

転職成功の秘訣は、サイトに公開されない求人にあった。

【退職代行ガーディアン】

【事例17】過重労働未然防止妨害

多重下請け構造の中間搾取企業と末端企業でのシステム開発における、長時間のブラック労働となったプロジェクトでの事例である。多重下請け構造の問題点については別記事を読んでいただきたい。

★関連記事
o08usyu7231.hatenablog.com
o08usyu7231.hatenablog.com

ここでの登場人物は3名である。

A氏:パワハラ被害者、末端企業でソフトウェア開発
   大手メーカーで実績を挙げている優秀な人材
B氏:パワハラ傍観者、末端企業のプロジェクトリーダー
C氏:パワハラ加害者、末端企業に丸投げで業務委託している中間搾取企業の窓口社員


毎日22時までの長時間労働である開発現場で、スケジュールに関するやりとりである。これを見てブラックだと見抜くことがでかるだろうか?

C氏:「○○の件、いつまでにできますか?」
A氏:「○○の作業には、多大な工数がかかります。」
C氏:「なぜ、そんなにかかるのですか?」
A氏:「××の作業が必要で、内容をよく調査しないといけないためです。影響の調査も必要です。」
C氏:「××はウチのソフトウェアはちゃんと出来ていると聞いていますので、そんなにかからないはずです。~~あればできるはずです。」
A氏:「そうは言っても、開発中は何が起きるかわかりません。ちゃんと出来ていると聞いていても、実際ちゃんと出来ていないことは多々あります。」
C氏:「設計書があるので、読めばわかります。」
A氏:「設計書を読んだだけではよくわからないことが多いです。短期間で読むには量が膨大すぎます。このシステムを熟知しており、このプロジェクトに慣れた人が、より詳細を思い出すのには良いかも知れませんが、初めて読んだ人がわかる設計書になっていません。」
C氏:「他の製品で実現しているソフトウェアを移植するだけです。持ってくるだけです。」
A氏:「移植するだけで本当に良いのか検証するのに時間がかかります。」
C氏:「で、なぜそんなにかかるのですか? 根拠を示してください。」
A氏:「C氏の案件はいつも予想外のことが発生しており、スケジュール感を信用できません。これまでの傾向を見れば明らかです。見ての通り毎日毎日この過重労働の状況であり、大変迷惑を受けております。この状況を理解できませんか? 余裕を持ったスケジュールが必要です。スケジュールを調整していただけませんか? 無理なスケジュールを押し付けるのはご遠慮いただきたいです。」
C氏:「無理を言っているつもりはありません。で、いつまでにできますか?」
・・・エンドレス・・・

このやりとりを見ただけでは、パワハラであると思う人は少ないのではないだろうか。暴言は見受けられず、よくある業務上の依頼でしかないように見える。細部に気付く人なら、C氏がA氏に対して執拗に迫り、問い詰めている様子が伺える。
更に、決定的なのが、このやりとりと背景状況をセットで考えると、ブラック労働であることが確実にわかる。

・上記やりとりがあった月のA氏の残業時間は、ほぼ過労死レベルのものである。B氏はそれを上回る。
・B氏はC氏の言いなり。
・この直前には、C氏は計画時点で「なぜ2日もかかるのですか?」とA氏に問い詰めたタスクが、実際には2週間要している。
・A氏のスキル不足ではないことが既にわかっている。A氏は優良企業やホワイト企業で実績を挙げている優秀な人材である。
・本プロジェクトは、A氏の作業のみが遅れているわけではなく、全体的に予定より遅れている。遅れているのではなくてスケジュールが短すぎる。
・本プロジェクトの背景状況として、A氏が言っていることが正しい。
・C氏の案件は、過去にも炎上しているとの情報がある。関係者からも呆れられている。

これは、長時間のブラック労働とセットで発生するパワハラの典型である。発注者としての立場を利用し(①)、プロジェクトを円滑に進めるためのコントロールではなく、短いスケジュールを約束させようと執拗に迫るという業務に必要相当な範囲を超えた言動により(②)、就労環境を悪化させている(③)ことから、パワハラの定義を満たしている。6類型では、発注者側から短いスケジュールで約束させるように執拗に迫る(2)「精神的な攻撃」、ただでさえ過重労働の状況で本来必要な工数を確保せず更に短いスケジュールでの完成を強要する(4)「過大な要求」が該当する。

C氏が改めなければならないのは以下の点だ。
・作業を依頼するときは相手目線で考える。「無理を言っているつもりはありません。」と言っているが、加害者側はそのつもりでも、この状況を許容できるか否かは、被害者が決めることである。「無理がどの程度祟っているか」を知るのは被害者である。
・自分は加害者であることを自覚する。
・他社の人間の労務管理はB氏が責任を持つのが普通である。とはいえビジネス以前に人間である以上、状況を知ろうとする姿勢が必要。スケジュール面のみならず、労務面も意識する。
・立場や力関係で被害者を問い詰めるのではなく、どうすればプロジェクト全体が円滑に進むかを考える。下請けに丸投げではなく、会社が異なれど協力して進めなければならない場面である。サポートする姿勢が必要。
・どうしてもスケジュール上急いでおり、A氏が示す見積りに納得いかないならば、自分で作業すれば済むことである。(しかし、実際には下請けに委託という表向きで作業しない。もしくは出来ない場合が多い。)
・A氏に依頼している作業が簡単と考えているのならば、自分で作業すれば良いことである。(しかし、実際には下請けに委託という表向きで作業しない。もしくは出来ない場合が多い。)
・A氏が気付いており、C氏自身が気付いていない問題点がある可能性を考慮し、A氏に寄り添って積極的にヒアリングを行う。
過重労働の未然防止を妨害する行為をやめる。
・「設計書があるから」「ソフトウェアを移植するだけ」のように、簡単と思わせて短いスケジュールを約束させようとする、詐欺商法と同一の行為をやめる
o08usyu7231.hatenablog.com


また、B氏においても傍観やC氏への同調ではリーダーとしてNGである。「無理な要求を受けない」というホワイト企業の姿勢を見習うべきである。同時に、C氏からの執拗な詰問によってA氏が迷惑を受けていることを認識し、改善措置を取るべきである。

最後に被害者A氏。過重労働の未然防止のため、毅然とした対応は良い。しかし、このような埒があかないケースでは、余裕のあるスケジュールの調整を要求するのではなく、断ることだ。断るには勇気が必要だ。被害に巻き込まれないためにも、ブラック労働やパワハラの予兆を早期に掴み、被害に遭っても決して泣き寝入りしないことだ。

【最後に】パワハラにおける考え方・まとめ

パワハラは加害者が未熟であることによって発生する。パワハラに関して被害者には非はない。被害者に改めるべき部分があると思えば、改めることは素晴らしいことである。しかし、パワハラを受けたことに対する責任まで取る必要はない。

一方、パワハラ加害者は重い軽いいずれにしてもそれなりの処分と教育を受け、更正してほしい。パワハラの加害者を絶対に昇格させてはいけない。降格するくらいを当たり前にしてほしい。

パワハラ加害者となる可能性が高いリーダー、管理職には、パワハラの重大さを知ったうえで、チーム・組織で成果を最大化するために必要なことを学んでほしい。私は様々なリーダー、管理職を見てきた。技術や能力が高いベテラン社員はある程度いる。しかし、いくら能力が高くてもパワハラ気質なベテラン社員は、管理職にふさわしくないと判断している。組織のメンバーのパフォーマンスの最大化の妨げとなっているからである。チーム・組織で成果を最大化するためにパワハラはいらない。


そして被害者はパワハラを受けた状況にもかかわらず業務において一定のアウトプットを出しているなら、優秀な人材であると考えて良さそうだ。

パワハラがいけないことであるということは皆知っている。しかし、何がパワハラに当たるか、パワハラが発生したときにどのような影響が出るかを理解していないのではないだろうか。パワハラに関する研修や教育は行われているが、最悪命に関わるということを教えていないのではないだろうか。

本来被害者側に要求しなければならないことは社会的に非常に残念ではあり、理不尽ではあるが、パワハラ被害に遭う前から、転職、起業、フリーランス、副業など準備を進めておくことが、被害者個人でできる対策だろう。それくらい日本のハラスメント対策は国際的に見ても遅れている。











エンジニアにおける派遣先・常駐先企業への転職

目次

f:id:o08Usyu7231:20210611200837j:plain

1.トラブルになりそうだが「職業選択の自由」がある

IT業界では、顧客企業へエンジニアを常駐させて業務を行う、「客先常駐」のスタイルが取られることがよくある。この「客先常駐」の中には、「請負」もあれば「派遣」もある。「派遣」契約の場合、常駐エンジニアを受け入れる企業の社員が、自社の社員と同じように、自社内で作業する常駐エンジニアに対して直接指揮命令することがある。

そして、「派遣先企業」と「常駐エンジニア」が合意すれば、「常駐エンジニア」が「派遣先企業」の正社員として働くこともありうる。「派遣元企業」にとっては、これまで「常駐エンジニア」として活躍してきた社員が、「派遣先企業」に引き抜かれた形となり気の毒であったり、「派遣元企業」と「派遣先企業」との間でトラブルになったりするのではないかと心配になる。「派遣先企業」も「派遣元企業」から何を言われるかわからないとビクビクしているというケースも多い。

しかし、この「常駐エンジニア」の正社員への「引き抜き」はよく行われているらしく、「引き抜き」と言えば聞こえは悪いが、法律としては全く問題ないどころか、職業選択の自由日本国憲法で保証されている。例えば、ある企業で「退職後、○年以内に○○に就職してはならない。」というように定めていると、これは「職業選択の自由」を不当に侵害している。

次に示すソフトウェア開発を行うメーカーにおいては、「常駐エンジニア」が「派遣先企業」へ転職(「派遣先企業」が「常駐エンジニア」を引き抜き)するケースもある。また、エンジニアのキャリアや意思を尊重する企業もある。

転職成功の秘訣は、サイトに公開されない求人にあった。

2.ソフトウェア開発を行うメーカーにおける事例

「常駐エンジニア」は正社員と比べて賃金が安く、また業務量が多いときに「常駐エンジニア」を投入し、業務量が少ないときは解約することができ、「派遣先企業」にとっては融通がきくようなイメージがある。定型作業や単純作業であればその通りかもしれないが、ソフトウェア開発のように専門性が求められている場合は事情が違うだろう。たた、「常駐エンジニア」を正社員として受け入れることについての考え方は、企業によって異なる。

ある企業は「常駐エンジニア」がどれだけ優秀な人材であっても、「派遣元企業」との間のトラブルを避けるために、一度「常駐エンジニア」として受け入れた人は正社員として採用しない方針を徹底している。

一方で、「常駐エンジニア」を正社員として受け入れている事例を複数持つ企業もある。その企業の開発現場の見解としては、次のようなものがある。

「ソフトウェア開発業務は専門性が必要。正社員であろうが、派遣エンジニアであろうが、技術は進歩するから常に教育が必要。しかし、派遣エンジニアはいつ派遣元企業の都合で引き上げられるかわからない。そのリスクを抱えながらソフトウェア技術者としての教育を続けても、投資に見合う効果が得られないこともある。よって、今後ソフトウェア開発部門から派遣エンジニアを廃止し、正社員のみとしたい。優秀な派遣エンジニアは本人の意思があるなら正社員として受け入れる方針としたい。」

私は、この見解は素晴らしいと思った。私なりに補足すると、この方法は、法律として問題ないどころか「職業選択の自由」に合致している。また、「派遣先企業」にとっても「常駐エンジニア」にとってもメリットがある。「派遣先企業」にとっては、新規のエンジニアを中途採用するケースと比べて「常駐エンジニア」の実績を直接見ることができ、スキルのミスマッチが起きにくい。「常駐エンジニア」にとっては、新規にエントリーする転職先企業と比べて「派遣先企業」の開発現場をわかっており、同様にスキルのミスマッチが起きにくい。普通にゼロから転職するよりもはるかに良いことの方が多い。また、「派遣先企業」から派遣エンジニアを廃止し正社員に統一することで、関わる企業数を減らし、ソフトウェア開発を進めるにあたって全メンバーに同じように教育を行い、一体感を醸成しやすいメリットがある。

doda

3.エンジニアの意思を尊重する企業も

「派遣先企業」が「常駐エンジニア」を正社員として引き抜くことは、「派遣元企業」との間でトラブルにならかねないとの心配がある。その通りだろう。「派遣元企業」からすれば、せっかく自社で育成したエンジニアが退職し、他の企業へ行ってしまうのだから、残念な気分になる。

しかし、逆にエンジニアの意思やキャリアを尊重する企業もあり、最初は「常駐エンジニア」で実績を積み、将来は大手メーカーへ転職というキャリアを尊重している。私が知る限りで代表的な例が、インテリジェンス(現:パーソルキャリア)社である。特徴的なのが、「人材派遣業」と「転職支援業」の両方を行っている企業だからである。形態は異なるにせよ、どちらも「人と仕事のマッチング」というビジネスには変わりない。

昔は終身雇用制で定年まで会社に務めるのが一般的だったが、今は終身雇用制は崩壊し、人材が流動的となった。更に、「組織」よりも「個」を重視する時代になった。これにマッチしたビジネスであると感じる。




4.結局キャリアを決めるのは個人次第

「引き抜き」というとネガティブなイメージがあるが、「常駐エンジニア」自身が「派遣先企業」へ転職したい、正社員になりたいという意向があるのなら、全く問題ないのではないかと思う。個人には「職業選択の自由」があるし「派遣元企業」がそれを阻止するのはおかしな話である。「派遣先企業」と「派遣元企業」でトラブルになるなど本来おかしな話だし、これを避けて「派遣先企業」のグループ企業へ転職するとか、それでも会社間でトラブルになるとか普通は考えられない。

今の時代、転職自体は誰でもありうることだし、転職は「転職先企業」と「転職希望者」のマッチングで成立するものである。「転職先企業」がたまたま「派遣先企業」だったというふうに考えてもおかしくないと思う。ここに「派遣元企業」が介入することは普通はない。

ソフトウェアエンジニアの中には、自分でソフトウェア設計やプログラミングをすることが好きで、年齢を重ねてもエンジニアとして現場の第一線で活躍したいという人もおり、マネージャー(管理職)になることを避けるために、あえて派遣という働き方を選ぶ人もいる。「派遣元企業」から「常駐エンジニア」が、(転職先が「派遣先企業」か全く別の企業かに関わらず)次々に転職していくということは、「派遣元企業」の労働条件・労働環境に問題を抱えており、転職先企業と比べて魅力が乏しい可能性が大であり、このような根本的な部分を改善していく必要があるのではないだろうか。

結局、キャリアを含めてその人の人生を決めるのはその人自身である。「派遣先企業」の正社員を目指すも良し、それ以外の転職先を探すも良し、「職業選択の自由」の基本に立ち返ろう。






「ホワイト」「ブラック」職場・労働一般分野徹底比較

f:id:o08Usyu7231:20210627174804j:plain
「ホワイト労働」「ブラック労働」の両方を経験した私が、両者を徹底比較してきた結果をお伝えする。かなりの違いがある印象を受けている。一個人が経験したことであるため、これから記載する内容が全てをカバーしているものではないし、中には主観的な部分もあることを了承願いたい。

以下、「表題」「ホワイト」「ブラック」の順に記載していく。「表題」の件について、「ホワイト」なケースと「ブラック」なケースについて、対比しながら言及していく。皆さんの職場環境がどのようなものか、見極めの参考にしてほしい。

「ホワイト」とは、「ホワイト企業」「優良企業」「ホワイトな開発現場(職場環境)」「ホワイトな人材」「ホワイトな考え方」「ホワイトな出来事」のいずれかを指す。
「ブラック」とは、「ブラック企業」「粗悪な企業」「ブラックな開発現場(職場環境)」「ブラックな人材」「ブラックな考え方」「ブラックな出来事」のいずれかを指す。

目次

視座

○「ホワイト」
社会目線。

●「ブラック」
会社目線。
o08usyu7231.hatenablog.com

過重労働で作業者が体調不良によりドクターストップ

○「ホワイト」
マネジメントが十分行き届いており、そもそも発生したためしがない。予兆があれば十分に配慮。

●「ブラック」
ドクターストップを受けて出社することができないにも関わらず、業務引き継ぎのために、作業者の上司は作業者を出社させる。作業者の健康より業務の引き継ぎの方が重要なのか? また、上司のマネジメントが未熟であることに気付いていない。
会社や上司へ連絡不要!【退職代行ガーディアン】

優秀な人材

○「ホワイト」
これまで優良企業で多々実績を出しており、他社へ行っても通用する、市場価値が高く、優れた人間性を持ち合わせている人材。

●「ブラック」
素直で協調性があり、上司に従順で、長時間労働パワハラ等の理不尽にも耐えることができ、低賃金で奴隷のように扱っても文句も言わず「成長のため」と前向きに捉えることができる、会社にとって都合の良い人材。
もしくは、ただ対象業務に長年従事しており、その領域に詳しいだけ。
o08usyu7231.hatenablog.com

残業時間の計上方法

○「ホワイト」
定時後、1分単位で残業時間が計上される。

●「ブラック」
定時後、最初の30分は休憩時間扱い。その後1時間経過時点で初めて1時間分が計上される。以降、30分単位で計上される。最初の1時間未満、以降の30分未満は切り捨て。例えば18時が終業なら、19時30分まで残業して初めて1時間分計上される。それ未満は計上されない。残金代は全額支払われるため一見合法に見えるが、例えば毎日19時20分まで残業しても全く残業代が支払われないなど抜け穴があり、違法。合法であるかのように見せかけて、じわじわと労働力を搾取する姑息な方法。
尚、ニュースや裁判等で表向きになっている、「残業代未払い」問題については明らかに違法であり論外。
転職で、サイトに掲載されていない【非公開求人】を活用する方法とは?

「会社対会社の関係を考えろ!」と言う目的

○「ホワイト」
問題や悪事の発生により、迷惑をかけてしまう範囲が、チーム内、部門内、他部門、取引先・顧客等の社外、エンドユーザーと広がるほど、影響が大きいこと認識させるために使う。

●「ブラック」
他社の人間から受けた理不尽な要求やパワハラに対して、被害者が被害を訴えるも、「相手はお客様だから」と立場や力関係を表に出し、会社間の取引を優先することのみを考え、被害者を黙らせるために使う。
低費用で確実な退職代行【退職代行ガーディアン】

「自己中心的」の意味

○「ホワイト」
本来の正しい意味を認識している。

●「ブラック」
「自己を犠牲にしない」ことを「自己中心的」と称する。前者は「普段は組織全体のために一生懸命尽力するが、自分を犠牲にしてまでは行わない」という意味。後者は「他人や組織全体を犠牲にしてでも自分の利益を追求するという、自分さえ良ければその他のことは無関心」という意味。この二つは全く別の意味であるのに、そのことを理解していない。
転職サイトに掲載されていない【非公開求人】の紹介を受ける方法は?

全体最適」の意味

○「ホワイト」
全体最適とは、企業や組織、またはシステム全体が最適化された状態を示す経営用語のひとつ。
組織にとって最適な落としどころを見つけ、そこに向かっていくことをさす。一部の人や部門にとっては最適ではないこともあるが、一部の人や部門に犠牲を強いて実現するものではない。また、異なる複数の立場においてWin-Winの関係であると言っても良い。

●「ブラック」
個人を犠牲にしてでも全体のために尽くすことを強要する体質。個人を犠牲にするのは、企業イメージの悪化、法的リスク、損害賠償のリスク、優秀な人材の流出など、多くのリスクを背負うことになる「全体最悪」であり、「全体最適」とは全く別物。
メディア掲載実績多数!【退職代行ガーディアン】

成長

○「ホワイト」
職務で必要な技術や知識を身に付けることで、これまでできなかったことができるようになること。また、人間としての倫理観が高まること。この2つを兼ね備え、社会に貢献できるようになること。

●「ブラック」
自組織に馴染み、どんなに困難なことや理不尽なことにも文句を言わず、組織にとって都合の良い人材になり、会社に貢献すること。



昇進する人材

○「ホワイト」
企業の問題点をいち早く発見し、周囲を巻き込んで改善に向けて行動した人。かつ、リーダーとしての素養や人間性を備え、周囲からの信頼を得られる人。

●「ブラック」
家庭を顧みず、長時間労働に耐えた者。組織に従順な者。パワハラ加害者。周囲のメンバーからはどのように思われていても、企業にとって都合の良い人材。
o08usyu7231.hatenablog.com

「信頼関係」

○「ホワイト」
異なる複数の立場においてWin-Winの関係。お互い相手を尊重し、同じ目的に対して、異なる立場であっても協力関係を築ける間柄。

●「ブラック」
依頼元が依頼先を一方的に従え、力関係を背景に都合良く使い潰す「主従関係」もしくは「従属関係」のことを「信頼関係」と呼ぶ。依頼元は依頼先のことを「信頼」していても、依頼先は依頼元のことを「信頼」していないケースが多い。
o08usyu7231.hatenablog.com

最後に

これらの比較結果を参考に、ブラックな予兆を確認できたならば、転職の準備をお薦めする。いざというとき、会社は労働者を守ってくれない。今の時代は転職が当たり前、無理して一つの会社に一生居る必要はない。自分の身は自分で守り、悔いのない人生を!






「ホワイト」「ブラック」ソフトウェア開発現場徹底比較

f:id:o08Usyu7231:20210627174804j:plain
「ホワイト労働」「ブラック労働」の両方を経験した私が、両者を徹底比較してきた結果をお伝えする。かなりの違いがある印象を受けている。一個人が経験したことであるため、これから記載する内容が全てをカバーしているものではないし、中には主観的な部分もあることを了承願いたい。

以下、「表題」「ホワイト」「ブラック」の順に記載していく。「表題」の件について、「ホワイト」なケースと「ブラック」なケースについて、対比しながら言及していく。皆さんの職場環境がどのようなものか、見極めの参考にしてほしい。

「ホワイト」とは、「ホワイト企業」「優良企業」「ホワイトな開発現場(職場環境)」「ホワイトな人材」「ホワイトな考え方」「ホワイトな出来事」のいずれかを指す。
「ブラック」とは、「ブラック企業」「粗悪な企業」「ブラックな開発現場(職場環境)」「ブラックな人材」「ブラックな考え方」「ブラックな出来事」のいずれかを指す。


目次

見積り・スケジュール

○「ホワイト」
残業しないことを前提としたスケジュールを設定する。トラブルが起きるリスクも考慮し、スケジュールにはバッファを持たせておく。作業工数が読めない場合は、長めに設定するか、読めない旨を説明しスケジュール調整を要請する可能性がある旨を伝えておく。長時間労働の未然防止のためにあらゆる手段を尽くし、開発要員に負担をかけないように最大限配慮する。

●「ブラック」
余裕を持ったスケジュールを設定しようとすれば、「なぜそんなにかかるのか。○日あれば十分だろう。」と詰問される。特に、要求側は「根拠を説明してほしい。」と迫ってくるが、根拠の説明は建前であり、本音は短いスケジュールを約束させたい意図があるため、根拠を説明しても理解できるだけの能力や姿勢に欠けており、何を説明しても時間の無駄でしかない。結局力関係を背景に、短い日程での完成を約束させられる。(パワハラ6類型の「過大な要求」に該当する可能性がある。) また、その執拗さが半端なく異常。長時間労働の未然防止を試みるも、それを妨害しようとする。ハラスメントにあたるので、このような依頼はお断りするのが正解。

派生開発におけるベース製品の仕様書・設計書

○「ホワイト」
仕様書・設計書が完璧で全く滞りなくスムーズに理解できるケースの方が少ない。時々、ベース製品のソースコードの方が新しく仕様書・設計書が一部最新の状態に更新されていないことがある。ある程度の情報はあるため、ソースコードと合わせて、不明点を有識者の協力を得ながら解決することで理解が進んでいく。また、ある程度理解するまで時間がかかることをあらかじめ想定している。

●「ブラック」
ある程度の情報はあるものの、その仕様書・設計書を読んで理解できるだけの前提知識がない状態で、依頼者はドキュメントだけを丸投げし、「読めばわかる」の一言を言い放つ。ドキュメントに不備があっても、作業者がスムーズに理解が進まないと、あたかも作業者がスキル不足であるかのような扱いをする。
仕様書・設計書には、前提知識がわかる人が読めば、更に詳細を思い出せる程度の情報はあるが、前提知識のない人が読んでも理解できるドキュメントになっていない。依頼者はそのことに気付かない。
doda

派生開発プロセス

○「ホワイト」
派生開発特有の難しさを理解しており、派生開発プロセスについて学び、プロセスの見直しが行われている。

●「ブラック」
派生開発特有の難しさを理解しておらず、新規開発と同じプロセスでやろうとする。これを「新規開発崩し」という。

他製品からの仕様横展開、他製品からのソフトウェア移植

○「ホワイト」
他製品からの移植といえども、ソフトウェアをそのまま移植できる場合とできない場合があること、移植だけで移植先の製品の品質が担保できるかどうかを考える姿勢、移植か否かによらない設計・検証の観点やノウハウを備えている。移植といえども誤りやすい点を理解しており、移植だからといって気を抜かない。

●「ブラック」
依頼者は作業者に対して「移植するだけ」「持ってくるだけ」「簡単」「○日あれば余裕でできる」などと、いかにも簡単に実現できるかのような印象操作をしておき、短いスケジュールでの完成を約束させようとする。また、その執拗さが半端なく異常。詐欺商法の手口と全く同じ。



作業者が多忙で業務負荷が高い

○「ホワイト」
依頼者が作業者に対して、「様々な業務を依頼しているため、業務負荷が高くなり申し訳ない」と思っている。しかし、作業者は忙しいにしても「申し訳ない」と思われる程負荷が高いとは思っていない。作業者はむしろ成長に繋がる業務量だと思っていることもある。依頼者は作業者の立場を考慮し、相手目線を忘れていない。

●「ブラック」
作業者は業務負荷が高すぎたり、無理なスケジュールで要求されていることに悲鳴をあげている状態にも関わらず、依頼者は「そこまで負荷が高いとは思っていない。無理を強いているつもりはない。」と、作業者のコンディションを気にかけることすらしない。依頼者は相手目線に立つことができず、常に自分目線。「無理を強いている状態」か否かは作業者が判断することであるにも関わらず、依頼者はそのことを理解できない。
高負荷の作業者にうつ病のような症状が出ているにも関わらず体調不良を訴えても上司が大ごととはとらえず、作業者の体調が更に悪化した事例あり。上司のマネジメントに問題あり。
依頼者においては、無意識に過負荷をかけてしまっているなら「無能」、意図的に過負荷をかけているのなら「悪質」、いずれにしても「ブラック」。
Webエンジニアの転職なら【転職ドラフト】


過重労働で作業者が体調不良によりドクターストップ

○「ホワイト」
マネジメントが十分行き届いており、そもそも発生したためしがない。予兆があれば十分に配慮。

●「ブラック」
ドクターストップを受けているにも関わらず、業務引き継ぎのために、作業者の上司は作業者を出社させる。作業者の健康より業務の引き継ぎの方が重要なのか? また、上司のマネジメントが未熟であることに気付いていない。

他の開発現場経験者の受け入れ

○「ホワイト」
その人が持つ他の開発現場での経験やノウハウを吸い上げて有効に活用する。一方、開発現場、開発プロジェクト特有の内容については丁寧にフォローする。両者の切り分けがうまい。

●「ブラック」
自分達のやり方に従わせようとする。自分達にとって都合の良いように事を運び、主従関係を明確にしようと、マウントするケースもある。

プロジェクトに不慣れな人に対する扱い

○「ホワイト」
その人が持つ他の開発現場での経験やノウハウを吸い上げて有効に活用する。一方、開発現場、開発プロジェクト特有の内容については丁寧にフォローする。両者の切り分けがうまい。

●「ブラック」
「不慣れ」と「スキル不足」を勘違いする。ある開発現場で優秀な実績を残した人が、他の場所へ移るとなかなか成果が出ないということがある。「慣れた人」が優秀な人材、「不慣れな人」をあまり出来が良くない人材と勘違いし、マウントを取る。
転職で、サイトに掲載されていない【非公開求人】を活用する方法とは?

システム評価要員の作業状況

○「ホワイト」
十分余裕を持ったスケジュールで早い段階からテスト要員がプロジェクトに参画し、システム全般の理解、仕様把握作業等、前倒しで進める。不明点は早い段階で解決する。不明点の解決に時間を要する場合でも早い段階から着手しているためスケジュールに余裕があり、心理的余裕もあるため、かえって順調に進むことが多い。

●「ブラック」
いきなりテスト行程にメンバーを投入する。システムの仕様書も不備あり、仕様の理解も十分ではない。テスト作業中トラブルに遭遇したとき、テスト仕様書の不備なのか、要求仕様書の不備なのか、ソフトウェアの不具合なのか、テスト環境の問題なのか、テスト方法の問題なのか、テストで使用するツールの設定ファイルの問題なのか、わからない。トラブル解決に多大な工数を要し、とてつもない労力を費やす割には、プロジェクトの進捗はほとんどない。
年収UP率93.8% / 平均年収UP額126万円のエンジニア転職サイト【転職ドラフト】

使用するPCのスペックやネットワーク環境

○「ホワイト」
企業にもよるが、そこそこのスペックのPCを与えられ業務に支障なし。特定のツール等使用するときに限り、少し動作が重たくなるくらいだが、許容範囲。本来高スペックPCが与えられれば、更に業務効率が上がるという考え方を持っている。

●「ブラック」
低スペックPCを与えられ、作業中イライラする。ひどい場合は、サーバ上のエクセルファイルを開くだけで数分かかる。サーバ内のフォルダ一つ移動するだけで、数分かかる。更に、ネットワークも含め、PCトラブルが多いことも、共通の特徴として挙げられる。これが本当にIT企業なのかと呆れる。
メディア掲載実績多数!【退職代行ガーディアン】

ソフトウェア設計におけるレビュー指摘

○「ホワイト」
レビューアとレビューイが、事前に設計などすりあわせした上で作業を進めるため、あまり指摘件数が多くならない。指摘内容については重要な点をわかりやすく、作成者の意図を尊重しながら説明し、対応の方向性をすりあわせる。レビューを通してメンバーは成長していく。

●「ブラック」
レビューアはレビューイに対して、作業を丸投げしておきながら、重箱の隅をつつきマウントを取る。「普通はこうやるだろ・・・」の「普通」が勝手に出来上がっている。レビューを通してメンバーは嫌気がさす。

ソースコードの変更行数が数行

○「ホワイト」
ソースコードの変更行数が数行であっても、満たしたい機能に対して、「その変更箇所だけで良いのか?」「他に影響を与えることはないか?」など、様々な観点から設計検証をした結果、最終的にソースコードの変更行数が数行で済んだという位置付け。
ソースコードの変更作業だけなら、5分程度でできる作業でも、その変更で良いという結論に辿り着くまでの道のりは長く、数日レベルになることもある。
これらのことを、作業者、依頼者、上位者がしっかり理解している状態。

●「ブラック」
ソースコード数行の変更にどれだけかかっているんだ! 俺だったら5分でできるぞ!」と理不尽な言葉を浴びせる。ソースコードの変更作業にのみ着目し、そこに辿り着くまでのプロセスをまるごと見落とし。見落としにも関わらず、何も問題と思わないくらい無知もしくは理解のない人間が、プロジェクトの旗振りをしていることがあり、メンバーに迷惑がかかる。スケジュール見積りをこの感覚でやると、即長時間労働になる。

最後に

これらの比較結果を参考に、ブラックな予兆を確認できたならば、転職の準備をお薦めする。いざというとき、会社は労働者を守ってくれない。今の時代は転職が当たり前、無理して一つの会社に一生居る必要はない。自分の身は自分で守り、悔いのない人生を!





パワハラの定義と身近に起きたグレーゾーンを含む事例解説(16)

目次

f:id:o08Usyu7231:20210605173638p:plain

【最初に】パワハラの定義と6つの類型

パワハラはご存知の通り「パワーハラスメント」の略であり、権力や地位を利用した嫌がらせという意味である。2001年に株式会社クオレ・シー・キューブによる造語である。ただ、その定義は曖昧で指導との区別が困難である現実を抱えていた。2020年6月にパワハラ防止法が適用され(中小企業は2022年4月より適用)、同時に厚生労働省による定義が明確になった。

パワハラの定義とは、

職場において行われる
 ①優越的な関係を背景とした言動であって、
 ②業務上必要かつ相当な範囲を超えたものにより、
 ③労働者の就業環境が害されるものであり、

①から③までの3つの要素を全て満たすものをいう。
なお、客観的にみて、業務上必要かつ相当な範囲で行われる適正な業務指示や指導については、職場におけるパワーハラスメントには該当しない。

詳しくはこちらを見てほしい。
www.no-harassment.mhlw.go.jp

続いて、パワハラの6類型(パターン)を項目だけ紹介しておく。

 (1)身体的な攻撃
 (2)精神的な攻撃
 (3)人間関係からの切り離し
 (4)過大な要求
 (5)過小な要求
 (6)個の侵害

詳しくはこちらを見てほしい。
www.no-harassment.mhlw.go.jp

ニュースで取り上げられているものや、裁判になったものは組織内で解決できなかった手遅れ案件である。また、世間の目も段々厳しくなってきており、損害賠償の相場も数百万単位(被害者が死亡の場合は数千万単位)に上がってきているという情報もある。いくら正論であっても、相手が嫌がるやり方であれば、法律に触れることになる。
ただでさえニュースで見ることが多くなってきているのだが、これらは氷山の一角であり、水面下には程度の大小を問わずさらに多くの案件が潜んでいる。上述の定義や類型を基に、私が実際に見たことがある事例を紹介し、定義や類型を元に解説する。程度や被害の大小は様々である。

・グレーゾーンであるもの、パワハラと断言できないもの
・「こんなのがパワハラになるのか?」というもの
・出来事が起きた当時はあまり意識しなかったものの今考えると「あのときのあの出来事はもしかするとパワハラにあたるのでは?自分も加害者にならないように気を付けよう。」と思ったもの

いずれにしても、加害者側に問題があり是正が必要であることは間違いなく言えるので、立場関係なく参考にしていただきたい。その上でパワハラの予兆を見極め、未然防止に繋げることが重要てある。

★関連リンク
なくならない日本のパワハラ問題 - ソフトウェアエンジニアが労働について情報発信するブログ
★事例一覧はこちら↓
パワハラの定義と身近に起きたグレーゾーンを含む事例解説一覧 - ソフトウェアエンジニアが労働について情報発信するブログ

転職成功の秘訣は、サイトに公開されない求人にあった。

【退職代行ガーディアン】

【事例16】隠蔽体質強要の疑い?

もう何年も前の、あるIT企業における話だ。社内の「ある活動」について、前年度までは「自己啓発」として取り組み、会社としてこの活動の状況や工数を管理することはしなかった。

今年度からはトップの方針により「業務」として取り組み、会社としてこの活動を予算化し、状況や工数を管理するようになった。

この活動に取り組むメンバーの中には、本当に好きで熱心に取り組み、自宅に持って帰って作業するメンバーもいた。

そして、今年度から「業務」として行う活動なのに、自宅に持ち帰って作業することに対して、「業務を自宅に持ち帰って行うことは、労務管理の面でも、コンプライアンスの面でも、セキュリティの面でも問題がある。」と、上層部から問題視されていた。そして、この活動の責任者は、上層部から「持ち帰り作業禁止」を指示された。

昨年までは、「自己啓発」として行われていた活動であったために、活動に熱心なメンバーが自宅に持って帰って作業しても何も問題にならなかったのである。

ここで大きく二つの意見がある。
一つは、(A)上層部の指示通り、「業務」として実施するなら会社で行うべきであるという意見である。
もう一つは、(B)活動に熱心なメンバーのモチベーションを落としてしまうことになるのではないかという意見である。

上層部から「持ち帰り作業禁止」を指示されたこの活動の責任者は、その指示に従い、この活動のメンバー全員にメールで指示内容と理由を展開した。

活動熱心なメンバーはこれに従い、自宅作業をやめ、この活動の作業を会社内で行うようになった。しかし、責任者がメールでの展開から数日後、他のメンバーの一人が(加害者)か、責任者(被害者)に対して周囲に聞こえる声で次のように言った。

「ああいうことメールに書くなよ。口頭で言えよ。」

加害者は過去にこの活動の責任者も含めて長年メンバーであり、被害者よりも経験が多い。被害者は加害者の言うことが理解できなかった。少なくとも、メールに書いた内容が残るということを嫌がっていたようだ。何か裏がある。。。

別にメールに書いてはいけないことを書いたわけでもないし、メールに残ってまずいような内容でもないのだが、加害者からすると何か後ろめたいことがあるに違いない。問題の根本を解決せず、都合の悪いことだけを伏せさせようとするのは、隠蔽体質の強要だ。

①この活動の経験が長いという優越的な立場を活かし、②本来解決すべき内容についての議論ではなく、都合の悪いことを書くなという謎の圧力をかけ、③被害者に疑念を持たせてしまう、というものである。

「この活動の自宅での作業を許容してやれ」というものだろうか? 口頭だと良くてメールだとダメな内容は、全く無くはないが、少なくともメールや文章に残されて嫌がられる内容は、まず何かを隠蔽しようとしている可能性を疑うべきである。

本来この問題で議論しなければならないのは、この活動を「業務」として行うならば、(A)上層部の指示に従い、工数管理して会社内での作業を義務付ける。もしくは、(B)活動熱心なメンバーにおける自宅での作業を許容するなら、「自己啓発」の位置付けに戻すよう再度検討しなおすかのいずれかである。

「業務」として実施するが、持ち帰り作業を許容するような抜け道を探そうとするから、責任者が正しい行いをしても拒絶反応をしてしまうのではないだろうか? このようなグレーゾーンはホワイトにしたいし、本例の加害者のような行為は普通の企業では起きないはずである。

【最後に】パワハラにおける考え方・まとめ

パワハラは加害者が未熟であることによって発生する。パワハラに関して被害者には非はない。被害者に改めるべき部分があると思えば、改めることは素晴らしいことである。しかし、パワハラを受けたことに対する責任まで取る必要はない。

一方、パワハラ加害者は重い軽いいずれにしてもそれなりの処分と教育を受け、更正してほしい。パワハラの加害者を絶対に昇格させてはいけない。降格するくらいを当たり前にしてほしい。
パワハラ加害者となる可能性が高いリーダー、管理職には、パワハラの重大さを知ったうえで、チーム・組織で成果を最大化するために必要なことを学んでほしい。私は様々なリーダー、管理職を見てきた。技術や能力が高いベテラン社員はある程度いる。しかし、いくら能力が高くてもパワハラ気質なベテラン社員は、管理職にふさわしくないと判断している。組織のメンバーのパフォーマンスの最大化の妨げとなっているからである。チーム・組織で成果を最大化するためにパワハラはいらない。



そして被害者はパワハラを受けた状況にもかかわらず業務において一定のアウトプットを出しているなら、優秀な人材であると考えて良さそうだ。

パワハラがいけないことであるということは皆知っている。しかし、何がパワハラに当たるか、パワハラが発生したときにどのような影響が出るかを理解していないのではないだろうか。パワハラに関する研修や教育は行われているが、最悪命に関わるということを教えていないのではないだろうか。

本来被害者側に要求しなければならないことは社会的に非常に残念ではあり、理不尽ではあるが、パワハラ被害に遭う前から、転職、起業、フリーランス、副業など準備を進めておくことが、被害者個人でできる対策だろう。それくらい日本のハラスメント対策は国際的に見ても遅れている。











ソフトウェア不具合が無いことを証明せよというのはパワハラである

f:id:o08Usyu7231:20210611202101j:plain
目次






1.ソフトウェアのテストとは

ソフトウェアに不具合が無いことは示せない。ソフトウェアに不具合があることは示せる。テストとは、不具合があることを証明するために行うものである。

JSTQB (日本ソフトウェアテスト資格認定委員会)が定めるソフトウェアテストの7原則」というものがある。本記事に関係のある2つだけ紹介する。

【原則1】テストは欠陥があることしか示せない
【原則2】全数テストは不可能

「あること」「起きること」を証明するのには1例をあげればいいだけである。しかし、「ないこと」「おきないこと」を証明するためには世の中すべてを調べないといけないので極めて困難である。なので、議論の場合には、まず「ある」という主張を先に証明することが現実的だ。「ない」ことを証明できないからといって「ある」とは言えないだろう。

無罪であることの証明、というのはとても難しい。すべての行動を明らかにしないといけないからだ。だからと言って「無罪であることを証明できないならあなたは有罪です」とはならない。有罪にする場合には、有罪であることを証明しないといない。

ソフトウェアテストや検証において現実的なのは、

「合意した確認範囲とテストケースにおいて、ユーザーに影響を与えるようなバグは見つかりませんでした。」
「これだけのテストを実施し、その限りにおいては、問題となる動作は確認されませんでした。」

という程度である。ソフトウェアに無知な顧客や組織内上層部から、「不具合はもうないよね!?」 「不具合がないことを証明しろ」と力関係を背景に詰め寄られても、「もう不具合はないです!」とは言えないのである。

ソフトウェア開発現場の管理職や上位者で「不具合がないことを証明しろ。それまでは帰れない。」と言うと、その人はソフトウェアの素人であると考えて良さそうだ。「ソフトウェアに不具合がないことは証明できない」のである。
年収UP率93.8% / 平均年収UP額126万円のエンジニア転職サイト【転職ドラフト】

2.パワハラの定義と類型

パワハラ厚生労働省の定義によると、
 ①優越的な関係を背景とした言動であって、
 ②業務上必要かつ相当な範囲を超えたものにより、
 ③労働者の就業環境が害されるものであり、
①から③までの3つの要素を全て満たすものをいう。
なお、客観的にみて、業務上必要かつ相当な範囲で行われる適正な業務指示や指導については、職場におけるパワーハラスメントには該当しない。

詳しくはこちらを見てほしい。
https://www.no-harassment.mhlw.go.jp/foundation/definition/about

続いて、パワハラの6類型(パターン)を項目だけ紹介しておく。

 (1)身体的な攻撃
 (2)精神的な攻撃
 (3)人間関係からの切り離し
 (4)過大な要求
 (5)過小な要求
 (6)個の侵害

詳しくはこちらを見てほしい。
https://www.no-harassment.mhlw.go.jp/foundation/pawahara-six-types/

パワハラの定義と類型については、以上のように説明されている。しかし、現実には皆が皆、これらを理解していないし、色々なところでパワハラが発生している。パワハラ発生とまではいかなくとも、グレーゾーン、パワハラ体質といった状況がよくある。

顧客や組織の上層部から力関係を背景に詰め寄られ、職場のモチベーションがダウンしたり、パワハラ体質や長時間労働で従業員が疲弊したり、心身に不調をきたし、優秀な人材の離脱、最悪の場合過労死や過労自殺が起きてしまう。第3者から見ると、なぜここまでしなければならないのかと思うが、当事者たちはなぜか頑張ってしまう。
Webエンジニアの転職なら【レバテックキャリア】

3.なぜ「ソフトウェアに不具合が無いことを証明せよ」というのはパワハラなのか?

ここまで、「ソフトウェアのテスト」と「パワハラの定義と類型」について記載してきた。この2つを組み合わせればおのずと答えは出てくるだろう。

繰り返すが、「ソフトウェアに不具合がないことは証明できない」のである。JSTQBが定める「ソフトウェアテストの7原則」の2つは、

【原則1】テストは欠陥があることしか示せない
【原則2】全数テストは不可能

である。

次に、パワハラの定義の3条件。
①優越的な関係を背景とした言動
②業務上必要かつ相当な範囲を超えたもの
③労働者の就業環境が害されるもの

6類型な中から関連する2つ。
(2)精神的な攻撃
(4)過大な要求

ソフトウェアに無知な顧客や組織内上層部から、「不具合がないことを証明しろ」と力関係を背景(①)に詰め寄られ、「ソフトウェアに不具合がないことは証明できない」(【原則1】【原則2】)にも関わらず、これを要求される(②)。その結果、職場のモチベーションがダウンしたり、パワハラ体質や長時間労働で従業員が疲弊したり、心身に不調をきたし、優秀な人材の離脱、最悪の場合過労死や過労自殺が起きてしまう(③)。

従業員に対して心理的に圧迫させ、「緊張感を持たせる」と謳いながら、「恐怖感でコントロール」している「精神的な攻撃」(2)となり、「過大な要求」(4)どころか不可能な要求である。

ソフトウェアテストの7原則」と「パワハラの定義・類型」を照らし合わせると、ぴったり上記のことが言えてしまうのではないかと思うのである。

本記事では「ソフトウェアテスト」について述べたが、ソフトウェア開発は簡単なものではない。管理職や上層部は「ソフトウェアについての理解」と「パワハラについての理解」の両方が求められる

一方、ソフトウェアエンジニアは「ソフトウェアについての理解」と「パワハラについての理解」の両方が出来ている企業へ就職、転職した方が良いことは間違いない。






下記、関連記事も参考にしてほしい。
o08usyu7231.hatenablog.com
o08usyu7231.hatenablog.com

「長時間労働」「過重労働」「デスマーチ」「ブラック労働」、言葉の使い分け

f:id:o08Usyu7231:20210628164114j:plain
長時間労働」「過重労働」「デスマーチ」「ブラック労働」、言葉の使い分けについて調べてみた。これらの言葉はIT業界における過酷な労働実態を表すイメージがあるが、IT業界に関わらず社会問題という共通点がある。どれもネガティブなイメージを与えるものの、これまでこれらの言葉をあまり厳密に意識して使い分けることがなかったため、どのように使い分けるべきか調べることにした。
目次






1.各々の説明

まずは、各々の言葉の意味を簡単に書き並べてみた。

長時間労働

長時間労働とは、文字通り労働時間が本来予定されている時間数と比較して特に長い状態を指す。日々残業まみれの状態。

日本では、具体的にどのくらいの時間数を超えれば「長時間労働」にあてはまるかの明確な定義はない。しかし、おおむね以下の指標を目安として、数段階に分けられる。

・月45時間以上の時間外労働
・月60時間以上の時間外労働
・月80時間以上の時間外労働
・月100時間以上の時間外労働

原則として三六協定による労働時間の延長の上限が月45時間となっている。時間外労働月45時間が一つの基準となる。月60時間以上の時間外労働となると、割増賃金の割増率が引き上げられる。月80時間以上の時間外労働は、いわゆる過労死ラインと呼ばれる。脳・心臓疾患の場合、発症前直近の2~6ヶ月間の平均で80時間を超える時間外労働をしている場合には、その業務と発症の関連性が強いと判断され、労働基準監督署が業務災害を認定する可能性が高くなる。月100時間以上の時間外労働については、脳・心臓疾患の発症前月に100時間を超える時間外労働をしていた場合、その業務と発症の関連性が強いと判定され、労働基準監督署が業務災害を認定する可能性が高くなる。

「過重労働」

過重労働とは長時間労働等により、労働者に身体的・精神的に過重な負荷を負わせる労働・業務形態をいう。不規則な勤務や頻繁な出張もこれに含まれる。長期間にわたる疲労の蓄積やストレスには脳疾患や心臓疾患、精神疾患を招く。また、過重労働が原因の疾患による病死や自殺は過労死と呼ばれる。
ただし、疾病と過重労働の関連性は、労働時間だけでなく職場でのポジションや業務内容等も吟味されたうえで判断される。

デスマーチ

デスマーチ とは、プロジェクトにおいて過酷な労働状況をいう。ソフトウェア産業に限らず、コンピュータが関係する一般的なプロジェクト全般で使われるようになってきており、特に納期直前等の状態が破綻寸前で、関係者の負荷が膨大になったプロジェクトの状況を表現するのに使われる。プロジェクトが死に向かう過酷な状況でプロジェクト要員が行進するという意味から、「デスマーチ」は「死の行進」とも呼ばれる。

具体的には、長時間の残業や徹夜・休日出勤の常態化といった、プロジェクトメンバーに極端な負荷・過重労働を強い、通常の勤務状態では成功する可能性がとても低いプロジェクト、およびこれに参加させられている状況を指す。

プロジェクト要員は、心身ともに極めて重い負担を強いられるため、急激な体調不良、離職、開発の破棄ともとれる中途半端な状態での強引な納品、場合によっては過労死や過労自殺に至る。その発生要因は、顧客からの無理な要求、開発側による無理な計画、前行程の遅延を後行程で長時間労働といった力業によって穴埋めする企業体質、プロジェクトマネジメントが不適切であることとされている。

「ブラック労働」

Wikipediaによると、「ブラック企業」または「ブラック会社」は、「違法行為、不法行為、脱法行為などにより従業員に無給の残業・朝残業などの不当な労働を強制したりパワハラなど人権を踏みにじる行為を日常的に行っている企業、もしくはそのような行為を行ってる社員を放置、黙認している企業のことを指す俗語である。」とある。このことから「ブラック労働」は上述のような労働スタイルを指すと考えられ、「ブラック企業」に限った話ではなく、一部の部門、一部のプロジェクトでも当てはまることがある。世間一般のイメージでは、長時間労働、ハラスメント、低賃金、専門家によると違法状態の放置、また私の「ブラック労働」の定義は、「労働によって、健康面・生活面・経済面・キャリア面に被害を与えること、もしくはその恐れのあること」である。つまり、ブルーカラー・ホワイトカラーや正規・非正規雇用を問わず、末端の従業員に過重な心身の負担や長時間の労働など劣悪な労働環境での勤務を強いて改善しないこと、すなわち、入社をお勧めできず、早期の転職が推奨されるような体質のことを「ブラック」と総称される。

従来の日本型雇用においては、単身赴任、長時間労働サービス残業にみられる企業の強大な指揮命令が労働者に課される一方で、年功賃金や終身雇用が保障され、福利厚生が充実していた。しかし、近年では長期雇用保障や手厚い企業福祉がないにもかかわらず指揮命令の強さや上層部の強大な権力が残っている。この点を「ブラック」と世間一般からの強い批判を浴びることとなった経緯もある。

あと本記事のタイトルには無いが、「強制労働」については「ブラック労働」と対比されている以下の記事を参照いただきたい。
o08usyu7231.hatenablog.com

2.比較してみた所感

長時間労働」は単純に労働時間が本来の規定と比べて大幅に長いことを指している。IT業界の長時間労働対策に関するサイトやセミナーがあり、ここで使われている言葉の多くは「長時間労働」だ。
www.mhlw.go.jp

「過重労働」は「長時間労働」を含んでいるが、心身への負荷が重すぎることを全面に出しているイメージである。「長時間労働」よりも広い意味で使われる印象を受けている。医療機関や納期直前のシステム開発プロジェクトのように職業柄心身に負荷がかかるケースと、パワハラにより心身に負荷がかかるケースがあり、一見前者はやむを得ず、後者は早急な改善・対策が必要と受け取られるそうだが、この負荷がかかることで健康面に影響を与えることを考えれば、どちらも問題ありと言わざるを得ない。

デスマーチ」はシステム開発プロジェクトでよく使われる以外は、「過重労働」とあまり区別がつかないようなイメージを持っていた。労働者にとって過酷な状態であることは両者変わりないが、前述の説明からすると「過重労働」が「労働」もしくは「労働者」にフォーカスしているのに対し、「デスマーチ」(死の行進)は破綻寸前で死に向かっている「プロジェクト」にフォーカスしている印象を受ける。

「ブラック労働」は「長時間労働」を含んでいるが、それ以外にも膨大な業務量に対してスケジュールが短く設定されている等、パワハラ体質、労働力の搾取、違法性といった要素が加味されているイメージである。また、「ブラック」の定義が曖昧で、労働者個人個人の価値観に左右され、これらの言葉の中で最も非公式な言葉でマイナスイメージの強いものと言える。それゆえ、公式な場やサイトで使われることは少なく、口コミサイト等でよく使われるイメージである。
転職成功の秘訣は、サイトに公開されない求人にあった。

3.まとめ

長時間労働」「過重労働」「デスマーチ」「ブラック労働」、これらの言葉の使い分けやニュアンスの違いについて調べ、考えてみた。微妙な違いはあるもののどれも問題であることには変わりなく、どの状態であっても、健康、キャリア、生活、人生に悪影響を与えるものでしかない。企業としては組織単位での是正が必須であり、これらに巻き込まれている被害者はまず改善を訴え、改善の見込みがなければ、転職をはじめこれらの状態から抜け出すことが必要だ。






「セカンドハラスメント」に対する無知・無策は致命的である

f:id:o08Usyu7231:20210615180028j:plain
「セカンドハラスメント」に対する無知・無策は致命的だ。他のハラスメント以上の問題点を有しており、非常に深刻な問題だ。是非とも、知見や事例をインプットしていただき、解決・対策・回避してもらいたいものである。





1.セカンドハラスメントとは

セカンドハラスメントとは、被害者が既に受けたハラスメントに対して、声を挙げたり、周囲に相談したことによって、被害を軽視されたり、被害者側の問題として扱われ二次被害が起き、状況が悪化することを指す。ハラスメント被害者を不利益扱いする行為の総称だ。略して「セカハラ」とも言われ、「セクハラ」とよく似た言葉ではあるが意味は全く異なる。一方で、「セカハラ」は「セクハラ」の派生形とも言われている。

セクハラ被害者に対して、
 「なぜに、一緒に食事に行ったの?」
 「なぜ、断らなかったの?」
 「あなたのほうから誘ったんじゃないの?」
 「そんな格好をしているからではないか?」
といったように被害者を責めることがある。これがセクハラを元にしたセカンドハラスメントの一例である。

セクハラだけではない。パワハラを受けた被害者に対して
 「被害者側も悪い!」
 「加害者の気持ちを考えたか?」
 「加害者の意図を理解していたか?」
といった言動も同様だ。

セカンドハラスメントは違法行為である。法的には元となったハラスメントの内容が引き継がれる形になる。「セクハラ」を元にしたものであれば「男女雇用機会均等法」違反、「マタハラ」であれば「育児介護休業法」違反、「パワハラ」であれば「損害賠償請求対象」となるほか、2020年6月から大手企業で適用された「パワハラ防止法」(中小企業では2022年4月から適用)違反にもなる。

詳細説明は他のサイトも参照してほしい。
www-pro--bank-co-jp.cdn.ampproject.org
agent-network.com
bizuben.com

過去には、NHKの特集で放送されたこともある。
www.nhk.or.jp

2.セカンドハラスメント問題が深刻な理由

セカンドハラスメントの詳細説明については、上述したような他のサイトに記載されているので、ここでは省略する。ここでは、私がセカンドハラスメントの問題が大きく深刻であると考えた4つの理由を挙げ、解説していく。

(1) あまり知られていない。

「セクハラ」「パワハラ」「マタハラ」あたりまでは世の中に浸透し、法律によって保護される、もしくは発生すればニュースにもなりうるほどにまでなってきた。しかし、「セカハラ」はなかなか聞き慣れない言葉であり、あまり世の中や企業内に浸透していない。企業の上層部やコンプライアンス相談窓口部門も知らないといったケースもあるほどだ。

(2) つい、やってしまいがち。

「セカンドハラスメント」は他のハラスメントとは違い、被害者にも改善点があるところに着目し、被害者のためを思った、善意の上での言動であることが少なくない。しかし、被害者からは、被害者に寄り添わず、加害者に寄り添い、諸悪の根元である加害者を是正する姿勢が見られないところが問題視されていることを忘れてはならない。被害者と被害者以外の人間では、圧倒的に感覚が違うものだ。「セカンドハラスメント」は加害者側に罪の意識が薄く、その大きな原因は加害者側の想像力の欠如である。

(3) 被害者の被害は大きい。

被害者はただでさえハラスメントによる被害を受けている状態で、勇気を出して相談したり、声を挙げたりしている。ここまでは素晴らしいことだ。にもかかわらず、これを踏みにじるような言動を周囲が行うことで、ハラスメント解決からますます遠ざかる結果となり、被害者は「泣き寝入りするしかないのか」という心理になってしまう。

(4) 被害者を黙らせることで大元のハラスメント撲滅から遠ざかる。

更に恐ろしいのは、加害者が是正されず、被害者が二重三重の被害を受けることで、被害者や周囲の人達に「相談しても無駄。」ということを学習させ、ハラスメント被害者を黙らせ、ハラスメントを相談しにくくし、大元のハラスメントも無くならないという悪循環に陥るところである。
あるハラスメント外部窓口団体は、セカンドハラスメントを懸念し、事実の報告が挙げられず、調査や解決・サポートをはじめ、その団体の事業に支障をきたしているという状況だ。

3.セカンドハラスメントの事例

セカンドハラスメントの事例を紹介しよう。

他社の管理職(パワハラ加害者)からパワハラを受けた被害者が苦痛により、体調を壊したことを、後日パワハラ加害者に対してクレームした。その結果、しばらく当人同士でトラブルになったものの、被害者が屈することなく労働問題に対する正論を発信し、パワハラ加害者が最終的に謝罪した例がある。これは組織内どころか社会的に見ても優良事例である。
しかし、後に被害者の上司(セカハラ加害者)は被害者に対して、
 「加害者の意図を理解していたか?」
 「被害者体調不良は他社には関係なく、当社内部で解決すべき。」
 「会社対会社の関係を考えているか?」
などと被害者を責めた挙げ句の果てに、被害者の人事評価を低評価とした。
被害者の上司の行為は、明らかにパワハラ被害者を黙らせることを目的としていることが見えており、セカンドハラスメントにあたる。

上記のセカンドハラスメント加害者の行為について、被害者はパワハラ相談窓口に報告した。パワハラ相談窓口の担当者は「セカンドハラスメント」の言葉をこの時初めて知ったとのことであり、「違法である」との実感が沸いていないようだった。また、人事評価の不利益について、「人事評価については上司が部下の一年間の行動を見てきて最もよく知る立場なので、パワハラ相談窓口が介入できない。」と述べ、セカンドハラスメント加害者が処分されることはなかった。しかし、セカンドハラスメントの一般知識については浸透させていくとの回答があり、社内全従業員宛てに定期的に発信される情報に、「セカンドハラスメント」の一般知識について取り上げられた。

上記のセカンドハラスメント加害者の行為について、被害者はセカンドハラスメント加害者の上司(部門のコンプライアンス責任者)に相談した。コンプライアンス責任者はセカンドハラスメント加害者と被害者の両者からヒアリングした後、コンプライアンス責任者は被害者に対して、被害者の改善点についての教育が中心になり、「(被害者への)成長のためを思っている」「期待している」といった内容を伝えた。パワハラやセカンドハラスメントから話を遠ざけようとしたり、セカンドハラスメント加害者が行った人事評価を正当化する姿勢が見られた。被害者にとって、コンプライアンス責任者のこのような行動は責任逃れのように見えた。セカンドハラスメント加害者が処分されることはなかった。しかし、セカンドハラスメント加害者を含む部門内の主要メンバーへ「パワハラが発生することによる影響、重み」についての話が、コンプライアンス責任者より展開された。

上記のセカンドハラスメントについて、被害者はこれ以上、不利益を受けることはなかった。被害者に寄り添い、協力する一部のメンバーもいた。
しかし、解決に向けてもあまり進展しなかった。被害者が受けた不当な人事評価は回復されることはなかった。セカンドハラスメント加害者からの被害者に対する謝罪もなかった。
本来なら、セカンドハラスメント加害者による謝罪のほか、加害者の処分、被害者における不当評価結果の回復措置、本人・組織としての再発防止、損害賠償が必要なレベルである。

4.セカンドハラスメントに対するあるべき対応

(1) 加害者、第3者、企業側の対応

多くの記事に記載されているが、まずは被害者からの「傾聴」である。決して被害者を否定したりしないこと。そして、セカンドハラスメント加害者は加害者であることの意識が薄く、被害者と被害者以外では心理状態が圧倒的に違うことを理解しておくべきだ。

一方、パワハラ被害者の改善点をセカンドハラスメントにならないように伝えるにはどうすれば良いか? ハラスメント被害者に成長してほしい場合どのような対応をすればよいか? という疑問がある。私自身色々調べたが、やはり「被害者に寄り添う」「被害者の話を聞く」「否定しない」ということが言われており、明確な答えにはたどり着けなかった。

パワハラ被害者に成長してほしい」と考えるならば、組織として理解しておかなければならないことがある。パワハラ被害者に対して直接成長を求めたり、期待や要求を伝えるだけでは、肝心な「被害」に対して寄り添っておらず、ハラスメントに対する取り組みが不十分であると感じさせてしまう。重要なのは、「パワハラ被害者が成長する」ために、その「前段」を整えることである。

「被害者のためを思って指導している」と言うが、そう言っておきながら被害者のためになっておらず、被害者を更に苦しめ、加害者、第三者、責任者が責任逃れをしているに過ぎない。
「被害者のためを思っている」のなら、まずハラスメントを無くすことが最優先であり、ハラスメントを許容しない体質作り、加害者への教育、ハラスメントに対して声を挙げやすくすること(但し、悪用、でっち上げは不可)など、真摯にハラスメントと向き合うことである。管理者にはこのような姿勢が必要だ。加害者側に問題があるのに、被害者への責任追及や指導を真っ先に行うべきではない。

ハラスメントが起きる職場で、人材の成長など見込めるはずがないどころか、優秀な人材が辞めていく、優秀な人材が来ないといったマイナス作用しかないことは必然だ。ハラスメントが原因で被害者が退職すれば、管理者はどのように責任をとるのだろうか?

(2) 被害者側の対応

被害者もセカンドハラスメントの知識や事例をインプットしておいた方が良い。ハラスメントを受けたことを、上司、同僚、コンプライアンス相談窓口へ相談するときは、その前に相談を受けた側がどのような対応をすべきか、あらかじめ知っておくと良い。

パワハラ相談窓口の相談員向けの教材やWebの情報、動画等で、相談を受けた人の対応として、良いもの、良くないものかあるので、それを一通り見れば素人でもある程度は分かる。
www.no-harassment.mhlw.go.jp

世の中には、コンプライアンス相談窓口の相談員がセカンドハラスメントをしている事例があるという情報を得たことがある。このようなことがあり得るので、相談相手は慎重に見極めよう。社内が信用できないなら、外部の相談窓口に相談するのも良い。
www.no-harassment.mhlw.go.jp

同時に、転職の準備を進めておこう。自分の人生を無駄にしないために。
転職成功の秘訣は、サイトに公開されない求人にあった。










ソフトウェア不具合報告を受ける際の心得

近年、様々な製品やサービスにおいてソフトウェアは欠かせない位置付けとなってきた。そのソフトウェアにおいて不具合が発生すると、顧客や市場に迷惑をかけ、信頼を損ねてしまう。

システム開発企業の部門の責任者は、ソフトウェア不具合に対して、早期の回復、関係者への説明など、迅速で真摯な対応が求められる。中でも、ソフトウェア不具合報告に関しては、「事実関係を、簡潔に、適切に」などと報告する側へ求める指導内容はよく見受けられる。これは一部正しい。
f:id:o08Usyu7231:20210611195449j:plain
しかし、現実のところ報告する側も報告以外の不具合対応で疲弊している人間にとっては、綺麗事や根性論でしかない。ここに厳しい指摘でも不具合発生部門にとってプラスになることならまだしも、単なる感情をぶつけるだけ、現場で頑張っている人達の苦労も汲み取れず、説明者や不具合発生部門を不快にさせる迷惑で残念な人というのも一定割合いる。

この記事では、ソフトウェア不具合報告を受ける側として心得るべきこと、私が気をつけていることを書いている。不具合報告を部下から上司へ行う場合、ソフトウェア開発企業から取引先へ行う場合、色々あるが共通して言えることは、「人間対人間」だ。これをよくわかっている企業と、そうでない企業で、大きく分かれるのではないかと思っている。

転職成功の秘訣は、サイトに公開されない求人にあった。

1.二律背反

ソフトウェア不具合報告を含めて、「報告は簡潔」にと一般的には言われている。

簡潔に報告すると、「分析が浅い」とか言う人もいる。
細かく報告すると、「よくわからないから簡潔に」と言う。

どちらか一方を選択すれば、他方の理由で否定される。このような状況は二律背反である。

「なぜミスをしてしまったか説明して」と言われて説明しようとすると、「言い訳しない」などと言われたりするのも、二律背反である。

二律背反によって当事者や報告者を、戸惑わせてはいけない。

2.ソフトウェア開発は簡単ではないことを理解する

多くのソフトウェア不具合は、簡潔に報告できるほど、単純ではない。「簡潔に報告」すると、「内容が簡単」なものであると勘違いする人がいる。

「詳細な報告を受けても内容の把握が追い付かない。」というのはその通りだろう。そのような人には「簡潔に報告」することが必要である。

問題はその先である。「簡潔に報告」されたからといって「内容が簡単」だと考えてはいけない。報告資料は、説明のために簡単に記載されていることがほとんどである。

「簡潔に報告」されても、そのさらに裏があるのではないかと想定しておくべきであるし、実際に私はそのようにしている。

3.ハラスメントの禁止

ソフトウェア不具合を出すと市場やお客様、関連部門に迷惑がかかる。迷惑を受けた側が、何をやっても良いかというとそれは違う。

「顧客のほうが立場が上だ。」と未だに勘違いしている人がいるが、優越的な関係を背景にしてはいけないし、「不具合を出した」ことの弱みに漬け込み、パワハラ等の悪質行為な及ぶのはもってのほかである。もちろん「不具合を出した」企業や部門は迅速に、真摯に、誠実に対応を進めなければならないことは前提である。

不具合報告から話が逸れるが、ペナルティで業務を増やすのもいかがなものかと思う。顧客からソフトウェア不具合発生企業へ、ソフトウェアのチェックリストを渡して「これに沿って検証せよ!」という依頼をする事例があったが、ソフトウェア品質検証のために本当に必要なことであれば問題ない。しかし、ただでさえ業務負荷が高く疲弊している人に対して、ペナルティや嫌がらせのような意味合いで行うことがあれば、かえって逆効果だ。負荷が増え、更に疲弊し、更にミスが増えるリスクを意識しておくべきである。人間としてあるべき姿が問われている。

話を戻そう。責めても何も良いことはない。建設的な意見や協力が必要だ。他社の不具合事例から何か学ぶことすらあるだろう

4.労働環境への配慮

ソフトウェア不具合に対しては、技術、プロセスに関する原因を分析した上で、再発防止が必要である。再発防止というと、技術やプロセスについてのものがほとんどであるが、労働環境に関する原因、再発防止も忘れてはならない。

スケジュールに余裕があったか?
作業者の負担に配慮したか?
十分なコンディションで業務にあたったか?

労働環境のことを語り出すと「言い訳」「甘い」「なめるな」などと、パワハラ発言をする人間が一定割合いる。

ソフトウェア不具合発生の部分が、最もクローズアップされ、吊し上げられるのだが、本質の問題は更に前段にあり、その結果ソフトウェア不具合発生に至るケースが考えられる。しかし現実には、余裕のないスケジュールや心理面から、劣悪な長時間労働パワハラ等劣悪な労働環境の結果、疲弊し、ミスが増え、不十分な検証の結果、不具合発生となって表面化した可能性を考慮できていないことが少なからずある。

ソフトウェア不具合再発防止に労務面のことを述べると、見事に揉めたが、結果としては正しいことを証明した事例がある。
o08usyu7231.hatenablog.com


ミスが許されない業務については、心身ともに健康な状態を維持できる良い労働環境の提供は絶対である。ソフトウェア開発に限った話ではない。例えば、医療現場はその筆頭と言える。
o08usyu7231.hatenablog.com




まとめ

ソフトウェア不具合を発生・流出させた企業や部門は、迅速に、真摯に、誠実に対応を進めなければならないことは言うまでもない。もちろん、発生・流出させてはいけない。発生・流出させてしまった場合でも、事実をわかりやすく説明し、再発防止の検討等、するべきことは多くある。

一方、ソフトウェア不具合報告を受ける側は横柄な態度をとりがちだ。そのようなことがあってはいけない。立場は色々あるが共通して言えることは、「人間対人間」だ。

ソフトウェア不具合を許容せよと言っているわけではないが、ソフトウェア開発は簡単ではないことを知っておくべきである。これをよくわかっている企業と、そうでない企業で、大きく分かれるのではないかと思っている。