品質とQAに関するポジションペーパー
はじめに
本記事は「QAなんもわからん会」に参加される皆様に、「なんかわかる人」として参加する私のQAのスタンスについて理解していただくための、かなり強めの自己開示です。
テキストで指摘されると多分傷つくので、こちらにコメントする場合はぜひなんもわからん会で指摘してください。
QAのあり方やテストエンジニアのあり方は様々です。
同じ組織の中でも、その人が”いい”と思っている価値観次第でQAに対して思っていることや、やりたいことが違ったりします。
ですので、特にQAの人に向けて、私のスタンスを理解してもらうために文書化しました。
実務において全ての仕事がこれら思想に基づいて行われているわけではなく、実際は組織の要請や周りのニーズ確認しながら、より役に立つQAエンジニアであることを心がけています。
ここに記載する内容に極端なこだわりがあり、絶対にそうしたいと思っているわけではないので、ご理解ください。
また、実際の業務において、「品質」や「ソフトウェアテスト」について説明する場合は、もっと汎用的で役に立つ定義を話します。
そしてこれを読んでいるあなたがQAエンジニアだった場合、あなたにこの記事に記載のある内容を強要したいとは思っていません。
共感してもらえると嬉しいですが、いろんな人がいろんな考えで誇りを持ってQAエンジニアをやっていると思っています。
私はそういった皆様の普段の働きを否定したいとは思っていません。むしろ尊重したいと思っています。
ごまずんのコンテキスト
私は今までテストの専門家、Dirty Testerとして活動してきました。
テスターとしては第三者検証会社の派遣テスターとしてスタートして、現在はSaaS会社でバキバキQAとして活動しています。(そして、Dirty Testerでもあり続けます)
これまで私は一貫して「プロダクトコードを書く」という活動をしたことがなく、品質保証の活動としては動的テストを主戦場としていました。
テストの専門家として「品質を保証する」とはどんなことかを考え続けてきました。
思えば今まで、テスターとして第三者のゲートキーパーとして働くことが多く、「品質の門番」として品質の説明責任を一手に引き受けているようなポジションが多かったです。
その中で思ったことは「しんどいな」ということです。
QAだけが品質保証の責任を担うことは、自分にとっては結構な精神的負荷がかかることでした。
品質とはなにか
品質の定義
2024年現在、「品質」とは「組織が想像する顧客にとっての価値」だと考えています。
「顧客にとっての価値」を満たすことで、社会貢献を行い、営利企業として永遠に持続することが究極の目的だと考えています。
「組織が想像する」とは、顧客のニーズが未確定であることを表しています。
一方、「実際の顧客」の言うことをないがしろにしてもいいのか？というのも違います。
顧客の声は聞くべきだと考えます。
ただ、「実際の顧客」の言うことをすべて聞いても、価値を最大化することに繋がらない場合もあるのではないかと考えています。
この考えは「顧客の声さえ聞いてれば適切なソリューションを提供できるとは限らない」という私の過去の営業としての経験から来ています。
ですので、顧客の声を超え、ニーズを先回りして、「どうあるべきか」を考え抜くというニュアンスを”想像”に含めています。
ワインバーグの「誰かにとっての価値」は、示唆の多い定義ですが、品質の定義として考えるべきことが広すぎて様々なステークホルダを認識しないといけない都合上、私の定義としては不採用としています。(ただし、重要な定義だと考えています)
一方「品質は顧客の価値基準で決まる」といったような定義は多くありますが、こちらにはおおむね同意しています。
営利企業において、顧客が最も重要なステークホルダーであり、品質を考える際には顧客に対して集中すべきだと考えるからです。
前述の品質の定義で「2024年現在」と記載したのは、今後のソフトウェアの発展により、一組織としての営利活動だけでなく、社会に対する責任が問われる場合があると考えてるからです。
AIの倫理は言うまでもないですが、特にプロダクトそのものがどのような価値を”善きもの”とするのか、正義とするかが問われる時代がやってくると思っています。
smalltalk「品質モデル:狩野モデル」
“品質”という言葉について、一般的には「レスポンスが速い」や「バグが少ない」などの言葉が使われ、”価値”という言葉が使われない傾向があるらしいです。
そういった場合の整理に使える品質モデルが”狩野モデル”です。
狩野モデルは製品の品質要素について「当たり前品質」「一元的品質」「魅力的品質」などに分類して、それぞれの充足度の特性を定義しています。
その他、品質の定義や品質のライフサイクルなど、示唆の多い品質モデルとなっています。
品質はどうやって判断するのか
「品質」を測る基準は様々ありえると思ってます。
広い意味では「品質水準」として扱われ、狭い意味では「テストケース」といった単位でも扱われると思います。
これらは営利企業として「価値があることを証明するための仮説」と考えています。
そのため、品質が満たされるかどうかの仮説の検証は究極的には結果で判断しなければならないと考えています。
検証結果として最もシンプルな指標は売上だと考えています。
QAとはなにか
QAと一言で言いますが、私は”QAという活動”と、”QAというロール”、ふたつの使われ方があると考えています。
もっと多いかもしれませんが、とりあえず2つの使われ方で述べたいと思います。
QAという活動
QAという活動におけるQAとは、品質保証の活動のことを言います。
“保証”とは「間違いないと確信して、責任を持つこと」だと思っています。
本記事での品質の定義を引用しつつ定義すれば「組織が想像する顧客にとっての価値を届けるために、きちんと納得して、説明責任を果たすこと」です。
QAという活動はあくまで”活動”であり、QAがやったからQAというものではありません。(QAさんQAして〜みたいな言葉をよく聞きます)
私は誰が行っていてもQAだと思います。
QAとは会社全体で行うものであり、ソフトウェア開発、セールス、マーケ、そしてビジネスを含めた全体で、持続的に価値を届けるために必要な活動だと考えます。
「いや、QAがQAのすべてを担うべきだ」という意見があると思いますが、私は別の考えを持っています。
なぜなら「価値を届ける」ということはソフトウェア開発のみで成り立っておらず、会社全体が価値を届けることに力を注ぐことで、ビジネスとして成り立つと考えるからです。
QAというロール
ではQAというロールは何なのかというと、実はいろいろあります。
詳しくはQMファンネルを参照してください。
また、私の上記のQMファンネルに対する批判とアンサーについても熟読してください。
ここではQAというロールについて、私が目指す２つのQAエンジニア像を例に取り上げます。
「顧客に価値を届けるためになんでもするエンジニア」
QAはテストだけにフォーカスするのではなく、ビジネスの起案から製品の運用まで(場合によっては廃棄まで)、あらゆるフェーズでエンジニアリングの技術を発揮して、推進していく人のことを想起しています。
私はそれを「フルスタックQAエンジニア」とも呼んでいます。
「品質保証を推進するために活動するQA分野に専門性を持ったエンジニア」
会社に所属する全ての人が、顧客に価値を届ける活動に専念するために、品質保証の技術を分け与えるアンパンマンのような人を想起しています。
QAとしての専門性をQA以外の他のロールの人にも発揮してもらうことで、適切なタイミングで、適切な品質保証活動を実施できることを目的としています。
smalltalk「QAとQC」
QAとQCという概念が存在します。
詳しくはJSTQB FLV4.0に記載されています。
https://jstqb.jp/dl/JSTQB-SyllabusFoundation_VersionV40.J01.pdf
本記事では、QCとQAは区別していません。
それは私があまり理解していないからです。
ただ、私の目指すべきQA像はプロセス指向の予防的アプローチなのかなと思いました。
品質保証の位置づけ
組織ごとに違う品質保証
品質保証のあり方は会社の品質保証に対する考え方に依存すると考えます。
会社として、どの程度品質を保証するかは、社会的な要請やリスクを鑑みた上で、ビジネス的なトレードオフによってなされるべきだと考えています。
極論「バグゼロで出荷すべき」「品質保証は全部システムテストだけでやるべき」「品質保証はしない」という会社があれば、それに従うのもまた、QAというロールになると思います。
そういった経営層の意思決定についてはとやかく言わない私のスタンスです。
ただ、私はそういう会社に在籍したことがないですし、在籍したいと思ったことはありません。
smalltalk 「”品質を上げること”はQAの責務なのか？」
QAというのは”Quality Assuarance”ということなので品質の”保証”となります。
“品質を上げる”というのはQAの責務かと言われると少し悩ましいです。
直接的に”品質を上げる”ことができるのは、プロダクトコードを書く開発者やSRE、CSやUSなどのサポート部門だと考えています。
QAというロールで閉じた話をすれば、やはり「品質の確認」によって「品質を上げるための情報提供やサポートを行っている」というのが私の意見です。
でも、私としては「品質を上げる」までやりたいです。
なのでここの整合性を保つ論理を誰か考えて欲しいです。
「情報提供することで間接的に品質を上げることに貢献している」とか「プロセス品質により品質に貢献している」とか「QAが品質水準を上げる」とかで成り立つのかしら…？
品質はどこまで保証すべきか
答えのない品質保証
「品質はどこまで保証すべきか」というものに明確な答えはありません。
なぜならビジネス(ここではソフトウェアを使ったビジネスのこと)とは「市場に受け入れられるかどうか」「市場に出たことによる瑕疵担保はないか」などの観点から相対的にビジネス的に受け入れられる”出荷可能な状態”を定義して、不確実な中で市場での仮説検証を回す性質があるからです。
出荷可能状態とは
品質保証するための活動(例えばテスト)を全ての時間を使って行っていると、いつまでたっても製品が出荷できないという意思決定がされる場合があります。この場合、ビジネスとして成り立ちません。
一方で、品質保証を一切行わない状態で出荷しても市場に受け入れられなかったり、下手したら市場での問題で瑕疵担保による損害賠償に発展する場合があります。
そうしたトレードオフの中で、出荷可能状態、つまりは「我々はここまでやったから大丈夫」という”納得感”を形成して、組織として自信を持って出荷することが、品質保証において大切だと私は考えます。
“出荷可能”が示す水準はその組織によって異なるものだと考えています。
「QAさんに任せたから大丈夫」ではなく、組織として説明責任を果たすことが重要だと私は考えます。
smalltalk 「出荷可能と判断するのがQAでは？」
「出荷可能と判断するのはQAでは？」については、答えづらい質問だと思いました。
ビジネスのスタイルとして、以下のような取り組みをしている場合は「組織として出荷可能」論とは相容れないと考えました。
QCDの観点で責任を分離して、認知的負荷を下げるような取り組みをしている場合
シックスシグマなどの品質判定技術を用いて、出荷判定を一任され、品質ゲートとなっている場合
また、ミッションクリティカルであったり、人の生命に関わる、”出荷可能状態”に大きな責任が伴う製品について、専門家の目線から出荷可能と判定するのも重要だと考えました。
実際に我々は日々そういった製品を使用しています。
そして、それらの品質保証によって生命や財産が守られています。
ここではただのテスターの雄、おおひらさんの教えに従って考えると良いのかなと思いました。
「作りたいモノ(ゴール)による」
ゴールの意思決定を経営層が明示的に行い、組織の責任分担をWhyのレベルでどこまで定義するかによってあるべき姿は変わると思います。
日本の伝統的品質管理では品質管理が経営でコントロールする事項とされていますが、おそらく新興のIT企業ではそこまで規定されていないと思います。
「経営層や周りのチームとのゴールの認識合わせを行いながら、QAの責務について考えることが必要」
というやや中庸的な内容ですが、私の現在の認識です。
テストとはどういう位置づけか
テストとは、品質を”保証”するための最も重要な活動のひとつです。
製品が価値を届けることをテストで確認することによって、出荷可能な状態であるということに自信を持つことが必要になります。
テストには中間成果物やコードを確認する静的テストと、実際の動作を確認する動的テストがあります。
私は動的テストの専門家なので、動的テストについて記載します。
動的テストで収集できる情報は”事実”であるということがとても重要であると考えています。
テストケースという仮説に対応する事実です。
事実の積み重ねによって出荷可能状態かどうかの経営判断を後押しすることが必要になります。
QAエンジニアはどう生きたらいいのか
ぜひ、JaSST’24関西に参加してください。
テーマ:「QAはどう生きるか～テストと品質保証の枠を越えて」
JaSST’24 Kansaiに来れなかった人はテストの街葛飾へ
おわりに
本記事は
Spiritual Powered by テストの街葛飾
参考文献にした文献
「QAエンジニアってなんなの？」
参考になるけど、今回の記事には反映していない文献
「品質保証（QA）とは。定義の三大流派と定義揺れの弊害」
本当のおわりに
こうやって考えると、なんかやっぱり「QAエンジニア」って名乗るのは荷が重い気がしてきました。
やっぱ私はDirty TesterでバキバキQAです。
時間があったら「QAの社会学」とかも記載したいなあ。
この記事が気に入ったらサポートをしてみませんか？