📘️ Book Club & 💬 Design Term：ソフトウェア開発におけるQAとは？QAのパーフォーマンスレビューを書いてみた

現在私の勤務している会社が成長するにつれて、効果的なスキルと考え方を構築する必要性も高ってきました。私たちはさまざまなスキルを身につけなければなりません。パフォーマンス・レビューはこれまでの業績をチェックインし、設定された目標に対してチームメンバーがどのように追跡しているかを確認するのに絶好な機会です。

またこれは、チームメンバーとマネージャーが、得意、また苦手なスキルについて話し合ったり、フィードバック、またはサポートについて話し合うための会話を行う機会でもあります。
個人のパフォーマンスを包括的に評価することで、企業は従業員に関する貴重な情報を得ることができます。

前回は私自身がプロダクト・デザイナーとしての自分の役割と責任、そして目標を設定してスキルを向上させる方法について考え、過去12か月間のゴール設定を見直し、次の12か月の潜在的な目標を検討するために、目標を確認し直し、英語でレポートを書いてみましたが、パフォーマンス・レビューの一環として、チームメンバーや地震の上司へフィードバックを与えることも求められています。

今回はただいま一緒のチームで働いているQAのチームメンバーのパフォーマンス・レビューを行うということで、フィードバックを求められたので、QAについて、役割と注意するべきポイントについてまとめてみました。

ソフトウェア開発におけるQAとは？

システム開発を行うエンジニアの中には、QAと呼ばれる職種が存在します。

QAはQuality Assuranceの略で、簡単に説明すると「品質保証」する職業です。システム開発におけるQAはソフトウェアの成果物の品質を担保する役目を担っています。

QAとは信頼できる製品を開発するための一連の要件を特定して維持することに焦点を当てたプロセスです。十分に開発されたQAシステムは、企業の信頼性を高め、製品に対する顧客の信頼を高め、ワークフローの効率を向上させ、真の競争上の優位性を提供します。

ソフトウェア開発の実践とプロセスにおけるQAの背後にある原動力は、標準化（ISO）。 そのため、QAはISO 9000国際規格とペアになっていることが多く、企業はこの規格を使用して、品質保証システムが効果的であることを確認しています。

正式なプロセスとして、品質保証は製造業にそのルーツをたどります—何年にもわたって、ITを含む他の多くの産業に広がっています。

QAは、ソフトウェア作成中の最も重要なプロセスの1つです。経験豊富なチームは、ソフトウェア開発のQAをテストやその他のプロセスと比較できないことを知っています。 独自の価値をもたらし、製品またはサービスが特定の要件を確実に満たすようにします。

ソフトウェア・テストとの違い

2つのプロセスは互換性があるように見えるかもしれません。結局のところ、どちらも特定の要件に一致し、最高品質のソフトウェアを出荷することを目指しています。

しかし、考慮したいことがあります。

QAプロセスの背後にある考え方は、製品の品質がクライアントの要件に沿っていることを保証することです。品質保証の専門家は、チームがソフトウェア開発ライフサイクルのすべての主要な手順に従うことを保証するプロセスの開発と実装の両方に取り組んでいます。これは、プロセス開発と継続的改善、および欠陥防止に焦点を当てた積極的な意思表示です。

一方、ソフトウェア・テストは、ソフトウェアの欠陥やエラーの特定に重点を置いています。テスターは、厳密なテストプロセスをソフトウェアに適用して、リリース前に要件や欠陥からの変更を修正する必要があるかどうかを確認します。ソフトウェア・テストは全体的な品質管理プロセスの一部であり、製品指向の活動にのみ焦点を当てています。また、テスターはバグの検出のみを担当し、バグの修正は担当しません。

では、品質管理とどう違うのでしょうか？

これらの2つのアクティビティは、互いに混同されることがよくあります。 実際には、それらはまったく異なります。

QAは予防活動がすべてですが、品質管理は是正プロセスに焦点を当てています。 QAはプロセスに関与するすべての人の責任であり、品質管理は（テスターの）特定のチームのドメインです。

💡これらのアクティビティはすべて深く絡み合っています。 品質管理は品質保証のサブセットです。 また、ソフトウェアテストは品質管理のサブセットです。

ソフトウェアの品質を維持することがなぜそれほど重要なのですか？

QAは、すべてのソフトウェア開発プロセスの重要な部分です。 本質的に、ソフトウェア開発のQAは、企業が顧客の期待と要件を満たす製品とサービスを作成するのに役立ちます。 これにより、高品質の製品を構築し、消費者の忠誠心と信頼を向上させることができます。 QAプログラムで定義された基準と手順に従うことで、チームは製品の欠陥が発生して問題になる前にそれを防ぐことができます。

組織の規模に応じて、QAはさまざまなサブタスクで構成できます。 その中核となるのは、QAプロセスが特定の品質の成果物を作成することです。 ソフトウェア要件は絶えず変化しており、チームは新しい目標を追加しているため、QAチームは、新しく追加された目標や要件がソフトウェアの品質に悪影響を与えないようにする必要があります。

当然のことながら、テスターとQAの専門家は、これらの基準を日常業務に適用します。 しかし、品質保証の恩恵を受ける立場にあるのは彼らだけではありません。 ソフトウェア開発者、経営幹部、およびその他の利害関係者は、時間の経過とともに進化する製品品質の傾向を追跡したい場合があります。

これは、成長し、ますます高度化するアプリケーションに特に当てはまります。QAプロセスもより複雑になります。 そのため、チームがQAプロセスについて熟考し、ニーズに完全に対応するツールを見つけることが重要です。

QAはソフトウェアの品質をどのように判断しますか？

QAは、欠陥管理アプローチと品質属性アプローチの2つの主要なアプローチを利用します。

QAでは、欠陥とは、クライアントの要件に沿っていないソフトウェアの要素です。開発者がそのような要件を完全に理解できない場合があり、それがデザインエラーにつながります。その他のエラーの原因には、不十分なデータ処理、バグのあるコード、または不適切な関数型ロジックが含まれます。

欠陥管理アプローチは、欠陥を追跡し、カテゴリを定義してその重大度をマークするのに役立ちます。QAの専門家は、開発チームの能力を測定する管理図を作成できます。

一方、品質属性アプローチは、次の6つの品質特性の達成に重点を置いています。

• 機能性
  ソフトウェアの機能は適切であり、正しく実装されていますか？
  ソフトウェアは他のシステムコンポーネントとどのように相互作用しますか？データを安全に処理できますか？必要な法律やガイドラインに準拠していますか？

• 信頼性
  ソフトウェアは特定の条件下で動作しますか？どのくらいの頻度で失敗しますか？障害が発生した後、システムはどのくらいの時間で完全に動作するようになりますか？

• 使いやすさ
  ユーザーはソフトウェアの機能を簡単に理解できますか？ソフトウェアの機能を理解するにはどのくらいの努力が必要ですか？

• 効率性
  開発チームは、ソフトウェアの開発中に優れたコーディング慣行に従いましたか？アーキテクチャは効率を念頭に置いてデザインされていますか？

• 保守性
  ソフトウェアの障害を特定して修正するのはどれほど簡単ですか？失敗の主な原因を特定することは可能ですか？障害が発生した場合、コードの変更にはどのくらいの労力が必要ですか？変更が適用されている間、システムパフォーマンスはどの程度安定していますか？

• 移植性
  システムは環境の変化に適応できますか？どれくらい簡単にインストールできますか？特定の環境でシステムコンポーネントを交換するのはどれくらい簡単ですか？
  形状や重量などが所持や運搬に適していることや、特定の場所に据え置いて使う前提ではなく、様々な場所に移動して使えるようデザインされていることなどを指します。

QA—チームの落とし穴

QAチームのパフォーマンスと有効性に影響を与える最も一般的な問題のいくつかの問題点があります。

• 欠陥の発生を分析できない
  これにより、欠陥が繰り返し発生する可能性が高くなります。

• QAに携わる方々は質問をすることを躊躇する場合がある。
  これはテスターやQA専門家の日常業務で最も一般的な障害の1つです。しかし、質問をしないとチームがシナリオを見逃してしまう場合、結果ははるかに悪化します。

• テストを自動化するのは便利ですが、注意が必要。
  現在、自動化はQA界の流行語です。自動化の導入の問題に対処するために、チームは多くの場合、バグログツールなどの半自動化されたソリューションから始めます。
  QMetry Automation Studio、Selenium などのツールがあります。

• ユーザー・エクスペリエンスを後まわしにしてしまう。
  QAは、テストシートを超えて、ユーザーエクスペリエンスを詳しく調べる必要があります。特に、クライアントの要件に対応しているかどうか。チームにUXの提案がある場合は、それをクライアントと共有する必要があります。クライアントは、UXの観点から実現するのが難しいビジョンを持っている場合があります。そのとき、QAチームが介入して修正を提案する必要があります。結局のところ、それは最終決定を下すためのクライアントの呼びかけです。

• バクの扱い方
  QAチームは、特にライブ・アプリケーションでバグを見つけた場合、開発チームとのコラボレーションが面倒になることがよくあります。しかし、彼らの仕事は、ソフトウェアの開発に携わるすべての人がより良い製品を出荷するのに役立つプロセスを確立することです。同じ間違いを再び回避する方法を考え出すことはあなたの時間をはるかにうまく利用することです。客観性を保ち、作業を他のチームと同期させます。非難ゲームを避けるようにしてください。

QAのパーフォーマンスレビュー

QAについての役割と注意するべきポイントを考慮した上で、ただいま一緒のチームで働いているQAのチームメンバーのパフォーマンス・レビューを書いてみました。

I’ve put some thoughts together for Tom’s Performance review.
トムの業績評価のためにいくつかの考えをまとめました。

What do you think of the work he’s been doing? For example, running regression tests, writing automated tests, providing feedback on features, details he’s put into bug reports, etc.
彼がやっている仕事についてどう思いますか？ たとえば、回帰テストの実行、自動テストの作成、機能に関するフィードバックの提供、バグレポートに入力した詳細などです。

I’m afraid that I wouldn’t be able to comment on his skills in running regression tests or writing automated tests, but Tom has been a great team member, he has been a great help giving us feedback on features and very detailed into bug reports.
回帰テストの実行や自動テストの作成に関する彼のスキルについてコメントすることはできませんが、トムは素晴らしいチームメンバーであり、機能に関するフィードバックを提供してくれ、バグについて非常に詳しく説明してくれました。 

He has been helping us make sure we are delivering a product that matches all the client requirements and making sure it’s functional and related to user experience.
彼は、すべてのクライアント要件に一致する製品を提供し、それが機能的でユーザーエクスペリエンスに関連していることを確認するのを手伝ってくれました。

How have the teams and your own interactions with him have gone? So things like stand-ups, 1 to 1 catch-ups, sprint planning, retro’s, etc.
チームと彼とのあなた自身の相互作用はどのように進んでいますか？ つまり、スタンドアップ、1対1のキャッチアップ、スプリント計画、レトロなどです。

I believe QA is a key element of the software development process. Without our QA team, we wouldn’t be able to deliver products that match all the client requirements.
QAはソフトウェア開発プロセスの重要な要素だと思います。 QAチームがいなければ、すべてのクライアントの要件に一致する製品を提供することはできません。

I have been reaching out to him from the get-go asking him feedback on our user experience and functionality. He has been really supportive and given us really valuable feedback.
私は最初から彼に連絡を取り、ユーザーエクスペリエンスと機能についてフィードバックを求めてきました。 彼は本当に協力的で、私たちに本当に貴重なフィードバックをくれました。

Has he been able to provide feedback during planning sessions and retros?
彼は計画セッションやレトロの間にフィードバックを提供することができましたか？

He has been able to provide valuable feedback during planning sessions and retros. I have also noticed that he is not afraid of asking questions. He has been reaching out on a number of occasions to other team members for feedback and suggestions and utilising them in practice.
彼は計画セッションやレトロの間に貴重なフィードバックを提供することができました。 私はまた、彼が質問をすることを恐れていないことに気づきました。 彼は何度も他のチームメンバーにフィードバックや提案を求め、それらを実際に活用してきました。

How has he gone learning from his experiences working on projects?
彼はプロジェクトに取り組んだ経験からどのように学びましたか？

We have been learning & proactivity looking into areas such as accessibility & inclusive design through working on the [Project name].
[プロジェクト名]に取り組むことで、アクセシビリティやインクルーシブデザインなどの分野を学び、積極的に取り組んできました。

Tom has been helping me ensure we’re building the best possible products for everyone. For example, during creating accessible buttons, links and forms he was able to give me tons of feedback and gave me really useful references.
トムは、私たちがすべての人にとって可能な限り最高の製品を構築していることを確認するのを手伝ってくれました。 たとえば、アクセシブルなボタン、リンク、フォームを作成している間、彼は私にたくさんのフィードバックをくれ、本当に役立つリファレンスをくれました。

まとめ

QAは、ソフトウェア開発プロセスの重要な要素です。

ソフトウェア開発におけるQAの主な目標は、機能的であろうとユーザーエクスペリエンスに関連するものであろうと、すべてのクライアント要件に一致する製品を提供することです。 経験豊富なQAチームがいない場合、完璧なデジタル製品を発送することは不可能です。

私も色々勉強中なので、皆さまのご意見・ご感想をお聞かせください。
お読み頂きまして、ありがとうございました。

メルボルンを拠点にプロダクトデザイナーとして働いています。 主にデジタル・プロダクトの制作に携わっています。