ソフトウェアには大きく二つのパターンがあり、一つはWindowsのソフト、スマホアプリ、カーナビの画像処理で少々のバグがあっても機敏に対応する、もしくは次のバージョンで対応すれば許される程度のパターンである。もう一つは自動車のエンジン制御、鉄道関係のシステム、金融システムのように、安全に関わるもの、バグが許されない品質最重視のパターンがある。
「ソフトウェアにバグが無いことを証明する」
このことは必要なことであると認識する方も多い。これを達成するには、どのようなプロセスで設計し、どのくらい検証、テストすればよいか？ 気の遠くなる話である。
イメージとしては、かなり無理な要求であると思う一方で、正しいことを言っているように思えるので、何も言い返せなくて困る。はたして、これはパワハラに当たるのか？
パワハラに当たるとすれば、どのような裏付けでそのように言えるのか？
このような疑問や悩みを持つ、ソフトウェアエンジニアは多いのではないだろうか？
この記事では、そのような疑問や悩みについて、関連事項を調査した上での意見を述べたい。
1.ソフトウェアのテストでバグが無いことは証明できない
まず、結論から言うと、ソフトウェアにバグが無いことは示せない。ソフトウェアにバグがあることは示せる。テストとは、バグがあることを証明するために行うものである。
JSTQB （日本ソフトウェアテスト資格認定委員会）が定める「ソフトウェアテストの7原則」というものがある。ここでは項目のみ挙げる。
- 【原則１】テストは欠陥があることしか示せない
- 【原則２】全数テストは不可能
- 【原則３】早期テストで時間とコストを節約
- 【原則４】欠陥の偏在
- 【原則５】殺虫剤のパラドックス
- 【原則６】テストは状況次第
- 【原則７】「バグゼロ」の落とし穴
この記事で関係あるのは【原則１】【原則２】【原則７】である。
「あること」「起きること」を証明するのには１例をあげればいいだけである。しかし、「ないこと」「おきないこと」を証明するためには世の中すべてを調べないといけない。極めて困難どころか、気の遠くなる話である。なので、議論の場合には、まず「ある」という主張を先に証明することが現実的だ。「ない」ことを証明できないからといって「ある」とは言えないだろう。
無罪であることの証明、というのはとても難しい。すべての行動を明らかにしないといけないからだ。だからと言って「無罪であることを証明できないならあなたは有罪です」とはならない。有罪にする場合には、有罪であることを証明しないといない。
ソフトウェアテストや検証において現実的なのは、
「合意した確認範囲とテストケースにおいて、ユーザーに影響を与えるようなバグは見つかりませんでした。」
「これだけのテストを実施し、その限りにおいては、問題となる動作は確認されませんでした。」
という程度である。
余談であるが、私が過去に勉強した情報処理技術者試験の高度試験区分のひ一つ『システム監査技術者』の参考書に記載されていたのを覚えている内容が、
「○○の前提で監査を行った限りでは、特に問題となる点は見当たらなかった。」
という程度のものであり、
「監査をやれば完璧！」
「監査にクリアしたから、ウチの組織は全く問題ない。」
わけではないのである。ソフトウェア開発も同じである。
ソフトウェアに無知な顧客や組織内上層部から、
「バグはもうないよね！？」
「バグがないことを証明しろ」
「バグがないことを証明するために、〇〇の検証を計画せよ」
と力関係を背景に詰め寄られても、「もうバグはないです！」とは言えないのである。
ソフトウェア開発現場の管理職や上位者で「バグがないことを証明しろ。それまでは帰れない。」と言うと、その人はソフトウェアの素人であると断言できる。「ソフトウェアにバグがないことは証明できない」のである。
2.パワハラの定義と類型をおさらいしておく
- ①優越的な関係を背景とした言動
- ②業務上必要かつ相当な範囲を超えたもの
- ③労働者の就業環境が害されるもの
①から③までの３つの要素を全て満たすものをいう。
なお、客観的にみて、業務上必要かつ相当な範囲で行われる適正な業務指示や指導については、職場におけるパワーハラスメントには該当しない。
詳しくはこちらを見てほしい。
www.no-harassment.mhlw.go.jp
続いて、パワハラの６類型（パターン）を項目だけ紹介しておく。
- (1)身体的な攻撃
- (2)精神的な攻撃
- (3)人間関係からの切り離し
- (4)過大な要求
- (5)過小な要求
- (6)個の侵害
詳しくはこちらを見てほしい。
www.no-harassment.mhlw.go.jp
パワハラの定義と類型については、以上のように説明されている。しかし、現実には皆が皆、これらを理解していないし、色々なところでパワハラが発生している。パワハラ発生とまではいかなくとも、グレーゾーン、パワハラ体質といった状況がよくある。
顧客や組織の上層部から力関係を背景に詰め寄られ、職場のモチベーションがダウンしたり、パワハラ体質や長時間労働で従業員が疲弊したり、心身に不調をきたし、優秀な人材の離脱、最悪の場合過労死や過労自殺が起きてしまう。第３者から見ると、異常でしかないのだが、当事者たちはなぜか頑張ってしまう。
3.なぜ「ソフトウェアにバグが無いことを証明せよ」というのはパワハラなのか？
ここまで、
「ソフトウェアのテスト」
「パワハラの定義と類型」
について記載してきた。この２つを組み合わせればおのずと答えは出てくる。
繰り返すが、「ソフトウェアにバグがないことは証明できない」のである。JSTQBが定める「ソフトウェアテストの7原則」のうち、この記事に関係あるのは、
- 【原則１】テストは欠陥があることしか示せない
- 【原則２】全数テストは不可能
- 【原則７】「バグゼロ」の落とし穴
の３つである。
次に、パワハラの定義の３条件。
- ①優越的な関係を背景とした言動
- ②業務上必要かつ相当な範囲を超えたもの
- ③労働者の就業環境が害されるもの
６類型な中から関連する２つ。
- (2)精神的な攻撃
- (4)過大な要求
ソフトウェアに無知な顧客や組織内上層部から、「バグがないことを証明しろ」と力関係を背景(①)に詰め寄られ、「ソフトウェアにバグがないことは証明できない」(【原則１】【原則２】【原則７】)にも関わらず、これを要求される(②)。
その結果、職場のモチベーションがダウンしたり、パワハラ体質や長時間労働で従業員が疲弊したり、心身に不調をきたし、優秀な人材の離脱、最悪の場合過労死や過労自殺が起きてしまう(③)。
従業員に対して心理的に圧迫させ、「緊張感を持たせる」と謳いながら、「恐怖感でコントロール」している「精神的な攻撃」(2)となり、「過大な要求」(4)どころか不可能な要求である。
「ソフトウェアテストの7原則」と「パワハラの定義・類型」を照らし合わせると、ぴったり上記のことが言えてしまうのである。
本記事では「ソフトウェアテスト」について述べたが、ソフトウェア開発は簡単なものではない。ソフトウェア開発組織の管理職、組織の上層部、ソフトウェア開発依頼組織は「ソフトウェアについての理解」と「パワハラについての理解」の両方が求められる。
一方、ソフトウェアエンジニアは「ソフトウェアについての理解」と「パワハラについての理解」の両方が出来ている企業へ就職、転職した方が良いことは間違いない。
4.発注側・受注側ともにソフトウェアエンジニアの労働環境に配慮せよ！
「ソフトウェアバグがないことを証明する」ことは不可能だが、世の中でバグが発生し、安全・生命におよぶ被害、経済への打撃、金銭に関する被害はあってはならない。
開発するソフトウェアが関連する製品・サービスの様々な使われ方を想定し、十分な設計・検証・テストがなされるには、「ソフトウェアバグがないことを証明せよ」と根性論をもって詰め寄るよりも、ソフトウェアエンジニアの労働環境を良好にすることが求められるということを、システム開発の発注側も、受注側も理解しておくべきである。
o08usyu7231.hatenablog.com
某金融系システムのように、ソフトウェアエンジニアの労働環境悪く、必要なシステム構築（設計・検証・テスト）に十分な工数が取れなければ、心理的な余裕がなくなり、悪意や怠慢が無くとも、システムの利用者側に跳ね返るのである。膨大で複雑なソフトウェア開発を「短納期」で発注し、「ソフトウェアバグがないことを証明せよ」と行き過ぎた要求をするという前段こそ改め、ソフトウェアエンジニアの労働環境に配慮した進め方が求められるのである。
o08usyu7231.hatenablog.com
o08usyu7231.hatenablog.com
優秀なソフトウェアエンジニア（テストエンジニアも含む）は、粗悪な要求元に潰されることなく、健全な環境で最大のパフォーマンスを発揮してほしい。粗悪な要求元は廃れ、健全な組織のみ繁栄してくれた方が世の中にとって良いことは間違いない。
