ソフトウェアQAの効果
「ソフトウェアテストの効果」というタイトルのブログを書きました。これと同じようによく議論されるのがQAの効果だと思います。私の考えをお伝えしたいと思います。長めなので、歩きながら等で音声で聞きたいという方はこちらをどうぞ。
QAというのは、Quality Assuranceの頭文字を取ったもので、品質保証の意味です。どこでも通用するようなQAの定義は簡単ではないので、ここでは、QAはソフトウェアテスト活動を含む品質保証／向上活動全般を指しています。
テストはプログラムを動かすことでバグを見つける活動です。対して品質保証は、それを含んで、バグの混入を未然に防止したり、まだバグとは言えないけれど将来バグになるような問題を混入させないようにしたりする活動です。
例えば、コードレビューの目的はバグを見つけることと将来のコード変更をしやすくすることの2つに大別できます。このうち、バグを見つけるためのコードレビューを実行すれば、それはテストに先立ってバグを見つけていることになります。また、つまり将来の変更のしやすさのために保守性を上げるような指摘をすれば、これも潜在的なバグを見つけているとみなすことができます。ですので、コードレビューも品質保証活動の一つと言えます。
その他にも、仕様やユーザーストーリー間の一貫性の確認、あるいは「このユーザーストーリーを実装してテストしようとすると、このイテレーションやスプリント内では時間が足りないのではないか」といった指摘も、急いで開発することによるバグの作り込みを防いでいるため、ある意味で品質保証活動と見なせます。ただ、急いでいると必ずバグが混入するとは言い切れないので、このあたりは品質保証活動かどうか少し見分けがつきにくくなってきます。
さらに見分けがつきにくくなりますが、アンチパターン(べからず集)を知っていることで余計なバグを作り込まずに済んだり、チームでルールを作って守ることで一貫性ができ、一貫性がないときと比べると作り直しや手戻りが減ったりすれば、それもある意味で品質保証活動の一つと言えます。
簡単な一貫性の例を挙げると、ユーザーインタフェース(画面)のあるソフトウェアを複数人で開発する際、画面のレイアウトや操作方法に一貫性がないと、ユーザーは戸惑うことがあります。そのため、一貫性がないことがテストでわかると、一度作ったものを修正しないといけなくなる場合があります。しかし、事前に一貫性のルールを決めておけば、ある程度防げるため、これも品質保証活動の側面を持ちます。
さらに範囲を広げるともはや品質保証活動とは別の活動に見えますが「知っておけばミスをしない」という知識やノウハウを共有することも品質向上につながります。また、研修で学んだ内容が未然防止につながれば、それ自体も見方によっては品質保証活動になります。
また、プロセス改善も手順を変えることでバグや問題の作り込みを防ぐことにつながるため、品質保証活動の一つとして位置づけることもできます。ただし、明確に定義されたプロセス通りに実行する開発スタイルの場合、プロセス改善専門のエンジニアや担当者がいるかもしれません。その場合は「これは品質保証活動ではありません」となるでしょう。逆に、そうした担当者がいなければ、プロセス改善自体も品質保証活動と考えることができます。どこでも通用するQAの定義が難しいのはこのあたりにあります。
少し長くなりましたが、ここまでがこのブログエントリでのQAの定義です。QAの効果の話に入る前に効果のほうについても前提を置いておいたほうがよいので、先に書きます。ソフトウェアテストの効果でも書いたので、そちらをご覧の方は読み飛ばしてくださればと思います。
一般的に効果とは便益やメリットといった「良いこと」がどれだけ、またはどのくらい「良いこと」が手に入るかを指します。「効果が大きい」とは、とても良いことが起きたり、それらがたくさん手に入ったりすることを指します。
効果と同時に使われる言葉に「効率」があります。効率は、便益やメリットをどれだけのコスト（手間や時間など）で得られるかを示し、少ないコストで得られれば「効率が高い」と言います。
そうすると効果と効率は別ものということになりますが、コストパフォーマンスの意味で、ほどよい効果をほどよいコストで手に入れることを「効果」と説明する場合があります。「QAの効果」「ソフトウェアテストの効果」と言う場合に、コスト度外視で便益やメリットだけを指していることは少ないと思います。
これらの前提をもとに「QAの効果」を説明したいと思います。
QAの効果はソフトウェアテストの効果に比べて、より分かりにくいという課題があります。なぜなら、テストでは「確かに間違っていますね」という形で伝えたり、イシューやバグレポートを書くことで具体化されるからです。それにより、修正しなかった場合に比べて品質の高いものをリリースできたこと(テストの効果)がチームにも認識されます。
QAの活動にはテストも含まれるため、テストでバグを見つければQAの効果として認識できます。コードレビューなどで「こうした方がいいのでは」と提案することも同じように認識されます。
しかし、上のQAの活動には未然防止やルール決めといった内容もあるので、テストに比べると認識しづらいものがあります。例えば、「この仕様はそもそも大丈夫か」「ユーザーにとって一貫性がないので、操作方法のルールを考えよう」といった活動は、「期待する結果と違う」という明確なバグに比べると、認識しづらくなります。
こうした知識や事前のルールのおかげでバグの混入を未然に防げた場合、これはテストにはないQAの大きな効果なのですが、「このルールがあったからバグを入れずに済んだ」とか「このルールのおかげで一貫性が保てて手戻りが減った」と毎回認識できるかというと、そうはいきません。
バグの場合は「このバグを修正する時間と確認時間、回帰テストの時間を省略できた」とはっきりと効果が認識できます。一方で未然防止の場合、「もし防止できていなかったら、これだけの時間がかかっていたはずだ」とはなかなか認識できず、これがQAの効果がテストの効果よりも分かりにくくなると私が考える理由です。
さらにここがもっとも悩ましいところですが、未然防止の方が、バグとなったものを修正するよりも、開発コストとしてははるかに効率が良いのです。そもそも間違いがないので、修正や修正確認といった手戻りがない分、効率がよくなります。
ただ、未然防止が実現できたとき、それがQA活動のおかげなのか、もともと開発関係者のスキルが高く注意深かったからなのか、その線引きは曖昧になります。その結果、「QAにこれだけコストをかけているが、本当に効果があるのか？」と問われた際に、「このような未然防止がQAのおかげでできています」と説明できるかどうかは明確ではありません。
これはソフトウェア開発に限りませんが、問題が起きてから「見つけて対策しました」という活動のほうが、問題が起きないように先回りしたほうがスムーズに開発が進める活動よりもわかりやすく目立ってしまう、という難しさがあるためです。未然防止の活動の重要性について合意形成を図り、その効果を認めてもらうことは、どこでもできるというわけではないという印象です。
未然防止により手戻りを減らすことの重要性を身をもって理解している人にとっては、それもQAやチームの効果や能力だと認識できます。しかし、認識できないと「問題なく進んでいるのに、QAは本当に必要なのか？」という疑問が生まれやすくなります。
この「ソフトウェアテストの効果」や「QAの効果」というテーマは、もともと私がソフトウェアレビューの研究を始めるころから考えていたものです。「どういうレビューに効果があり、どういうレビューは効果が出ないのか」を調べようとしたことがきっかけでした。その具体例や考え方、どういう場合にコストが効果を上回ってしまうのか、そしてそのアンチパターンなどをまとめた『間違いだらけの設計レビュー』という本を書いています。まだ読んだことがなく、書店などで見かける機会があれば、覗いてみてください。