「好き」の反対は「好きじゃない」？
おはようございます。
ＩＴ業界で長らくソフトウェア開発のアレ（課題解決）やコレ（トラブル解決）やに従事し、最近では品質保証など第三者による精密な評価・分析を中心に従事しています。
この業界は不思議なもので、「論理」の塊のようなプログラムを作成しているにもかかわらず、案外論理的に物事を考えようとするエンジニアは非常に希少なことでも有名です。いえ、多くのエンジニアはプログラムを作成するとき"だけ"は論理的なのかもしれませんが、それ以外の業務では全くと言っていいほど論理性の欠けているシーンが多々見受けられます。
その１つがタイトルにある事例です。
たとえば、ソフトウェアテストという工程があります。
一般にソフトウェア開発におけるテストというと単体テストを経て、結合テスト、システムテスト、あるいは受入テストなど数多くのテストを実施し、
「今まで行ってきたテスト内容のなかには
もう欠陥は含まれていません」
と実証するための手続きを踏みます。
実証してもいないのに「品質」を語ることはできませんから当然です。
ですがこれ、何を意味しているのかというと詰まるところ
「やってないところはわかりません」
と言っているということなんですね。
テストというのはやったところだけ証明することはできますが、やってないところは何一つ証明できないものなのです。ある程度は論理的に説明がつきますが、それでも多くは絵に描いた餅。本当に説明内容が正しいかどうかは、実証しないことにはわかりません。
だからこそ「どんな観点のテストを実施するか」「どこまで実施するか」というのは非常に重要な割合を占めます。テストケース数が多いかどうか以前に、この点が完ぺきに近い状態となっていなければ、その後のテストケース数の過不足なんて論じても意味がありません。
この大前提を理解していない人があまりにも多いのです。
にもかかわらず「テスト結果から品質を証明しろ」と言われると、多くの企業、多くのプロジェクト、多くのエンジニアは定量的な品質管理方法だけを採用しようとします。
このIPAからPDFをダウンロードできたかと思いますが、こうした書籍が出ていることで盲目的に
「ＩＰＡがそういってるから」
を免罪符として、定量的な品質分析をすれば保証できると勘違いしている人が出てきます。ググれば大抵の情報が簡単に見つけられる時代になった弊害ですかね…。それらしい答えに行き着くとそれだけで満足してしまう人が増えた気がします。
ですが、果たしてそれだけで満足のいく結果となるでしょうか？
たとえば、この書籍のなかでも謳われている分析方法の１つに「ゾーン分析」「ゾーンモデル」というものがあります。
テストの密度（テスト対象の規模に対するテストケース数の割合）と、そのテストの結果として発生する欠陥の密度（テスト対象の規模に対するバグ数の割合）を比較したもので、それぞれに上限値と下限値を設けることで、
上下限の範囲内にある場合、適正と判断する
上下限の範囲外にある場合、不適正の可能性があるため詳細を確かめる
…あるいはそうなる可能性を予測するというものです。
しかし、そもそもこのテスト密度というものは、「テスト内容に偏りがなく、また抜け漏れが発生しないよう適切に設けられている」ことが前提で、その前提が確保されていなければ単純に数値を見ただけでは何とも言えないものです。
たとえばあるプログラムにおいてテスト密度「２件」が妥当だったと仮定しましょう。
その内容が
Ａ＝１の場合、Ｂは２であること
Ａ＝１ではない場合、Ｂは２ではないこと
と書かれていたら、それはテストとして妥当といえるのでしょうか？
パット見、間違ってはいないかもしれません。ケースとしては網羅されているような錯覚を覚える人もいるでしょう。
ですが、元来テストとは「どうなっていることが正しいか？」を検証するための工程です。「どうなって"いなければ"よい」というものではありません。テストケース①は問題ありませんが、テストケース②は明らかに変ですよね。
たしかにＡが１ではなかったらＢは２ではないのかもしれません。
ですが、本当に確認すべきはプログラムやまたはプログラムの集合体である機能が、どのような結果を返すことが正しいのかを検証することです。
仮に、「Ｂ = Ａ × ２」という仕様になっているのであれば、
Ａ＝10の場合、Ｂは20であること
Ａ＝-1の場合、Ｂは-2であること
など、「どうなっていることが正しいか」「その組み合わせによってどれだけのケースを実施すれば仕様として問題ないと言い切れるのか」という観点からテストケースを考えるべきです。
それを
①Ａ＝1の場合、Ｂは2であること
の反証として
②Ａ＝1ではない場合、Ｂは2ではないこと
としただけではテストケース①そのものを裏付けることはできても、プログラム内容やその背景にある仕様が本当に正しいかどうかなんてわかるはずもありません。仮にこのテストケースを良しとした場合、
Ａ＝5の場合、Ｂは15になる
ケースでも「OK」となってしまいます。
これって要するに
「スキの反対は、『スキじゃない』」
「キライの反対は、『キライじゃない』」
「無関心の反対は、『無関心じゃない』」
と言っているようなものです。
ものを知らない子供の発想です。
当然、国語のテストなら『０点』となっていることでしょう。
もちろん、ソフトウェア品質としても認められません。
ですが、ソフトウェア開発の世界ではそれがまかり通ってしまうんです。この程度のことも理解できず、ただ単に定量的品質管理だけを行えば（テスト密度とバグ密度のバランスが良ければ）テスト品質について説明が可能であると考えている、あるいは妄信しているエンジニアが一定数存在しているためです。
はたしてこのような思考停止した状態で、どこかの権威をかさに着て「○○がそういったから」を乱用するようなあり方を放置していてよいのでしょうか。それでお客さまにご迷惑をかけることはないのでしょうか。
たしかに数値は説得力があります。
お客さまを説得する…あるいは納得させる材料にはなりえると私も思います。
ですが数値というのはただそれだけで効果を発揮しません。
いえむしろそこに意味を持たせなければ、如何様にも悪意に満ちた用い方が可能となってしまいます。
前提として
「その数値の使い方が正しいこと」
「その数値に至るまでの背景に誤りがないこと」
をしっかりと証明しておいてこそ、数値は最大限の効果を発揮します。
数値に意味づけをするのはあくまでその数値を用いる人間の仕事です。そのことを忘れ、ただ盲目的に数値を使えばいいとしか思っていない人に正しく数値を使いこなすことは絶対にできません。
「なぜ、その数値が正しいといえるのか？」
「その数値に対する結論に誤りがあった場合、あなたは責任が取れるのか？」
「『○○がそう言ったから』というが、その内容に誤りがあった場合
○○が代わりに責任を取るということか？」
と聞かれて、理路整然と答えられるのであれば問題はないと思います。
要するに
「山田が死んだらお前も死ぬんか」説
これが成立するということですしね。
そうでないのであればまず自分なりに理論を構築し、引用元はその裏付けとしてのみ用いるようにしましょう。曰く
「○○がそういったから」
判断や行動を起こすのではなく
「こういう理屈のもとにそうすることを決めました。 ←ここまでで説得する
これは○○でも同様のことが定義されています」 ←ここはただの後押し
としましょう。
自分の中で納得できる答えを持たず、見出そうとする姿勢もなく、他者からなんとなく答えらしいものを得るだけで満足するのは「自らの中に何一つ答えを持っていない」し「持つ気がない」という証拠でもあります。
ただ他人の解答用紙を写しただけでしかありませんし、それで問題が起きたときは他責にするといっているようなものです。そしてなにより「なぜそうする必要があるのか」「その選択が適切かどうか」に対する理解が伴っていないわけですから、自身の成長にはまったく寄与しません。
昨今ではそういったエンジニアをよく見かける点、そしてそうした状況に何の疑念も持っていないシニア層が多い点が目立つようになった気がします。
そのせいか、ちょっと業界全体の不安を覚えます。
いただいたサポートは、全額本noteへの執筆…記載活動、およびそのための情報収集活動に使わせていただきます。