品質保証（QA）とは？品質管理との違いや具体的な業務内容について解説

品質保証はさまざまな業界で重要視されていますが、具体的にどのようなことを行うのでしょうか？品質とは何か、何をすべきかをはっきりさせなければ、品質を高めていくことは不可能です。

ここでは、品質とはそもそも何か、品質保証とは何なのかについて解説します。

品質保証について考える前に、そもそも品質とは何なのかを定義する必要があります。

品質とは、製品やサービスが利用者の使用目的をどれくらい満たしているかを表すものです。使用目的は状況によって異なるので、求められる品質は一律ではありません。

たとえば、自動車を例にすると、高速道路を日常的に使うための速度を重視する人もいるでしょうし、長距離の移動でも疲れない乗り心地を重視する人もいるでしょう。価格が安いことを重視する人もいれば、すぐに提供されることが重要な場合もあるでしょう。これらの品質を複合的に判断することもあります。

ITシステムであれば、バグによる計算間違いがないこと、多数の人が同時に利用するときの安定性、利用者にわかりやすいこと、セキュリティレベルが高いことなど基本的な品質に加え、コストの制約や納期の制約など、さまざまな観点の品質が求められます。

このように、品質は扱う製品やサービスによって異なり、どのような品質が求められるかは、顧客のニーズによっても異なるのです。そして、品質の高さは顧客満足度に直結するため、品質を高めることは企業にとって重要なミッションといえるでしょう。

品質保証とは、一般的には、出荷後も利用者に安心感や満足感をもってもらうための活動とされています。

単に製品やサービスに欠陥がなく、仕様どおりに動くことを確認するだけはありません。顧客のニーズを満たし、高い満足度を得られる製品やサービスを生み出す活動のことを指しています。そのためには、製品やサービスをユーザー視点で評価して、品質を向上し担保するための活動を進めていく必要があります。

ITシステムでいえば、システムのリリース後に、システムの有効性や使いやすさなどの品質をユーザー視点で評価して、さらに品質を向上していく活動ということになります。これは、次のシステム改修への企画にもつながっていきます。

品質保証は「Quality Assurance」の略で、QAと表記されることがあります。このQAとよく似たものに、品質管理があります。「Quality Control」の略で、QCと呼ばれるものです。この2つは何が違うのでしょうか？

品質管理は、製品やサービスの製造工程から出荷確認までが基本的な活動範囲になります。

購入した材料が予定の仕様・性能をもっているか、製造のプロセスが指定どおりに精度よく実行されているか、工程の途中や出荷前のチェックで想定の品質を確保しているか。こういったことを確認して、出荷する製品の品質を安定されることが品質管理になります。

ITでいえば、品質管理では、十分にスキルのあるメンバーを集めているか、開発プロセスを規定どおりに実行しているか、レビューやテストの実施量は十分か、バグ検出は十分か、インフラの性能は十分か、といったチェックを実施します。

品質管理では、出荷した製品の品質を確保することはできますが、出荷した後にどのように利用されるかについては関与しません。しかし、出荷後に必要な品質が変わらないのであれば、品質管理で十分です。

利用の方法が明確なものについては、品質管理で十分な面があります。たとえば、ネジのような素材や、ドライバーのような工具においては、利用方法が限定されているため、ほとんどの人が同じ品質を求めることになります。その品質を出荷時に確保できれば、利用者は満足します。

利用方法が不定でも、一定の基準を満たせば、品質管理で十分なものもあります。たとえば、ぬいぐるみや子ども向け玩具は、子どもが噛んでも問題ないように特定物質を含まないとか、乱暴に扱ってもケガなどにつながらないといった品質を求められますが、個別の利用方法への対応は求められません。

このように、品質管理で十分に対応できる製品も、多数あります。

出荷後に必要な品質が変わらないのであれば、品質管理で十分と紹介しました。では、出荷した後に品質が変わっていくものではどうでしょうか。

たとえば自動車を例にすると、使うにつれてタイヤやワイパーなどがすり減っていきます。オイルなどの液類が減ったり、フィルターが劣化したりして、性能が悪くなることもあるでしょう。これらは定期点検などのタイミングでメンテナンスが必要になります。

ITシステムにおいても時間とともに品質が変わっていきます。よくある例としては、データベースのもつデータの増加です。これは処理時間の増加やストレージの圧迫につながっていきます。セキュリティの劣化もあげられます。毎月のように新しい問題が見つかり、セキュリティパッチの適用が必要となります。さらに、ストレージに使うHDDやSSDには寿命があるため、定期的な交換が必要になります。

顧客の使用目的が変わることによって、求められる品質が変わることもあります。

自動車が雪国に行くことになったら、タイヤチェーンが必要になります。ITシステムの利用者が増えたら、ストレージ追加などのインフラ増強が必要になります。

このように、製品そのものの品質が経年劣化したり、顧客の使用目的が変わったりする状況は、品質管理でカバーすることができません。品質保証を導入することで、品質を維持し、また顧客の使用目的にあわせて修正していくことが必要になるのです。

ITシステムの品質保証の例として、セキュリティパッチの適用やストレージ追加などをあげました。これはシステム運用と何が違うのか、と思った方もいるのではないでしょうか？

たしかに、ITシステムのリリース後のアフターフォローというと、システム運用の作業が真っ先にあげられます。システムを維持するというという意味では、運用も品質保証の一環であることは間違いありません。

しかし、ここでやりたいのは、システムを維持するのではなく、品質を保証することです。品質とは、利用者の使用目的をどれくらい満たしているかを表すものです。社内外のエンドユーザー、そしてシステムに投資をしたオーナーの目的に対して、より高い価値をもたらす活動が品質保証なのです。

業務で使われる多くのシステムは、社内のエンドユーザーの業務効率を高めたり、社外のエンドユーザーとの取引に貢献したりする目的をもっています。その結果は、システムのオーナーに会社の利益という形で還元されます。業務効率をさらに高めるのにどうすればよいのか、社外との取引を増やすために何をすればよいのか、これを考えてITシステムに反映させることこそが、ITシステムの品質保証といえるでしょう。

ここでは、ITシステムを例にして、各プロセスにおける品質保証の仕事についてご説明します。具体的にどのような対応を行うのか、イメージしてみてください。

品質保証が扱う業務範囲は非常に広く、企画段階から対応を行います。ITシステムでは、要求分析のプロセスになります。どのようなITシステムをつくるか、どのようにITシステムを修正するかを、業務の視点で考えます。

典型的には、すでに運用中のITシステムから、ユーザーの要望を収集します。ユーザーによっては明に声をあげない場合もあるかもしれません。その場合は、業務の現場を実際に観察して、課題を探すこともあるでしょう。

最近では、新しいビジネスモデルをITで実装する例も多くなっています。このとき、システム視点が強くなってしまって、ユーザー目線が弱くなる例も多々あります。品質保証の立場としては、実際のユーザーや業務の現場を想定して、ユーザー目線の提案をすることが期待されます。

企画はITシステムに限定したものではありません。システム開発やシステム運用のプロセスに課題があるのであれば、それをどのように変えるかという検討も行います。最終的に、開発チーム、運用チーム、ユーザー、システムオーナーのすべてにとって、価値・利益が高まるような仕組みを考えます。

要求分析の品質保証活動で目指すべきことは、顧客からニーズを聞くだけでなく、隠れたニーズも掘り起こすことだといえるでしょう。

ITシステムの要件定義では、多岐にわたる要求のなかから、今回の開発で実現することを明確化します。また、システム的に実行する部分と、人が実行する部分を明確化します。

多くの場合、顧客はシステムに対して多大な期待をするので、開発範囲が膨らんでしまいがちです。ここでコストや納期の制約も考慮して、顧客からの要求を厳選することも重要になります。コストや納期も品質の一環として、保証できるような合意に導くことが重要です。

同時に性能やセキュリティなどの非機能要件を明確にすることも重要です。機能を考えることは容易ですが、非機能要件を検討するためには経験やスキルが必要です。非機能要件は開発だけでなくリリース後のコストにも影響するので、品質保証でおさえておくことが必要です。

要件定義の品質保証活動で目指すべきことは、コストや納期を踏まえて実現可能な要件に落とし込んでいくことだといえるでしょう。

性能、ユーザビリティ、セキュリティなどの非機能要件は、設計のプロセスのなかで具体化されてきます。品質保証としては、ユーザー目線や非機能要件に着目して設計をレビューしていきたいところです。また、リリース後のことを想定して、運用面の設計に漏れがないかということも確認します。

このプロセスでの品質確保は、品質管理で実施する部分もありますので、品質保証ではユーザー目線や要件定義とのトレーサビリティなど、品質管理で対象外になりがちなところを重点的に確認するのがよいでしょう。

デプロイは、開発したシステムを運用環境に展開する作業のことです。品質管理は、システムをリリースした後にも、価値を高めるためにシステムを改修していく活動です。一度システムをリリースしたら終わりではなく、何度も繰り返す作業として、スムーズにデプロイできることを確認しましょう。

テストにおいては、ユーザー目線や非機能要件に着目して、確認していきたいところです。リリースにおいては、顧客側の運用体制を整えることを手伝う必要があるかもしれません。

このプロセスにおいても、品質管理で対象外となりがちな、利用者視点や運用視点をとり入れた品質保証を行っていくのがよいでしょう。

品質保証では、リリースされたら終わりではなく、リリース後にも利用者視点でのアフターサービスを行います。

ユーザーの声をヒアリングしたり、アンケートを出したり、メールで意見を聞くなど、さまざまな方法でユーザーの声を集めます。そして、ユーザーの満足度や不満な点を確認し、今後のITシステムの改善に役立てます。

そのほかにも、ユーザーからシステムの使い方に関する問い合わせを受けたり、困りごとの対応をしたりするアフターフォローも必要です。問い合わせのあった声を集めて分析することでも、今後の改善点の抽出につなげられます。

このプロセスの品質保証活動によって、顧客やユーザーの満足度が決まるといっても過言ではないでしょう。

従来型のITシステムの開発では、上流工程をコンサルが行い、設計をベンダー、コーディングや運用はそれぞれパートナー企業という分離された体制で行っていました。システムに求められる品質が上流工程ですべて決まっていて、変化することのない時代には、この体制はコスト抑制のために最適なものだったかもしれません。

しかし、ITシステムの適用範囲が広がり、ITシステムに要求される品質が変化をつづける現代には、運用の結果を次の企画にフィードバックする必要が出てきました。これを実現するのが品質保証という活動です。

ITシステムのライフサイクルをまたがって、すべてのプロセスを通して品質保証の活動を行うことによって、変わりゆく要求に追随していくことができるようになるのです。

近年では、製造工程や出荷時の品質管理だけではなく、運用から企画・設計にフィードバックする品質保証が重要視されつつあります。

たとえば、出荷後に製品が壊れることは品質管理の範囲外でした。品質保証では、この製品が壊れるという事象を捕捉して、企画・設計の工夫で製品を壊れにくくする工夫につなげるということができます。出荷後の品質の変化や利用者の変化にも対応できるようになります。

ITシステムでも同様です。従来のシステム運用がシステムを維持するという消極的なものであったのに対して、品質保証の考えをとり入れたシステム運用は、システム価値を高めて利益を増やそうという積極的な活動を行います。運用を通してシステムとその利用目的とのギャップを把握し、これを埋める提案をします。

この品質保証の活動は、開発チームと運用チームが合体して全体最適化を図る、DevOpsの考え方とも相性がよいものです。DevOpsではアジャイル開発とクラウドコンピューティングを活用して、短いサイクルでのリリースを行います。品質保証においても現場で見つかった課題がすばやくシステムに反映されることは大歓迎なので、品質保証の効果的な実現のために、DevOpsをとり入れることも検討の価値があると思われます。

DevOpsについてはこちらもご覧ください。
＞＞DevOpsとは？アジャイル開発との違い、導入するメリット・デメリットについて解説のページへ

この記事では、品質保証とは何か、品質保証と品質管理の違い、各プロセスの品質保証の内容などについて解説しました。

品質を担保するための手法は変わってきており、製造工程や出荷時だけでなく、上流工程からアフターサービスまでの品質保証が主流になってきています。品質管理手法を変えて品質の向上を目指したい場合には、品質保証（QA）の考え方を導入する必要があるでしょう。

品質保証の実施のために、開発と運用の関係を見直したいとお悩みの場合には、DevOpsの導入もあわせて検討してみてください。

ご相談はこちらから
＞＞お問い合わせページへ
＞＞料金についてページへ

大手IT会社にて、17年間ソフトウェア製品の開発に従事し、ソフトウェアエンジニアリングを深耕。SE支援部門に移り、システム開発の標準化を担当し、IPAのITスペシャリスト委員として活動。また100を超えるお客様の現場の支援を通して、品質向上活動の様々な側面を経験。その後、人材育成に従事し、4年に渡り開発者を技術とマインドの両面から指導。2019年、ヒンシツ大学の講師としてSHIFTに参画。

担当講座