事なかれ主義では決して「品質」関連の仕事ができない
これは、JSTQB(Japan Software Testing Qualifications Board)の定める
「テストの7原則」
からも読み取ることが可能です。
JQSTB資格試験については、あまり「資格手当」対象に含められていないIT企業が多いのではないでしょうか。「モノづくりさえできればテストの仕方や品質なんてどうとでもなるんじゃないの?」なんていい加減な姿勢の企業では推進されていないのかもしれません。
しかし、ここに書かれている通りソフトウェアテストによって自らの作った製品の品質が「大丈夫である」と言い切るためには、何を以って『大丈夫』と言えばいいのかその源流を知っておくべきでしょう。
IT企業に依頼するユーザー企業は、IT企業から提案を受ける際に確認する質問に次のことを加えてみるといいかもしれません。
何も知らないエンジニアが、なんとなくの経験則だけでモノづくりを行い、経験則だけでテストする…なんてことも案外ザラにあります。私自身、独学で色々と勉強しなければ何もわからないままでした。会社から何か1つでも教えてもらったことはありません。
そんな状態のままで、エンジニアは何を以って品質を保証するのでしょう。
さて。
表題にある「事なかれ主義者」…つまりは「波風立てないようにふるまう傾向の強い人」が、なぜ品質に関わる仕事を全うできないか。それは7原則でいうところの
全数テストは不可能
テストは「欠陥がある」ことしか示せない
という原則に由来します。
エンジニアのみなさんは、自分自身が開発したソフトウェアに対して全数テストをしたことがありますか?
"全数テスト"とは、入力できる値の範囲すべて、表現できる精度すべてに対して可能性のあるものはたった1つも略さずに全部テストしきることです。
たとえば、ある入力項目の仕様が「10桁まで入力可能な金額」と定められているとします。大きめの販管システムなら10桁程度普通にあります。金融機関であれば12~13桁が一般的です。
金額ですから、一般的な操作として
「マイナスはない」
「小数はない」
と仮定すると、-1~10,000,000,000(11桁の初期値)まで、100億件超のケースをすべて一つひとつ確認するということです(-1と10,000,000,000は異常系確認)。
常識的に考えて、時間がかかりすぎるため現実的には無理ですよね。
だからこそ「同値分割」や「境界値分析」と言った統計的なテスト手法が生み出されているわけです。全数のテストができない以上、『完璧』な品質を物理的に保証することは不可能です。同値分割や境界値分析は、論理的な観点によって少ないケースから品質を保証する仕組みです。
そのため『論理的に問題がある部分』をおざなりにする人には、絶対に品質を保証しきることができないのです。
だから、問題点や疑問点が浮上した時に、それをそのままにして解決あるいはあるべき姿をハッキリさせずになんとかその場を波風たたせないようにとばかり考えるような事なかれ主義的に次に進めようとする人は妥協を優先してしまうがために、なにかしら/どこかしらの品質が低下しやすくなります。
わかりやすく言うならば、なによりも波風立たせないようにすることを優先するがゆえに、
信用することができない
のです。当然、信用することができない人が保証する「品質」も信用できません。信用に足る論理的な説明が伴わないからです。
たとえば、
「〇〇は□□である。ゆえに△△である」
という表現の文章があったとします。これ、論理的思考っぽく書かれていますが実はまったく論理的ではありません。個人的には"エセロジカルシンキング"と呼んでいます。
論理的思考では「演繹法(えんえきほう)」と「帰納法」という表現方法がありますが、上記の表現はそのどちらにも該当しません。
どちらかと言うと演繹法に近いのですが、演繹法は別名「三段論法」とも言われていて、正確には
「〇〇は□□である。
□□は△△である。
ゆえに〇〇は△△である」
と導き出すものです。
見ての通り、まったく言っている論点が異なることがわかります。
前者は、〇〇と□□の関係をつづっていても△△との関係性が導き出されていません。表現方法だけが論理的っぽく見えるだけで、論理的でもなんでもなくただの短絡思考でしかないことがわかります。
具体的には
「んー…メモリ 0x0001(〇〇)には "1"(□□) が入っている。
じゃあ、今日はカレー(△△)が食べたい」
と言っているようなものです。ただの破天荒なわがままキャラにしか見えませんね。どの辺が論理的だと言うのでしょう。
ですが、これが普段ロジカルシンキングに触れていない人が聞くと、コロッと騙されてしまいやすいんですね。組織の中でも「アイツはできるヤツ」なんて言われ方をすることもあるんですけど、実際には詐欺と変わりませんので注意が必要です。
日本語表現1つとっても、このように
「これ、おかしいんじゃないの?」
という部分は数多く発見できます。
もしも、ソフトウェア開発の中でドキュメントレビューする側の立場に立つ人が、こうしたおかしい部分をそのままにしておいてなんとなくわかったつもりになって先に進めてしまった場合、レビュー自体は素通りするかもしれませんが、その文章を受け取った他の人がレビュアーと同じように空気を読んで解釈し、同じ理解に達するでしょうか?
おかしい部分に対して明確に「おかしい」と言及せず、
たとえば
「まぁ、時間も圧してるから」
「言いたいことは分かったから」
といって品質上の課題を明確にすることもなく、おざなりにするような事なかれ主義者であった場合、本当にその先の作業や活動、事業は真っ当に進むと断言できるでしょうか。
答えは「No」です。
その後、指示を受けて活動する多くのメンバーのうち1人でも解釈を誤れば、それはプロジェクト活動そのものに欠陥が生じるということです。
その責任を負う覚悟を持ったうえでおざなりにしているのでしょうか。
そもそも"時間が圧してるから"なんて理由で品質を疎かにしてもいいと思っている人に、品質を語る資格なんてありません。
7原則にある
「テストは「欠陥がある」ことしか示せない」
は全数が確認できないからこそ出てくる因果関係のある原則です。
実際には全数を確認したところで
「「欠陥がある」ことを確認できなかった。
だから、この製品には「欠陥がない」と判断する。」
と言うことしかできません。
さらに、実際には全数テストすることは無理なので、物理的に証明することは困難どころではなく不可能です。
そもそも「欠陥がない」ことは説明ができません。
どんなに正しく動いているように見えていても、中の動作はおかしな動作をしていてたまたま期待した通りの結果だった…と言うことはブラックボックステストであればよくあることです。
ですから物理的には当然、論理的にも「欠陥がある」ことを証明できなかったので、「ゆえに、欠陥はないと判断する」という論法の持っていき方しかできないのです。
こうした背景から、事なかれ主義な人が品質に携わり、事なかれ主義的に
「おかしい」ポイントを適当に流すようなことをしてしまうと、必ず悪意のない"欠陥の隠蔽"を招き、品質を損なうことになってしまいます。
こうしたことは日頃の様々な「評価」活動でも同じことが言えます。
ソフトウェアを含む製品の品質に限った話ではありません。
日頃の業務品質に多大な影響を与えるのです。
たとえば、
"部下の報告を聞く上司"
その報告から何かを読み取り、判断や決断をしたり、次の指示を出したりしますよね。報告内容におかしな点を見つけても、そのまま放置していれば部下は誤った育ち方しかできなくなってしまいます。
自己啓発させようにも部下は自分が誤っていることに気付いていないため、一生啓発することができません。
たったこれだけのことで上司による部下の育成が滞ることになります。
ちょっとしたことに対して「ちょっとしたこと」なだけに、うやむやのまま前に進めることばかり考える人がいます。
しかし、些細だからと言ってうやむやにするという決断は、その決断に見合った大きな責任が伴うことを忘れてはいけません。
「細かい」と言われるかもしれませんが、なんでもかんでも細かいことが非難されるような社会は適切な社会とは言えません。
物事によって求められる粒度(細かさ)はすべて異なります。
そして「細かいなぁ」と言うほぼすべての人は、
「じゃあどの程度の粒度が適切で正しいと断言できるのか?」
と言われるとまともに回答できないでしょう。非難する人は、自分のゆるい既得権益をただ守りたいがために、まともに評価しようとする他人をただ貶めようとしているにすぎないからです。
自らの携わる『業務』に対する品質意識の高い人は、決して粗い粒度で物事を見ることはありません(できません)。
業務に従事する以上、その業務によって得られる対価(お客さまからの支払いや、個人への給与)を常に確認し、プロフェッショナルとしての「責任」を自覚しているからです。
タイトルでは「品質関連」と記述していますが、これはソフトウェア品質だけの話ではないと言うことを肝に銘じておいてください。社会人として、与えられた役割としての質が問われているのです。
いただいたサポートは、全額本noteへの執筆…記載活動、およびそのための情報収集活動に使わせていただきます。