はじめに

どうもこんにちは。GCコンテンツ編集部です。Webサービス系企業に関わる方なら一度はQAという言葉を耳にされたことがあるかと思います。製品開発の現場に近い方なら毎日耳にされているかもしれません。QAとはここではQ&Aの略ではなくQuality Assuranceの略QAです。本記事ではソフトウェア開発における「QAとは何か」を品質に関して世界的に著名な狩野モデルを用いて記述します。本記事で記載されている内容がQAの理解の正解では決してありませんが、本記事が皆様のQAへの理解を深めるきっかけとなれば幸いです。

QAとは何か

早速ですが、QAとは何でしょうか。ソフトウェア開発の現場だけではなく、事業側の方も日常的にQAという言葉は利用されます。

「開発が終わったからQAしよう」

ですとか、

「QAの結果をみてからリリースを判断しよう」

ですとか概ねこのような文脈で使われるかと思います。

ソフトウェアに関わる企業一般において、開発が終わった後のプロセスを示してQAと呼ばれることが多いです。QAによってリリース判定に必要なソフトウェアの品質情報が集められ、ある一定基準を満たしたソフトウェアはリリースされます。リリースが行われたソフトウェアは運用へと引き継がれていきます。このように、QAは開発と運用の間の門番のような役割を担っていることがソフトウェア開発におけるQAの位置付けといえます。

開発全体の中のQAの位置付けイメージ

次にQAについて、もう少し広い範囲で考えてみます。QA、Quality Assuranceは日本語で『品質保証』を示します。ソフトウェア開発の業界のみで使われる言葉ではなく、何か製品を作る業界において、その品質を保証する体系を広く指し示して『品質保証』と言われたりもします。

つまり、QAと言えば、ソフトウェア開発においては、ある種開発と運用の間の門番のような役割を表すけれど、広義ではそもそもの品質保証がQAの本質であるということです。

これらの観点をまとめると、ソフトウェア開発におけるQAとは、

Quality Assurance ▶ソフトウェアの品質を保証するプロセス

と言うことが出来ます。さて、そんなQAですが、皆さんはなぜQAを行うのでしょうか。また、なぜQAを行わないのでしょうか。

QAを行うメリットは主に以下3点が上げられます。

・バグが少ないシステム/ソフトウェアをリリースできること

・仕様書通りにシステム/ソフトウェアがリリースできること

・継続的にシステム/ソフトウェアの品質を管理できること

1点目は特にイメージしやすいかと思います。QAのプロセスの本質はバグを発見し、改修するところにあります。そのため、QAを行うことによって、バグが少ないシステム/ソフトウェアをリリースすることが可能となります。

次に、仕様書の通りに動くという観点がQAの保証するところです。QAは様々な方法を用いてバグ発見のために検証を行いますが、その中の大きな一つの観点として、「仕様書通りに動くかどうか」というものがあります。つまり、しっかりとしたQAを通過したソフトウェアは「仕様書通り」に動くことがある一定レベルで保証されている、ということができます。

最後の3点目は「継続的な品質の管理」です。一度リリースするだけであれば、形式張ったQAは必要ないかもしれません。ただ、複数回のリリースを行うに際し、同じ水準でリリース判定を行うためにはある一定水準以上の形式が必要で、そこにQAは一役買います。QAを行うことによって、前回のリリース時とのソフトウェアの品質の差異を浮き彫りにすることが出来るのです。そのため、QAを充分に行うことによって、継続的なシステム/ソフトウェアの品質の管理が可能となる、といえるのです。

このようにメリットが多いQAですが、手間、時間、コストが掛かるため、「とにかくQAをたくさん行う」ような判断は行いにくいのが多くの開発現場の実態かと思います。多くの検証作業を行うためには、それだけ多くの人員が必要となり、その分多くの時間・コストが必要となってきます。近年テスト自動化はどんどんスコープを拡大していますが、それでもQAの実施量に依存した手間、時間、コストの増加は避けることができないと言えるかと思います。つまり、この手間、時間、コストはあえていうのであれば、QAを行うデメリットと言えます。

限られた予算・リソース・スケジュールの中でいかに高い品質を目指すか、というところにQAの大義名分は存在するものの、その制約ゆえに重要性の共通認識を作りにくいこともまたQAの性質とも言えるかと思います。

上記のようなメリットを踏まえると、多少コストが必要となっても、大きなシステム/ソフトウェアであればあるほど、「QAを行わない」という選択肢は無いと思います。

実質的にQA組織を持っていない組織であっても、代替手段でおおよそQAとおぼしき活動は行われていることが一般的です。

なぜQAを行うか〜狩野モデルから考える「品質」〜

ここまでの内容をまとめると、QAは

「サービス/機能を実装しているシステムの「品質」を上げるため」に実施すると言えます。言い換えると、QAを行うことによる組織の期待値は、そのシステムの品質が上がっていることなのです。

ただ、「品質」という言葉はQAと同様に、様々な団体で定義されており、とっつきにくい概念です。

ここでは、よく知られていてわかりやすい「品質」の考え方である狩野モデルを取り扱って、なぜQAを行うか、を考えていきたいと思います。

狩野モデルでは品質を5つの品質要素に分けて考えます。「当り前品質」、「一元的品質」、「魅力品質」、「無関心品質」、「逆品質」の5つです。

当り前品質は、充足されていることが当たり前の品質要素です。車であれば、エンジンがかかる、が当たり前品質に当たります。

一元的品質は、充足されていれば、満足、不充足であれば不満を引き起こす品質要素です。自動車で例えるならば、燃費が良いことが一元的品質に当たります。

魅力品質は、充足されていれば、満足、不充足であっても仕方ないと思われる品質要素です。車であれば、車中でWi-fiを使えるか、がそれに当たります。Wi-fiが使えなくて不満を感じる人はいないでしょう。

無関心品質は充足されていても不充足であっても満足度には影響を与えない品質要素です。

逆品質は充足されていれば不満、不充足であれば満足を引き起こす品質要素です。

狩野モデルから考えるQA

さて、では狩野モデルの5つの品質要素を用いて、QAを改めて考えてみましょう。

実際のQAの対象として「品質」を上げるという議論になった際、着目されるのは狩野モデルでいう「当り前品質」、「一元的品質」、「魅力品質」の3つです。

サービスに期待する品質（当り前品質）をカバーしながら、一元的品質をあげて、魅力品質を上げるような段階でQAを行っていくという順番になります。

例えば、先ほどの車の例でいうと、エンジンがかかるか（当たり前品質）どうかわからない車のルーフ（魅力品質）の動作をチェックすることはあまり生産的といえないでしょう

大きなサービスになればなるほど、QAに掛かるコストは莫大になり、開発速度を重視すればするほど、いわゆる守備であるQAはないがしろにされがちです。多くのステークホルダーが絡む中で全員がQAについて同じレベルの理解を持ちながら、サービス開発の意思決定を行うことは至難の技です。

狩野モデルを用いて「品質」を理解することがQAを理解する上でトップクラスに重要、というわけではないですが、「品質」について組織で共通理解を持つと、同じ認識のもとでQAを優先順位付けて考えることができるようになり、結果としてシステム/ソフトウェアのみならず、サービス全体の品質を上げることに繋がっていきます。

車の例で言うと、まずエンジンがかかることが「品質」として重要である、と全員が「品質」に関して共通の理解を持つことでチーム全員が同じ方向を向いてQAを行うことが出来ます。

すると、全体のサービスの機能の優先順位が明確化され、自ずとサービス全体の品質が上がっていく、というわけです。

車の例で言うと非常にシンプルで、「当たり前品質」を見失うことはそうそうないかと思いますが、実際WEBサービスやシステムでは「当たり前品質」が見失われることはしばしばあります。

とりわけ、組織の人数が増えて、開発と事業と分断されているような組織において、何を顧客に届けるべきか不明瞭になり、結果、それは「品質」への理解の分断を招き、最終的に表出する形としてQAの対象を見失ってしまうのです。

ここでお示しさせて頂いたQAへの理解はあくまで一例ですし、QAへの理解という意味では一つの側面をお示ししただけだと思っています。

ただ、もしこの記事をお読みになられた方の中で「QAとは何か」に対して明確な答えを持たれていない方は、一度狩野モデルをもとに「品質」について考えてください。自社サービスを行っている会社に所属されている方は、自社のサービスの「当たり前品質」とは何か、を考えてみてください。その「当り前品質」を保証するプロセスこそがQAなのです。

さて、最後少し抽象的な結論になりましたが、「QAとは何か」本記事を読む前と比べていかがでしょうか。解像度が上がりましたでしょうか。

本記事が皆様それぞれのQAについての理解を推し進める一端を担うことが出来ますと幸いです。

まとめ