※このブログに「品質保証」カテゴリを作ってしまった・・・

とボヤいてますが、Twitterでこんなボヤきをしていました。

そしたら色々とコメントをいただけて、「QAってなんや?」を自分なりに書き出してみようと思いました。

切り口は色々考えられますが、今回私が想定して(というか自分が置かれて)いるシチュエーションは、

  • JoinしたQAエンジニアとして、「QAってこういうことだと思っていますよ」「自分はQAエンジニアとしてこういうことをやろうと思っていますよ」を周りに説明する

です。

品質とは、的な切り口では、

あたりを読んでみると良いのではないでしょうか。(それか『現代品質管理総論』に手を伸ばすとか)

ただ、今回の想定シチュエーション的にはいきなり「ほらこれ読め」というのは違う&言語化をサボらないほうが良い、ということで、QAについて専門外の人(とはいえ飲食とか農業とかほどは離れていない人)に説明するつもりでつらつら書いてみます。

QA(Quality Assurance)ってなんだろう

日本語にすると「品質保証」です。そのまま解釈すると「品質」を「保証」すること、ですね。この「品質」と「保証」の2つのことばが両方とも、誰にとっても明らかにわかるものであれば、「品質保証」もみんながわかる概念になるでしょう。が、「保証」はまだ良いとして、「品質」が何なのかをハッキリ説明するのが難しいのではないでしょうか。

「品質ってのがはっきりしないんですけど、大丈夫です!保証しますよ!」なんて言っても当然誰も信用してくれません。

(ここで若干話がそれるのですが、私が上のツイートのように「弊社のチームではこれまでQAしてなかったところ、QAできるようになりました!」みたいな文章を見てモヤっとするのは、QAのQ(品質)のことをはっきりと内部でわかっていない風なままAssuranceできるようになったと言っている(と感じる)から、と気づきました)

じゃあ、QAのQ(品質)ってなんでしょうか。

品質ってなんだろう

QAエンジニアの間でも意見が割れるところでしょう。意見が割れるポイントは、品質の定義として正解不正解があるというよりは、どれが一番しっくりくるか、というところですが。(気になる人はQAエンジニアとっ捕まえて「品質ってなんだと思いますか?」と聞いて困らせましょう(困っていいのか?

さておき、品質の定義については絶対の正解はありません。『ソフトウェア品質知識体系ガイド SQuBOK Guide』など見てもらえると、色々な方の「品質とは」が載っています。

時代の移り変わりとともにソフトウェア開発も変わっているため、「品質とは」も移り変わっている部分があります。

ただ、色々な品質の定義に共通して出てくる要素として

  • 価値
  • ユーザー(受け手、顧客、など)

があります。

乱暴なまとめかたをすると、ソフトウェアなりシステムなりを使う人にどれだけの価値を提供するかが品質、と言えるよね、という話です。

※雰囲気では「そうだね」と思える一方で、リリース直後のポケモンGOなどは非常に品質が悪かったもののたくさんのユーザーが遊んでいた(≒価値がある、と思われていた)ので、ここがうまく説明できないなぁと個人的に感じています。

ここでポイントになるのは、万人が価値を感じるものは基本的にはなく、Aさんにとって価値がある≒品質が良いものは、Bさんにとっても同じとは限らない、という点です。これは直感には合っているのではないでしょうか。

品質=価値がある、ということを保証したい

ここでもとの「QA(品質保証)ってなんだろう」という問いに一度戻りましょう。

品質を保証するということは、上記の品質の定義(っぽいもの)を用いて言い換えると、「顧客にとって価値がある、ということを保証する」ことになります。

しかし、まだ、価値があるとか無いとかの抽象度は、品質が良いとか悪いとかの抽象度から変わっていないように見えます。同じくらい、まだふわっとしています。 「品質が良い、悪い」という、まだふわっとした抽象的な概念を、ブレークダウンしなければいけません。

実はここ自体が「品質保証」に含まれている、と私は捉えています。つまり、

  • 自分たちの顧客がどんな人達で
  • 顧客にとって品質が良いとはどういうことか

を考えて仮説を立てること、が品質保証(QA)活動の一部であり、同時にQAエンジニアのお仕事の一部、です。雑な言い方をすると、決まった正解がないので、自分たちで「正解はこうだ」を作るところからやるのが品質保証ではないでしょうか。

仮説を立てる、という表現をしたのは、ほんとうに価値があるかどうかは顧客が感じるものなので、QAエンジニアを含めた作り手サイドからは「こういうものは価値があるだろう」と推測するしかない、と考えたからです。自分たちの思う品質のよいものを世に出して、反応が答え合わせになる、イメージでいます。

もちろん、全ての点が仮説というわけではありません。規格によって定められた定量値があってそれを下回ったら不合格、という場合もあります。そういった類のものはもちろん満たしたうえで、の話です。

ここで自分たちの思う品質、を具体化していく際に、品質に関する様々なモデルなどが活用できるわけです。

あらためてQAってなんだろう

ここまででざっくり外観が見えてきました(私には)

品質保証、というのは

  • 自分たちの顧客を理解する・設定する
  • 顧客にとっての「品質が良い」とはどういうことか、を定める
  • 製品が、自分たちの思う「品質が良い」状態であることを確かめる

ということなのではないでしょうか。

テストとQA

また脇道にそれますが、私は単に「テストをする」ことを「QAする」というのに違和感がある派です。 これが、上記の「品質保証とは」で一応の説明ができるわけです。

テスト、というのは3番目の「確かめる」手段のひとつであり、QA活動の一部だと考えています。

QAエンジニアは何をするのか

ここまででQAとは、の輪郭が見えたところで、じゃあQAエンジニアって何するの?も併せて考えてみましょう。品質保証をする人、と考えるとわかりやすいですが、では品質保証はQAエンジニア「だけ」がするのでしょうか?

品質保証はQAエンジニアのしごと、と捉えている人も世の中には居ますが、流れとしては逆です。QAエンジニアだけが頑張っても品質はよくならないので、PM, PdM, Devなどなど製品にかかわる皆がそれぞれの立場から品質にコミットしてよいものを作りましょう、というのが現状のスタンダードです。(と言い切ったものの証拠はないので主観になってしまっています。)

記事の最初に貼ったツイートに、@freddiefujiwaraさんから頂いた一連のリプライが好例だと思います。

で、私としては「全員が品質にコミットするうえで、皆のQA活動を主導する存在」がQAエンジニアなのでは?と思っています。

QA系エンジニアのロールを整理した「QAファンネル(QMファンネル)」においても、一定以上のスペシャリティを持つQAでは「品質文化の浸透」や「技術移転」「推進」といった働きが期待されています。これは、QAエンジニアからQAエンジニアへの浸透にかぎらず、ステークホルダー全体に品質文化を浸透させたり、QAを推進したりすることだと私は解釈しています。

自分たちのチームで「品質が良いとはどういうことか」を明らかにしていく、それはQAだけが決めるものではありません。QAが主導して(もちろんプロダクトオーナーなりが主導してもいいのですが、QAのお仕事だと思うようにしています)皆で合意をする。自分たちの作るサービスやプロダクトがこういう状態だったら、品質が良いって言ってもいいよね!をはっきりさせる。

もちろんこの「品質が良い」には移り変わりもあるでしょう。サービスやプロダクトのフェーズにも依存しますし、社会状況にも依存します。コロナによってガラッと世の中が変わり、品質が良い、の基準も変わったもの、色々ありそうです。そのため、品質が良いというのは一度定めただけではダメで、アップデートしていく必要があります。そこもQAエンジニアが主導するところ、と思っています。

まとめると

品質保証、というのは

  • 自分たちの顧客を理解する・設定する
  • 顧客にとっての「品質が良い」とはどういうことか、を定める
  • 製品が、自分たちの思う「品質が良い」状態であることを確かめる

ことではないか、が今夜時点での私の考えです。

また、QAエンジニアは品質保証を単独でやるわけではなく、みんなでQA活動をするのをひっぱっていく存在ではないか、と思います。

そしてここに戻る

(『ソフトウェア品質保証の考え方と実際』読み返してくる

書籍では

『ソフトウェア品質知識体系ガイド SQuBOK Guide』に、品質保証に関する記載があります。

まず、ISO9000では。

品質要求事項が満たされるという革新を与えることに焦点を合わせた品質マネジメントの一部

飯塚先生は

お客様に安心して使っていただけるような製品を提供するためのすべての活動

とおっしゃっていて、かなり広い意味として用いているようです。

おれたちの戦いはこれからだ!

もとのツイートににしさんからリプを頂いていたのですが、ぜひ見てほしいので貼っておきます。

たぶんこの記事で書いた内容は拙い、のですがそれでも考え続けます。(浅くても思考過程を書いておかないと見返せもしないしツッコミももらえない)