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

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

パワハラ事例解説(18) - システム開発における設計レビュー時に自分の価値観押し付け

このシリーズの記事では、パワハラの定義と類型、私の身近に起きたグレーゾーンを含む事例について、定義と類型をもとに解説している。内容によっては考え方や改善策についても述べているので参考にしてほしい。

自分が加害者にならないように注意することをはじめ、被害に遭いそうな場合はいち早く予兆に気付くことが求められる。

目次


【最初に】パワハラの定義と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

ニュースで取り上げられているものや、裁判になったものは組織内で解決できなかった手遅れ案件である。また、世間の目も段々厳しくなってきており、損害賠償の相場も数百万単位(被害者が死亡の場合は数千万単位)に上がってきているという情報もある。いくら正論であっても、相手が嫌がるやり方であれば、法律に触れることになる。

ただでさえニュースで見ることが多くなってきているのだが、これらは氷山の一角であり、水面下には程度の大小を問わずさらに多くの案件が潜んでいる。上述の定義や類型を基に、私が実際に見たことがある事例を紹介し、定義や類型を元に解説する。程度や被害の大小は様々である。

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

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

★関連リンク
o08usyu7231.hatenablog.com
o08usyu7231.hatenablog.com
★事例一覧はこちら↓
o08usyu7231.hatenablog.com

【事例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氏のように力関係を背景に、価値観を押し付け、他者の責任としている以上、労働環境が改善されることはない。

『新規開発崩し』ではなく、正しい『派生開発』の知識を身に着けるべきだ。

ちなみに、この事例で扱った開発案件は、他にも下記記事の事例にも該当している。いずれも加害者はC氏である。
o08usyu7231.hatenablog.com
o08usyu7231.hatenablog.com

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

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

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

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

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

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

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