みなさんこんにちは。 今回は先日閲覧した記事の一文からQAについて考えたことがありましたので書いてみようと思います。
———————————————————————————————————————
◆現代ビジネス 賢者の知恵「人間対コンピュータ将棋」頂上決戦の真実【後編】一手も悪手を指さなかった三浦八段は、なぜ敗れたのか」 https://gendai.ismedia.jp/articles/-/35787
———————————————————————————————————————
上記は、2013年3月23日から5週にわたって行われたプロ棋士vsコンピュータの将棋棋戦である「第２回将棋電王戦」についての記事ですが、記事の中で、以下のような一文が出てきます。
「あの敗戦で、貴重な課題を突きつけられました。あの攻めが無理だったことは、プロの先生に負かされて初めてわかることです。ふだん、強くない相手と指していても、無理が通って勝ってしまうこともありますから、気づきにくいんです （中略） 本当に「バグ」なのかどうかは、プロ棋士でなければ正しく判定できない」
上記のような将棋ソフトは、将棋の過去の棋譜というインプットをもとにゴール（＝詰み。相手を負かすこと）までの膨大なパターンを考えて、優勢な進め方を判断していくのですが、その判断が正しいかどうかは、提供する相手である利用者（＝この場合、プロ棋士）に使ってもらってからでないと分かりにくいと言っています。
コンピュータ将棋ソフトの開発者は開発のプロですが、将棋のプロ（級の腕前）では無い方もいるので、過去の棋譜から仕様を作りプログラムを開発し、仕様通りに動かないバグを取り払いますが、実際の利用時に使えるものになっているかどうかのチェックは、対局などの実践を行うことで「品質」のチェック（プロ棋士がチェッカー）が行われていると言えそうです。
上記の場合は、プロと対局を行うこともあるコンピュータ将棋ソフトというある意味特殊な領域だと思いますので、品質の精度を測るにしても将棋がプロ級に強くないと計測者たり得ないのでしょうが、利用者が一般の方々であるサービスの場合だとどうでしょうか。
必ずしも将棋の場合と同じ状況で扱うことはできないと思いますが、普段のQAを行う場面で考えてみると、通常、バグを見つけるのは品質のプロであるQA担当者で、利用上の使いにくさなどについては一般の利用者から出てくることも多いと思います。
このバグというのは、基本的に仕様に規定された振る舞いをサービスがその通りに行ってくれない場合にバグとなり、仕様に明記されていないことはバグとして上げません。 （仕様がボロボロなので、とりあえず上げてくださいと言われたり、現場で独自のルールを決めている場合は別です）
そして、サービスに対する意見・要望を上げる可能性のある一般の利用者はサービスが世に出てからしか利用することはできません。 つまり、「使いにくい」という結果は、しばらく後になってから出てくるということになります。
QAを「品質保証」だとすれば、品質に対してどこまでかを保証すべきで、そうなると保証の範囲は「仕様で謳われた範囲」ということになるのでしょうが、仮にQAを行う目的が「サービスを利用するお客様がやりたいことができて、かつ気持ちよく使って頂くためのチェックをしていく（手伝う）」という風に考えるとすれば、仕様の確認だけに留まらず、明記されている仕様を超えてサービスに対する気づきという形で情報を提供することも役目の１つに捉えても良いと感じています。（※しかし、肝心のテスト自体が疎かになっては本末転倒ですのでそこは注意しましょう）
ケースバイケースですが、テストを行っていると、例えば「殆ど発生しないけれども、仕様とは異なるのでバグである」という扱いのものと、「仕様には明記が無いが、利用者にとって明らかに勝手の悪い操作感であり事実上のバグと言えるもの」に遭遇することがあります。
テスト（仕様に基づくもの）と気づきは作業のプライオリティを分けて考える必要がありますが、利用者が使うサービスであると考える限り、後者も意識しておくのは必要なアクションだと普段から考えるようにしています。
将棋の例ではないですが、「無理が通って勝ってしまうこともありますから、気づきにくい」現象に事前に気づくことができれば、バグが１つ減らせる可能性があり、品質向上に貢献することができます。 みなさんもテストなど行う際、このような視点を持って一度試されてはいかがでしょうか。
Tweet