QAとしての自分の考えを表明するためのポジションペーパー

はじめに

本記事は「QAなんもわからん会」というイベントに「なんかわかる人」として参加した際に、私のQAのスタンスについて理解していただくために記述した、極めて強い自己開示です。 https://connpass.com/event/316195/

かなり強い自己開示であるため、テキストでの批判・批評はご遠慮いただきたいと考えています。 また、私に対してではなく、私の所属する企業や団体に対して、SNSその他の媒体を使って苦情を入れることもご遠慮いただきたいです。

あくまで私個人の考えであって、所属する団体の考えを代表するものではない点をご留意いただきたいです。

この文章の立ち位置

QAのあり方やテストエンジニアのあり方は多種多様なのが現状です。

たとえ同じ組織の中にいたとしても、その人が”いい”と思っている価値観次第で、QAに対して思っていることや、やりたいことが違っています。 そのため、本文書はとくにQAの人に向けて、私のスタンスを理解してもらうために文書化を行ないます。

ただし、実務において、すべての仕事がこれら思想に基づいて行なわれているわけではありません。

現場の私は組織の要請や周りのニーズ確認しながら、より役に立つQAエンジニアであることを第一として業務を行なっています。 ここに記載する内容へ病的・極端なこだわりがあるわけではありません。

絶対にそうしたいと思っているわけでもありません。 現場のニーズに応えながら、柔軟なスタイルと施策を行なうことを大切にするのが私のQAのスタイルです。

また、実際の業務において、「品質」や「ソフトウェアテスト」について説明する場合は、この定義と同じ表現をするとは限りません。 その人にとって、もっと汎用的で実務で役に立つ定義を使って話すことがあります。

そしてこれを読んでいるあなたがQAエンジニアだった場合、この記事に記載のある内容を強要したいとも思っていません。

ただ、共感してもらえると嬉しいと思ってはいます。

しかし、さまざな人がさまざま考えで誇りを持ってQAエンジニアをしていることは事実です。

私はそういった皆さまの普段の働きを尊重したいと考えています。

コンテキスト

私は今までテストの専門家、Dirty Testerとして活動してきました。 私のキャリアは第三者検証会社の派遣テスターとしてスタートして、現在はSaaS会社のバキバキQAです。（そして、Dirty Testerでもあります）

これまで私は一貫して「プロダクトコードを書く」という活動をしたことがなく、品質保証の活動としては動的テストを主な業務としてきました。 そして、テストの専門家として「品質を保証する」とはどんなことかを考え続けてきました。

思えば今まで、テスターとして第三者のゲートキーパーとして働くことが多く、「品質の門番」として品質の説明責任を一手に引き受けているようなポジションが多かったのです。

そのなかで思ったことは「しんどい」という一言です。

QAだけが品質保証の責任を担うことは、自分にとっては結構な精神的負荷がかかることでありました。

品質とはなにか

品質の定義

「品質」とは、あるものがいいか悪いかを端的に表した尺度だと考えています。

「品質」には「狙った品質」と「実際の品質」の2つがあると考えています。

※ここで「ねらいの品質」などの言葉を使わないことには理由があります。 それについてはsmalltalk「ねらいの品質」と「できばえの品質」を参照してください。

狙った品質

「狙った品質」とは「組織が想像する顧客にとっての価値」だと考えています。

企業の目的は、「顧客にとっての価値」を満たすことで、社会貢献を行ない、営利企業として永遠に持続することが究極の目的だと考えています。

そして、狙った品質で重要な部分は「組織が想像する」という部分です。 これは、顧客からフィードバックを得られるまで、顧客のニーズが未確定であることを表しています。

テストエンジニアにとって一番最初に意識することはこの「狙った品質」です。 顧客のフィードバック前に、「これが顧客の価値である」と想像したことに対して、アプローチする必要があると考えています。

実際の品質

一方、「実際の顧客」の言うことをないがしろにしてもいいのか？　というと、そうではありません。

実際に品質が満たされたかどうかを決めるのはあくまで「顧客」です。 「実際に使われ、顧客や社会に対していい影響を与えているかどうか」 それによって実際の品質がフィードバックされると考えます。

狙った品質と実際の品質を識別する背景

ソフトウェア開発において、顧客の声は聞くべきだと考えます。

しかし、「実際の顧客」の言うことをすべて聞いても、価値を最大化することに繋がらない場合もあるとも考えます。

この考えは「顧客の声さえ聞いてれば適切なソリューションを提供できるとは限らない」という私の過去の営業としての経験則から来ています。 だから、作り手である我々は、顧客の声を超え、ニーズを先回りする必要があります。 つまり「どうあるべきか」を考え抜く必要があるということです。

そういったニュアンスを「狙い品質」にある「想像」という言葉に含めています。

誰かにとっての価値

ワインバーグの「誰かにとっての価値」は、示唆の多い定義であると考えます。

しかしながら、品質の定義として使ってしまうと、考えるべきことが広すぎると感じています。 製品が「誰のために作られているか」「どのようなステークホルダーがいるか」は実に多様です。 そしてそれぞれの価値観は実に相対的です。 それを識別することはムダではないと考えます。

ただ、多種多様なステークホルダーを認識する前にまず、シンプルに「もっとも大事にしたい顧客のことを考えるべき」というのが私の考えです。

「品質は顧客の価値基準で決まる」といったような実際の品質に近いような定義は多くあります。 それには概ね同意しています。

営利企業において、顧客がもっとも重要なステークホルダーであり、品質を考える際には顧客に対して集中すべきだと考えています。

品質の未来

これらの品質の定義は現在執筆している2024年現在のものです。 そういうのも、今後のソフトウェアの発展により、プロダクト開発は一組織としての営利活動だけでなく、社会に対する責任が問われると考えているからです。 AIの倫理は言うまでもないが、とくにプロダクトそのものがどのような価値を”善きもの”とするのか、”正義”とするかが問われる時代がやってくると考えています。

smalltalk「品質モデル:狩野モデル」

“品質”という言葉について、一般的には「レスポンスが速い」や「バグが少ない」などの言葉が使われ、”価値”という言葉が使われないこともあります。

そういった場合の整理に使える品質モデルが「狩野モデル」だと考えます。 狩野モデルは製品の品質要素について「当たり前品質」「一元的品質」「魅力的品質」などに分類して、それぞれの充足度の特性を定義しています。

その他、品質の定義や品質のライフサイクルなど、示唆の多い品質モデルとなっています。

smalltalk「ねらいの品質」と「できばえの品質」

品質管理の言葉として、「ねらいの品質」と「できばえの品質」という言葉があります。 本稿ではあえてこの言葉を使いませんでした。

「ねらいの品質」と「できばえの品質」は西堀栄三郎が提唱した概念で、「品質管理心得帳」などの書籍で言及されています。

これらの用語を使わなかった理由として、「ねらいの品質」「できばえの品質」は、調達工程・製造工程における製品の「ばらつき」が背景にあるからです。 調達・製造における部品のばらつきはハードウェア固有の問題です。

ソフトウェア開発の文脈での品質管理は、従来の枠組みだけで語れば、設計工程での品質管理が必要になります。 これらの考えとの混同を避けるために、似たような概念を別の言葉で表現しています。

品質はどうやって測るのか

「品質」を測る基準はさまざまな場合が考えられます。

広い意味では「品質水準」として扱われ、狭い意味では「テストケース」といった単位でも扱われます。 これらは営利企業における「狙いの品質」として「価値があることを証明するための仮説」と考えています。

そのため、品質が満たされるかどうかの仮説の検証は究極的には結果で判断しなければなりません。

検証結果としてもっともシンプルな指標は売上だと考えています。

だが、これは現在の私の考えであって、永久に売上が指標となるかはわからないのが現状です。

たとえば、高価格で販売される原子力発電所を1つ売れることはボールペン1万本よりも品質が高いのでしょうか。 売上とは相対的な指標ではなく、あくまでシンプルを保ちつつ測るための指標であると私は考えています。

営業や販売の品質図るような指標としては営業利益率が妥当かもしれません。 または会社に対する投資や株価でも測れるかもしれません。

そもそもこれらは遅行的な指標であり、ソフトウェア開発には不適切かもしれません。

「品質はどうやって測るのか」に対する答えはまだまだ考察の余地があると考えています。

QAとはなにか

QAと一言で言っても、”QAという活動”と、”QAというロール”、2つの使われ方があることを私は観測しています。 突き詰めるともっと多くの切り口がありますが、本稿ではこの2つの切り口で述べたいです。

QAという活動

QAという活動における「QA」とは、品質保証の活動のことです。 “保証”とは「間違いないと確信して、責任を持つこと」だと考えます。 本稿での品質の定義を引用しつつ言葉にすれば「組織が想像する顧客にとっての価値を届けるために、きちんと納得して、説明責任を果たすこと」だと考えます。

QAという活動はあくまで”活動”であり、QAがやったからQAというものではありません。 QAさんQAして〜といった言葉があるが、私にとって、それは納得いくコミュニケーションではありません。 私は誰が行なっていてもQAだと思っています。

QAとは会社全体で行なうものであり、ソフトウェア開発、セールス、マーケティング、そして経営を含めた全体で、持続的に価値を届けるために必要な活動だと考えています。

「いや、QAがQAのすべてを担うべきだ」「QA以外の人々はQA以外のことに集中すべきだ」という意見があることは承知しています。 それらの意見があった上でも、私はこの考えを変えることはありません。

もはや「価値を届ける」ということはソフトウェア開発のみで成り立っていないというのが現状だと考えます。 品質保証のために、会社全体が価値を届けることに力を注ぐことで、ビジネスとして成り立つと考えています。

QAというロール

QAというロールについても考えたいと思います。 QAというロールの体系化はQMファンネルというもので体系化を試みているので、まだ見ていない人は確認してほしいです。 https://www.slideshare.net/YasuharuNishi/quality-management-funnel-3d-how-to-organize-qarelated-roles-and-specialties

また、私の上記のQMファンネルに対する批判とアンサーについては以下の記事で公開しています。

https://yy-world.hatenadiary.com/entry/2024/11/24/010000

https://zenn.dev/55_ymzn/articles/explaining_unclear_aspects_of_the_qm_funnel

ここでのQAというロールについて、私が目指す2つのQAエンジニア像を例に取り上げたいと思います。

「顧客に価値を届けるためになんでもするエンジニア」

QAはテストだけにフォーカスするべきではないと考えています。 ビジネスの起案から製品の運用まで（場合によっては廃棄まで）あらゆるフェーズでエンジニアリングの技術を発揮して、推進していく人のことだと考えています。 私はそれを「フルスタックQAエンジニア」とも呼んでいます。

「品質保証を推進するために活動するQA分野に専門性を持ったエンジニア」

会社に所属するすべての人が、顧客へ価値を届ける活動に専念するため、品質保証の技術を分け与える人であることを目指したいと考えています。 QAとしての活動が、QA以外の他のロールの人に実践できるように推進していく人です。

これにより、適切なタイミングで、適切な品質保証活動を実施できること目指します。

smalltalk「QAとQC」

QAとQCという概念が存在します。

詳しくはJSTQB FLV4.0に記載されているので、そちらも参照してほしいです。

https://jstqb.jp/dl/JSTQB-SyllabusFoundation_VersionV40.J01.pdf

私の目指すべきQA像はプロセス指向の予防的アプローチではないかと考えています。

ただ、本記事ではQAとQCを区別はしないことにしています。

品質保証の位置づけ

組織ごとに違う品質保証

品質保証のあり方は会社の品質保証に対する考え方に依存すると考えています。

会社として、どの程度品質を保証するかは、社会的な要請やリスクを鑑みた上で、ビジネス的なトレードオフによってなされるべきです。

「バグゼロで出荷すべき」、「品質保証は全部システムテストだけでやるべき」、「品質保証はしない」という会社があるかもしれません。 それに従うのもまた、QAというロールになると考えます。

そういった経営層の意思決定について、助言は行なうが、QAとして組織全体の意思決定をコントロールすることは望んでいません。 会社全体で納得できる品質保証のあり方を実践すべきだと考えています。

smalltalk 「”品質を上げること”はQAの責務なのか？」

QAというのは”Quality Assurance”です。 品質の”保証”です。

では、“品質を上げる”はQAの責務なのでしょうか。

私は、直接的に”品質を上げる”ことができるのは、プロダクトコードを書く開発者やSRE、CSやUSなどのサポート部門だと考えています。 QAとしてプロダクトコードを書く場合、あるいはその他保守運用等に関わる場合、QAは品質を上げていると言えるかもしれません。

一方で、QAというロールがテストを意味するのならば、やはり「品質の確認」によって「品質を上げるための情報提供やサポートを行なっている」というのが私の意見です。

しかし、私としては「品質を上げる」までやりたいと考えています。

それの言い訳として、「情報提供することで間接的に品質を上げることに貢献している」、「プロセス品質により品質に貢献している」、「QAが品質水準を上げる」などが成り立つのではないかと考えています。

品質はどこまで保証すべきか

答えのない品質保証

「品質はどこまで保証すべきか」というものに明確な答えはありません。

なぜならソフトウェアを使ったビジネスは、「市場に受け入れられるか」「市場に出たことによる瑕疵担保はないか」などの観点から相対的にビジネスとして受け入れられる”出荷可能な状態”を定義して、不確実な中で市場での仮説検証を回す性質があるからです。

出荷可能状態とは

品質保証するための活動、たとえばテストをすべての時間を使って行なっていると、いつまでたっても製品を出荷できない可能性があります。 この場合、ビジネスとして成り立ちません。

一方で、品質保証を一切行なわない状態で出荷しても市場に受け入れられない場合もあるかもしれません。 下手をしたら市場での問題が発生し、瑕疵担保による損害賠償に発展する場合もありえます。

そうしたトレードオフのなかで、出荷可能状態、つまりは「我々はここまでやったから大丈夫」という”納得感”を形成する必要があります。 これにより、組織として自信を持って出荷することが、品質保証において大切だと私は考えます。

“出荷可能”が示す水準はその組織によって異なります。

「QAさんに任せたから大丈夫」ではなく、組織として説明責任を果たすことが重要だと私は考えます。

smalltalk 「出荷可能と判断するのがQAでは？」

「出荷可能と判断するのはQAでは？」については、明確に答えが出ません。

ビジネスのスタイルとして、以下のような取り組みをしている場合は「QAではなく組織として出荷可能な状態を定義する」には当てはまらないと考えます。

とくに最後の場合は、専門家の目線から出荷可能と判定することも重要です。

実際に我々は日々そういった製品を使用しています。 そして、それらの品質保証によって生命や財産が守られていることを忘れてはいけないと思っています。

テストとはどういう位置づけか

テストとは、品質を”保証”するためのもっとも重要な活動の1つです。 製品が価値を届けられることをテストで確認することによって、出荷可能な状態であるということに自信を持つことができます。

テストには中間成果物やコードを確認する静的テストと、実際の動作を確認する動的テストが存在します。

私は動的テストの専門家であるので、動的テストについて記載します。

動的テストで収集できる情報は”事実”であるということがとても重要だと思っています。

「テストケース」という仮説に対応する”事実”です。 事実の積み重ねによって、「出荷可能状態かどうかの経営判断を推進すること」これが動的テストの位置付けだと私は考えています。

おわりに

本記事はSpiritual Powered byテストの街葛飾。

参考文献にした文献

「QAエンジニアってなんなの？」https://www.youtube.com/watch?v=gBuNtDaBBCM

参考になるが、今回の記事には反映していない文献

「品質保証（QA）とは。定義の三大流派と定義揺れの弊害」https://goyoki.hatenablog.com/entry/2023/06/04/192409本当のおわりに

本当のおわりに

こうやって考えると、なんかやっぱり「QAエンジニア」って名乗るのは荷が重いです。

やはり私はDirty TesterでバキバキQAなのです。

← Meに戻る