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

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

パワハラ事例解説(19) - システム開発における過剰要求未達時のレビューで「詰問」

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

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

目次


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

【事例19】システム開発における過剰要求未達時のレビューで「詰問」

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

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


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

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


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

パワハラ事例を述べる前に、前置きの説明をする。

システムを構築する上での仕様には、大きく「正常系」と「異常系」の二つに分かれる。「正常系」とは使用者が普段使用する機能における表向きの動作(振る舞い)であり、要求通りの機能を満たすことが求められる。一方、「異常系」とは異常時の動作であり、システムを構成する部品の一部が機能不全となった場合や使用者が想定外の使い方をした場合でも、システム全体としては、安全や整合性が担保されることが求められる。「正常系」は機能を満たしているかを普通にテストすれば不具合を見つけやすい一方で、「異常系」は意図的に意地悪操作やおかしな状態、故障状態を作り出さなければ不具合を見つけることができない。大抵の場合、「正常系」が出来ていればシステムが問題なく動作しているように見えてしまい、「異常系」の検証がおろそかになりがちてある。その結果、「異常系」における検証が不十分であることに起因する不具合が市場へ流出しやすい。金融システムトラブルによるシステム停止は、まさにこの「異常系」での不具合が多いのではないかと考えられる。システムにおける「異常系」の設計は極めて重要である。

さて、いきなりシステムの「正常系」「異常系」の話をしたが、このパワハラ事例と何が関係あるのかということについて述べる。

被害者A氏は、前述したように短かすぎるスケジュールで、設計に取り掛かり、システムに使用するデバイスのマニュアルの読み込みに苦労しながら、何とか「正常系」の設計を終えた。

A氏による設計が完了した時点で、B氏、C氏の三者でレビューを行った。「正常系」の設計の内容こそ問題ないものの、C氏は「異常系」も対応されていて当然のような認識であった。レビューでは、「異常系」のことを中心に「質問」。A氏は「未検討」と回答すると、C氏は更に嫌がらせのごとく「質問」。いや、「質問」ではなく「詰問」である。

冒頭に述べた通り、ただでさえ異常に短いスケジュールと長時間労働の中で、鋭意尽力して作り上げたデバイスドライバ「正常系」の設計を完成させたA氏の苦労を踏みにじり、「異常系」など着手不可能な状況と何度伝えても、C氏の「詰問」の内容は「異常系」。さすがにA氏は呆れるのみであった。B氏も「異常系」は優先度を下げて後回しと説明するも、何も変わらなかった。


これは、長時間のブラック労働とセットで発生するパワハラの典型である。発注者としての立場を利用し(①)、「正常系」の設計を完成させるだけでも並々ならぬ苦労であるにも関わらず、これを踏みにじり、検討未着手である「異常系」に対する執拗な「詰問」により、設計者が戸惑う様子や心理を汲み取ろうとせず、もはや嫌がらせと化してしまっているという、業務に必要相当な範囲を超えた言動により(②)、就労環境を悪化させている(③)ことから、パワハラの定義を満たしている。6類型では、設計者の苦労を踏みにじり「詰問」を続け、相手に不快感やダメージを与える(2)「精神的な攻撃」、ただでさえ過重労働の状況で着手すらしていない未達部分があることを理解せず、あたかも「異常系」まで対応できていて当然といった姿勢を変えない(4)「過大な要求」が該当する。

本例は「テクハラ」によく似ている。「テクハラ」は「テクノロジーハラスメント」もしくは「テクニカルハラスメント」の略で、PCスキルの長けた人がPCにあまり詳しくない人に対して「こんなことも知らないのですか?」と嫌味を言ったり、難しい・聞き慣れない専門用語をひたすら並べて聞き手を戸惑わせる行為を指す。
jinjibu.jp

本例もシステムの「異常系」という一部の業務領域に対して、ただでさえ異常なほどの短すぎるスケジュールと過重労働の中、工数不足で理解が追いつかない被害者に対してマウントを取り、未着手である「異常系」まで出来て当然といった態度で接することで、例え悪意が無くとも相手に不快感を与え、戸惑わせる行為に問題である。
o08usyu7231.hatenablog.com

システムにおける「異常系」は『重要な位置付け』であり、システム設計において必ず考慮しなければならないものである。しかし、このC氏の場合は「異常系」の『重要な位置付け』を悪用しブラック労働の被害者に責任を押し付けるという、卑劣なやり方を行っていたのである。


C氏が改めなければならないのは以下の点だ。

  • A氏の状況や心情を理解し、配慮する。
  • スケジュール確保等、「異常系」まで確実に対応できるよう「前段」を整える。
  • 「異常系」を別タスクにする。
  • 「テクハラ」を理解し、本事例に応用できる程度の想像力を養う。
  • ただでさえ過重労働の中、A氏に「正常系」を対応いただいたことに感謝し、敬意を示す。(ホワイト企業は出来ている。)
  • 個人レベルではなく組織として、下請け取引先も含めてブラック労働の克服に努める。
  • 「業績」「納期」「信頼」などビジネスの側面のみに着目した観点を全面に押し出し、取引先担当者A氏へ詰め寄るのではなく、「人権」「健康」「道徳」「倫理」「社会性」を考慮できる程度にまで視座を高める。


被害者A氏としては無理なスケジュールの対応は断固として断るべきだ。断るには勇気が必要だ。本例の場合は、「正常系」の設計を対応しただけでも御の字である程、劣悪な「前段」であることを早期に見抜き、毅然とした態度を取ることが重要である。
過重労働の被害に巻き込まれないためにも、ブラック労働やパワハラの予兆を早期に掴み、是正の要求は必要だが、いざというときは抜け出すことも必要だ。

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

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

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

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

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

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

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

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