2023.03.27
本コラムはテスト分析手法「ゆもつよメソッド」で有名な湯本 剛氏（freee株式会社／株式会社ytte Lab）による連載コンテンツです。
湯本氏のnote「テストマネジメント虎の巻」はこちら
第1回：いまどきのソフトウェア開発に求められるもの 第2回：新しい開発スタイルの概要 第3回：新しい開発スタイルに合わせたテストの概要 第4回：開発チームとテストチームの関係～成功のための大事な役割～ 第5回：品質リスク（プロジェクトリスク・プロダクトリスク）の許容度合い 第6回：テストレベル間のテスト量の関係は？テストピラミッドとの関係も
第7回：品質リスク（プロジェクトリスク・プロダクトリスク）の許容度合い
本連載では、ソフトウェアテストをする際には、ビジネスの成功に貢献するという本来の目的を意識しながら、これからの開発に役立つことを考えていくことが重要だと説明してきました。考えていくべきことは、以下の４つになります。
- 開発チームとテストチームの関係
- 品質リスクの許容度合い
- テストレベル間のテスト量の関係
- QA（Quality Assurance）の考え方
最終回となる今回は「QA（Quality Assurance）の考え方」について、まずはQA（Quality Assurance）の定義を確認し、これまでのQAの課題、およびビジネスの成功に貢献するためにはどうすべきかといった流れで深掘りしていきます。
- もくじ
1．QA（Quality Assurance）の定義
ISTQBの用語集[1]ではQA（Quality Assurance）を「品質保証」と訳しています。定義は以下のようになります。
品質保証：品質要件が満たされるという確信を提供することに焦点を当てた活動。
ISTQBによる品質保証の定義を確認すると、「保証」という言葉が一般的に持つ「物や人に責任を持ち、欠陥があったら損害の責任を引き受ける。」というニュアンスとは異なると感じている人もいると思います。日本語訳の「保証」はAssuranceを訳したものです。AssuranceはAssureの名詞形です。Assureの意味は「誰かの何かに対する心配を減らす」になります。「確信を提供することに焦点を当てた活動」というのは、翻訳的で分かりづらいのですが、「誰かの何かに対する不安を取り除くことに注力する活動」だと考えればわかりやすいかと思います。電通大の西先生は、このことをさらにわかりやすく「納得感の共感」と呼んでいます。[2]
また、QAとテストは同じではありません。このことは、JSTQBのFL2018シラバスの「1.2.2品質保証とテスト」という節の冒頭にて「品質保証（または単にQAともいう）という用語がテストを意味するために使われることがある。しかし、品質保証とテストは、関連してはいるが同じではない。」と書かれています。
2．日本の品質保証の変遷
品質保証（日本ではQAを品質保証と呼ばれているのでこの節では品質保証と呼びます）の考え方には、歴史的な経緯も考慮する必要があります。日本では、欧米とは異なる、日本独自の品質保証の考え方があり、その背景には、新品の補償（損害・費用などを補いつぐなう）から保証（損害の責任を引き受ける）へ発展したという経緯があると言われています。SQuBOK Guide V2 [3]に日本での品質保証の考え方の経緯が書かれているので以下に引用します。
新しい商品に対する修理や取り替えにより損失を補償する時代から、1950年代以降の家電ブームによる大量生産・大量販売とともに、購入後ある一定期間中に生じたメーカー責任の障害に対してメーカーが補償するという「品質保証書」付きでなければ売れない時代へ変わっていった。それが発展して、現在では競争力のあるサービス、製品の提供のために、お客様が「安心」「満足」「長く使用できる」ことを目的として、品質保証が実施されるようになった。
また、同書には、日本におけるソフトウェア品質保証の特徴として以下の3つがあるとしています。
- レビュー重視（早い段階から品質を作り込む）
- 障害に分析に基づく改善（同じ問題を繰り返さないように改善する）
- 独立した品質保証部門の存在（仕組みの構築、開発途中の監査、および出荷判定）
この3つの中の１つである、独立した品質保証部門が存在する経緯について同書に書かれている部分を以下に引用します。
開発部門から独立した品質保証部門が設置されていることが多い。これは、製造業における検査部門をなぞらえて設置されるようになったものと思われる。ソフトウェアにおける品質保証部門は。品質マネジメントシステムの構築、運用などの仕組みの整備に加えて、開発途中における品質監査、出荷製品の評価や出荷判定など、成果物の品質に直接関わる活動をすることが多い。成果物の品質に直接かかわる品質保証部門が存在する組織では、開発部門と品質保証部の代表からなる複数人の合議制で出荷判定を実施する。特に大企業では、最終的な出荷判定の機能を品質保証部門が保有していることが多い。
[3] SQuBOK策定部会：ソフトウェア品質知識体系ガイド第2版,オーム社(2016).
3．これまでのQAの課題
その昔、ソフトウェアは製造業で作られるハードウェア製品の部品の１つのような位置付けでした。そのため、補償から保証というQAの考え方が最も効果的だったのかもしれません。しかし、本連載の第一回目で述べたように、現代社会では多くのものの価値がソフトウェアによって決まるようになってきています。
ハードウェア製品の製造では大量に作る製品がみな同じであることを保証することが大事です。しかし、ソフトウェアの場合、作る製品は前と必ず何かが異なります。同じであればコピーができるため作る必要がありません。
これまでのQAの考え方で有効なこともたくさんあり、学ぶこともたくさんあります。しかし、ビジネスの成功に貢献するためにはトライアルアンドエラーができる開発とチームの垣根を超えた開発を行うことが大事であると本連載で一貫して説明してきた経緯から考えると、これからは変えていくべきことも出てきます。
4．これからも有効なこと
- 競争力のあるサービスや製品を提供するために、お客様のことを考える
- 早い段階から品質を作り込む
- 同じ問題を繰り返さないように改善をする
いままでもこれからも競争力のあるサービス、製品を提供することが大事なことは変わりありません。そのためにはお客様のことを考えるのがとても大事であることも変わらないでしょう。また、早い段階から品質を作り込むことや同じ間違いを繰り返さないように改善することも今までと同様に重要なこととなります。
ただし、本連載の第一回で述べたとおり、現代社会は、本当にお客様にとって価値があるものは何かということがわかりづらく、短期間の間に変わっていく可能性があることを忘れてはいけません。
5．これからは変えていくべきこと
- リリース時に保証をする
- 独立した部門が開発途中に品質監査を行う
- 各部門の代表が集まり出荷判定を行う、および独立した部門が出荷判定を行う
「リリース時に保証をする」は、日本の品質保証の変遷についての引用にかかれている「品質保証書をつける」を筆者が解釈して言い方を変えたものです。リリース時点で「安心」「満足」「長く使用できる」ことをどこまで責任持つかは見直す必要があります。これは過去の連載で述べた品質リスクの許容度合いをマネジメントすることで実現します。
また、独立した部門が監査をしたり、出荷判定をしたりするためにはさまざまな証拠を集める必要があり、開発スピードの妨げになります。また、別の部門の人たちが新しい開発スタイルの中で途中から入ってきて最新の状況を把握したうえで的確な判断をするのは困難です。これに対しては開発チームとテストチームの関係で述べたようにチームの中にQAが内在するアプローチが有効です。
6．チーム自身が継続的品質改善をしていくのがこれからのQA
ビジネスの成功に貢献するためにトライアルアンドエラーができる開発とチームの垣根を超えた開発を行うことが大事であり、それらの実現のためにソフトウェア開発の新しいスタイルが浸透してきていること、新しいスタイルに合わせたソフトウェアテストをしていく必要があることを考慮すると、これからはチーム全員が納得感を共有できるようにしていくのがQAの仕事になると考えられます。QAは専任者がいてもよいですし、チームのだれかが兼任でもよいかもしれませんが、チームに内在してチームの状況を把握できていることが大事です。
そして、品質リスクをマネジメントするためにテスト結果や欠陥情報といったデータを分析し、チーム内にフィードバックしていくのが重要な役割になるでしょう。そして、トライアルアンドエラーができる開発をしていくことの一環として品質を向上させる改善サイクルを回し続けていくことを目指します。ソフトウェアテストは、改善サイクルを回し続けていくための情報源として活用できるほど納得感の共有に役立ちます。
おわりに
今回は、「これからのQAの考え方」について深掘りをしていきました。これまでの7回で、ビジネスに貢献するためにはソフトウェアテストはどうあるべきかを書いてきました。大事なことは、ビジネスの成功のために開発スタイルが変わっていく中で、ソフトウェアテストをその変化に合わせていくことです。
これまでのテストの技術や考え方は、これからのソフトウェアテストをしていくための土台として重要なことは忘れてはいけません。土台としての技術や考え方をしっかり身につけた上で、ビジネスの成功という目的から見て変えた方が良いことは何かと考えてトライアルしていくことが、より良いソフトウェアテストをしていく近道になるでしょう。
