QAチームで大切にしていた5つのこと
はじめに
私は2005年から2017年頃まで、10年以上にわたり品質保証エンジニア部隊(QAチーム)の長をしていました。
ここ2年ほどはプリセールスエンジニアとしてセールス側で仕事していましたが、この10月からまた品質保証に戻ってくることになりました。
そこで、この機会に往時QAチームで大切にしていたことをまとめてみようと思います。
(※あくまでも私が率いていた当時のQAチームの話ですので、その前提でお読みいただくようお願いします。)
1. ユーザー視点を担う
プロダクトのテストは、開発(プログラマーという意味です)とQAそれぞれで行っていました。
なぜそれぞれでテストをするのかというと、テストする際の視点が異なるからです。
開発はホワイトボックステスト(プログラマー視点のテスト)、QAはブラックボックステスト(ユーザー視点のテスト)を行います。つまり、プロダクト品質を高めるためのアプローチとして、2つの異なる視点のテストを採用しているのです。
どちらか一方に偏ってしまうと、プロダクトとしてはいびつになってしまいます。
たとえば、ユーザー体験や納期を重視するあまり、ソースコードの可読性が悪くなってしまうと、メンテナンスしづらくなってバグの温床になったり、不具合が発生した際に素早く対応できなかったりと、長い目で見るとユーザーが不利益をこうむることになってしまったりします。
逆に、ソースコードの中身を重視するあまり、ユーザーがとても使いにくい機能になると、プロダクトの価値が下がってしまいます。
両視点をバランスを取って程よい落としどころを見つけることがプロダクトとしては重要になります。
このように、QAはユーザー視点のテストを担っていますので、ユーザーの代弁者として振る舞えるように、常に情報収集し続けなければなりません。
さらに言うと、QAではプロダクトのファーストユーザーであるべき、と定義しています。
同じプロダクトに長く関わっていると、当然ユーザーとしてもベテランの域に達してきて、初めて触った人の気持ちが分からなくなってしまいます。初めてのユーザーにはそのプロダクトの「当たり前」は通用しません。
だからこそ、「ファーストユーザーならどう感じるだろう？」と自問自答し続けないと、どうしてもプロダクトに慣れたユーザーの視点しか出てこなくなってします。
新規・既存双方のユーザー視点も持つことは、必ずQAとして優れたアウトプットを出すことに結びつくでしょう。
2. テスターではなく、プロダクト開発者である
QAエンジニアはテスターではなく、「プロダクト開発者」であるという定義をしています。
ここでQAエンジニアとテスターを区別しているのは、役割が違うからです。前者は「品質保証する人」であり、後者は「テストする人」です。すなわち、両者はやるべきことも異なれば、目的も異なるのです。
QAが品質保証するためには、まず現状の品質状態を明らかにし(明らかにするための1ツールとして「テスト」を行います)、そこからどういう品質にすべきか戦略を立てアクションしていきます。そして品質を高めるためは、開発の協力が必須となります。
開発と一緒に品質を高めていくうえでは、仕様策定や開発のテストなどについて、QAならではのユーザー視点で積極的に関わっていく必要があります。
このように、QAはテストだけやっている、ということはなく、プロダクト開発者の一員として自らの専門性を重んじ、開発と協力しながらプロダクトを作っていくということをやっています。
3. 開発とは対等であるべき
前項でQAはプロダクト開発者の一員として開発と協力しながらプロダクトを作る、と書きましたが、そのために心がけているのは、開発と対等であることです。
開発とQAは役割が異なりますが、目的は価値あるプロダクトを作りお客さまに届けるという点で一致しています。
役割が異なっているのには意味があって、開発はプログラム視点、QAはユーザー視点でプロダクトの価値を高めていきます。
QAはユーザーの代弁者ですので、ユーザー視点でダメなものはダメと言えないといけません。そのときに、開発のほうが立場が上、となると意見を出しづらくなったり、意見がつぶされてしまったりということがあり得ます。(もちろん、QAのほうが立場が上、というのも同じです。)
目的を共有する対等な立場で、遠慮なく(しかしHRTは大事に)意見をぶつけ合うことが、価値あるプロダクトを作りお客さまに届けるために大事なことだと考えています。
4. 答えは自分で見つける
受託や請負では、「何をテストするか」(テスト対象)・「どういうテストをするか」(テスト計画)・「どういった結果になればOKか」(終了条件・品質目標)といったことは顧客や元請けから指示がある場合や、要件定義書・設計仕様書などのドキュメントから得た状況をもとに作ることが多いと思いますが、自社パッケージ開発の場合、顧客や元請けからの指示は原則無く、ドキュメントが整備されていないこともままあります。
当時、ドキュメントは必要最低限(ソースコードが仕様書です！)しか作っていませんでしたし、(立場が対等で視点も異なるため)開発から指示をもらうこともないので、QAではすべて自分たちで考えて答えを見つけていきます。
そのとき、考えの軸となるのも「ユーザー視点」です。
「ユーザーはどんな機能を望んでいるのか？」「ユーザーはどんな品質を求めているのか？」、すなわち「ユーザーが何を価値と感じるのか？」ということを以下のようなインプット情報をもとに考え、一つ一つの事項に対し最適解を出していきます。
- 対応項目 (とその詳細)
- プロダクトが現在立っているステージ
- 売り上げ状況
- サポートの問い合わせ
- 過去のテスト資産
- BTS・QAチーム内のナレッジ
- 経験則
決して楽なことではありませんが、自分たちで品質目標からスケジュールまで、すべて決められることというのはQAとしては非常にやりがいのあることだと思っています。
5. やる理由・やらない理由を考える
テストには終わりがありません。テストするための観点は考えれば考えるほど、無尽蔵に出てきます。そして不具合も(ある程度大きなプログラムになれば)無くなることはないでしょう。
ということで、やろうと思えばコストと時間が許される限りテストし続けることが可能です。そしてそれはテスト計画者からすれば非常に楽なやり方です。気にするのは優先順位くらいだからです。
しかし、現実はコストも時間も有限であり、基本的に足りないほうが多いのです。
そのため結局はテストを削らざるを得なくなります。削る際の理由が「なんとなく」や「間に合わないから」だった際に、リリース後にテストを削った箇所で不具合が検知された場合、「なぜテストしてなかったのか？」という問いに何て答えるのでしょうか？
そうならないためにも、テスト計画段階で「やる理由」「やらない理由」という理由付けを明確にすべきです。
特に大切なのは「やらない理由」で、「やらない理由」を考えることは「やらなかった場合のユーザーへの影響を考えること」であり、それは「ユーザー視点を担っているQA」だからこそ考えることができます。
品質にも大きな影響を与える判断になりますので、この過程はQAとして非常に重要なことだと考えています。
重要なのですが、「やらない理由」を考えるのは大変です。でも「やらない理由」を考えるのが面倒だから実施してしまおう、というのはご法度です。必ずプロジェクトの進行に支障をきたします。最悪はスケジュールが破たんするでしょう。
最後に
以上、10年以上の経験をもとにした、QAチームが大切にしていた5つのことを書かせていただきました。
この5つのことは相互に関係しあっていて、QAの大きな柱になっていたのだということをあらためて実感することができました。
QAはなかなかスポットライトのあたることがない印象がありますが、ユーザーにとって価値のあるプロダクトを作るためには必要不可欠な存在です。
両界曼荼羅の先にあるユーザーの満足を祈って、QAライフをエンジョイしましょう！
