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

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

パワハラ事例解説(24) - ソフトウェア設計に対する会議の場での否定

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

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

目次


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

【事例24】ソフトウェア設計に対する会議の場での否定

システム開発における要求仕様に対して、それを実現する手段はハードウェアとソフトウェアに大きく区別される。このうち、ソフトウェア設計にかかわる部分での事例である。パワハラと呼べるかどうかは微妙だ。

ソフトウェアの設計方法は、組織によって大枠の考え方を統一しているところもあるが、一般的には何を重視するかによって変わってくる。ソースコードの読みやすさなのか、作成するときの労力なのか、テストのやりやすさなのか、作成スピードなのか、汎用性なのか・・・。

あるシステム開発プロジェクトにて、リーダー(加害者)は、ベテラン社員(被害者)が作成したソフトウェアの設計が気に入らなかったため、チームのメンバー全員が集まっている会議の場で

「これは見にくい! あかんわ!」

と一蹴した。設計が複雑に見えてしまいリーダーの目にはそのように見えたのだろう。

その場では、メンバは萎縮し、リーダーに異を唱える人は居なかった。ベテラン社員はリーダーの発言に対して違和感を持った。理由は次の通りだ。

  • ベテラン社員を含め一部の担当者は、このベテラン社員の設計により、テストがやりやすいことの恩恵を受けている。
  • リーダーの言い分が全うな指導で、取り入れるべきところがあるならまだしも、ベテラン社員には参考にすらならなかった。
  • リーダーは表面的な部分のみを捉え、ベテラン社員の設計によるメリットを理解していないまま、短絡的に問題となる言葉を発してしまった。

リーダーという立場を活かして(職務上の力関係を背景に)(①)、周囲(主にベテラン社員)を不快にさせた(就労環境を悪化させた)(③)面は、パワハラの定義に当てはまるのだが、業務に必要相当な範囲を超えているかどうか(②)は微妙である。ソフトウェア設計に対する必要な指摘と捉えれば業務の範囲とも言えるが、このケースはほぼ否定に近い。

パワハラに当たるとは言い難くとも、リーダーの発言はもう少し周囲の人の心情を考えたものにすべきである。

具体的には、

  1. ベテラン社員の設計に対するメリット・デメリットを明確にする
  2. 該当する開発プロジェクトや更に将来的な展望にどのような要素が求められるかを明確にする
  3. 両者がマッチしている点、していない点を洗い出す
  4. 最終的な落としどころを決める。

という流れである。

また、内容によっては、ベテラン社員に任せておけば良いことも少なくない。

リーダーにはこのような姿勢が求められる。当たり前にできてほしい。でなければ組織に活気がなくなし、否定的な面が多くみられるリーダーに、ベテラン社員も良いアイデアを持ってくることはなくなるだろう。法律上パワハラとならなくても、職場にはデメリットをもたらすのである。

リーダーや管理職の発言は本人が想像している以上に周囲への影響が大きいものだ。組織の中で影響力のある立場であるから当然だ。しかし、リーダーや管理職自身がそのことを理解していないケースが少なくない。ソフトウェア開発に限らず、組織の活性化や成果の最大化に向けて、リーダーや管理職が学ぶべきことは多い。

最後に、この件一件だけであれば大した問題ではないのだが、このような人材は他の場面においてもパワハラ気質である傾向があり、小さな兆候は見逃せないのである。被害者になる可能性のある人に対して要求するのは理不尽であるが、大きな被害を受ける前に小さな兆候を検知し、未然防止に努めていただきたい。そのためにこのような記事を書いている。誰もが、加害者にも被害者にもなりうるのである。

実際、本事例のリーダーと下記事例の加害者は同一人物だ。
【事例20】納期逼迫による残業時間増加への圧力
o08usyu7231.hatenablog.com

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

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

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

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

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

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

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