ビジョナリー・QA：グロービスQAチームの理想と3つのゴール

「究極的には、QAチームは無いのが理想」と言い切るグロービスQAチームが少数精鋭で挑むチャレンジをご紹介します。アジャイル開発の品質のあり方、そして理想に至る短期・中期・長期のゴールとは？

結論ファースト

はじめに、本エントリーの要約を載せておきます。

スピードの速いアジャイル開発において、もはや品質はQAエンジニアやQAチームだけが保証するものではありません。企画からリリースまで関わるチーム全体で創り上げていくものなのです。ビジネス価値向上への貢献を使命とするグロービスQAチームは、開発チームから独立した立場でスピードと品質を両立すべく工夫したテストはもちろん、データドリブンの品質改善活動や、SM・POやステークホルダーへのアプローチを通じた上流からの品質向上および組織の品質文化醸成に取り組んでいます。QAチームがいなくても高品質のプロダクトが素早く提供される組織こそが、グロービスQAチームが掲げる究極の理想です。

QAチームがいない組織がQAチームの理想という、この少し変わった理想像は、QAチームが2020年1月に発足したときに議論して導き出したものです。当社QAチームがなぜその発想に至ったのか、またそのためにどのような取り組みをしているのかを、本エントリーではご紹介します。

そもそもQAとはどんな仕事なのか

QAはQuality Assuranceの略で、製品の品質保証に取り組む職能です。最近はソフトウェア開発の重要な一領域として認識されていて、専門職である「QAエンジニア」が広く知られるようになってきました。製造業の品質保証部をルーツに持つため「テスト担当者」というイメージを強く持っている方も多いかもしれません。

QAエンジニアはリリース時の製品品質を向上させることで、ビジネス価値への貢献を果たします。そのための主な手法が「テスト」です。「品質のプロ」の専門知識と技能を駆使し、プロダクトがお客様に万全の状態で使っていただけるかを確認します。QAによるテストに合格しないと製品がリリースできないよう定めた開発プロセスを用いている組織では、QAチームや品質保証部が「品質の番人」と呼ばれることもあります。「Made in Japan」は昔から高品質の代名詞と言われますが、その裏では品質を厳しく確認するQAエンジニアがきっちり仕事をしているわけですね。

近年では、多くの産業でITの利活用が進んで開発エンジニアの活躍の場が広がり、技術や開発手法が発展しています。それに伴い、QAエンジニアの果たすべき役割がどんどん広がっているのです。特に、当社のようにアジャイルソフトウェア開発（以下、アジャイル開発）を採用している組織では「プロダクトの品質を保証する最善の方法はテストとは限らない」と考えられ始めています。それは、私たちグロービスデジタルプロダクト開発組織のQAチームも例外ではありません。

ビジョナリー・QA

まずはこの奇妙な言葉の説明から始めましょう。ビジョナリー（Visionary）という言葉は、当社QAチームのサブリーダーが入社前のカジュアル面談で口にした次の言葉に由来します。

開発エンジニアが理想を掲げて牽引している企業はよくありますが、QAエンジニアが理想を掲げるビジョナリーなQAチームは初めて見ました。

「ビジョナリー」というと格好良いですが、当社QAチームは2020年1月に本格始動した存続1年にも満たない若いチームです。まだまだ色々なことをゼロベースで創造しなければならない状態で、自分たちの「理想」なんて語っていたら笑われてしまうのが現実です。

一方で、理想を最初に持つことができたことは強みでもあります。日々めまぐるしく業務をこなしていると、ともすれば長期的に目指していきたい姿や在り方を見失ってしまいがちですが、理想が道標となり、当社QAチームは一歩ずつ着実に進むことができているのです。

その理想は、そもそもアジャイル開発ではどうやってプロダクトの品質を高めるかを議論するところから始まりました。

アジャイル開発ではチームが品質の責任を持つ

グロービスデジタルプロダクト開発組織ではスクラムを推奨していますが、アジャイル開発には他にもXP（エクストリーム・プログラミング）・カンバン・クリスタル・DAD（Disciplined Agile Delivery）など様々な手法があります。いずれの手法であっても、従来のウォーターフォール開発との大きな違いは、やはり極端に短納期であることと、開発チームへの素早いフィードバックが求められることでしょう。このスピードは、QAエンジニアにとって簡単に対応できるものではありません。特に、QAエンジニアの主要業務であったテストは数週間から数ヶ月かけるため、リリースできるプロダクトを短期で開発するプロセスに適した手法とは言えません。

そこで、アジャイル開発においては、チームが品質を作り込むというアプローチが取られます。TDD（Test Driven Development：テスト駆動開発）やATDD（Acceptance Test Driven Development：受け入れ駆動開発）といった数々の手法が生み出されています。QAでないチームが自ら「テスト」と名のつくアクティビティに取り組むようになったのです。
長年にわたって「品質の番人」の任を一手に引き受けてきたQAエンジニアは、純粋なアジャイル開発では、その役目を解かれたといえるかもしれません。

究極的には、QAチームは無いのが理想

では、QAエンジニアの仕事はなくなってしまったのでしょうか？　そうですね……創業期のスタートアップではQAエンジニアを雇わないことの方が多いですし、グロースしてからもプロダクトチームだけで高品質なプロダクトを開発・リリースし続けられる組織であれば、QAエンジニアは要らなくなるでしょう。アジャイル開発における品質保証のあり方を議論する中で、究極的には、QAチームは無いのが理想だと当社QAチームでは結論づけています（すごいチームだと思いませんか？）。もちろん、実際にはそうはいきません。実現させるにしても、数々のハードルが待ち構えているであろうことは想像に難くないでしょう。

しかし、理想に向けた短期・中期・長期のゴールを作り、推進すれば、少しずつ近づけると当社QAチームでは全員が信じ、突き進んでいます。

短期のゴール：スピードと品質を両立させるテスト

あらゆるQAチームが、何を差し置いても実施するよう求められるタスク。それはリリースを控えたプロダクトのテストでしょう。ソフトウェア開発工程の上流にアプローチすることでバグ（不具合）の混入を未然に防ぐべきという大前提はありますが、それでも混入してしまったバグは、テストで見つけ出さなければなりません。すでに述べた通り、アジャイル開発では、品質はチームが取り組むべき課題ですが、不具合が起きた場合のリスクが大きい機能などは、QAエンジニアの知見をフル活用したテストで確認する必要があります。もちろん、スピードと品質を両立させるテストが求められます。当社QAチームではテストに際し、PO（Product Owner）やSM（Scrum Master）を含む開発チームとの綿密なコミュニケーションを取って認識の相違を防ぐと同時に、探索的テストを最初に行ってテスト対象の特徴を早期に把握します。それをもとにMind Map®で全体像を描いた上で、優先順位を決めてからテストを実施します。QAエンジニアのテストといえば仕様書を読み込んで数千・数万件のテストケースを作成する……みたいなイメージをお持ちの方にとっては少し粗すぎるやり方に見えるかもしれませんが、不具合をしっかり発見できることはもちろん、規模の大きなプロジェクトでこの方法を適用することで効果を上げています。とあるプロダクトでは、開発チームと密にコミュニケーションを取って一丸となって取り組んだことで、リリース後不具合（インシデント）を0件に抑えた実績もあります。当社QAチームのテストは重要な役割を果たしましたが、もちろんそれだけではなく、開発チームもテストに対して主体的に取り組み、両者の連携が非常にうまくいった結果、実現できたことです。こうしたアプローチを出発点に、今後さらに洗練させていきたいところです。

スクラムとの関わりという点では、当社では現時点でQAエンジニア全員が独立したQAチームに所属しています。スクラムではチーム内ですべて完結することが理想であることから、QAエンジニアをスクラムにアサインしている企業も多いと思います。しかし、当社ではそもそもQAエンジニアの数がスクラムよりも少なく、物理的に全スクラムにはアサインできません。そしてそれ以上にむしろ、スクラムに入らない独立したQAチームとして貫き通して高い成果を挙げようと様々な取り組みを進めているのです。これはQA業界でもあまり類を見ないチャレンジだと思います。

中期のゴール：データドリブンによる品質改善

プロダクト開発は1度リリースしたきりでは終わりません。リリースしたらお客様やステークホルダーからのフィードバックをもとに新バージョンの企画・開発が始まります。プロダクトの絶えざる改善はアジャイル開発の肝であると同時に、時代とお客様の要請でもあり、組織のビジネス価値の向上に直結します。

「改善は計測から始まる」という基本に立ち返り、当社QAチームではデータを駆使してプロダクトの品質改善に貢献しようと準備を進めています。メトリクスの中でもバグはプロダクトの改善につながる最も重要な情報として管理するべきであり、BTS（Bug Tracking System）を用いて効率的にバグ管理と情報取得ができるような仕組みを考えています。

「BTSも入れてないのか！」と驚かれる方がいらっしゃるかもしれません。BTS無しで品質改善をするなんて考えられないくらい、BTSが重要なツールであることは明らかです。ただ、その一方で、ツールを闇雲に入れても生産性につながらなくては意味がありません。しっかりと効果を検証し、導入後の運用も視野に入れて進めているのが現状です。

そのほか、ISO/IEC25000シリーズ（SQuaRE）で定義されている品質特性も参考にしつつ、当社のエンジニアリングマネージャーとも協力しながら、組織にとって最も効果が高いデータを取得して品質改善につなげようと取り組んでいます。

計測されなければ改善もできません。品質は投資対効果が測りにくいものですが、だからこそ、早いうちから有効な指標を使って計測し、得られたデータを根拠にして改善を進めることが大切です。その成果はすぐにわかりやすく見えたりはしませんが、長い目で見たときに、品質を左右する大きな差となって現れるのです。

長期のゴール：組織全体への品質文化醸成

高品質なプロダクトは、テストだけでは決して実現しません。また、データをどんなに揃えても、それだけではやはり実現しません。では、常に品質の高いプロダクトをリリースしている組織と、そうでない組織の差は何でしょうか。その答えは、高品質を当たり前だと考える文化です。当社QAチームではその第一歩として上流へのアプローチに取り組んでいます。

上流へのアプローチということで、主にSMやPO、ステークホルダーとのコミュニケーションを活発に行っています。各チームのSMと連携し、統一された「完成の定義（Definition of Done）」を作成したり、ユーザーストーリーを承認する会議体に参加して品質の観点からバグが混入しないよう取り組んだりしています。

品質文化醸成はすぐに結果が出ない活動です。しかし、しっかりした品質文化を作り、改善し続けることができれば、今よりももっと素晴らしい組織に進化できます。未来を見据えたアクションを、当社QAチームでは日々取り組んでいます。

結論ラスト

さいごに、本エントリーの要約を載せておきます。

スピードの速いアジャイル開発において、もはや品質はQAエンジニアやQAチームだけが保証するものではありません。企画からリリースまで関わるチーム全体で創り上げていくものなのです。ビジネス価値向上への貢献を使命とするグロービスQAチームは、開発チームから独立した立場でスピードと品質を両立すべく工夫したテストはもちろん、データドリブンの品質改善活動や、SM・POやステークホルダーへのアプローチを通じた上流からの品質向上および組織の品質文化醸成に取り組んでいます。QAチームがいなくても高品質のプロダクトが素早く提供される組織こそが、グロービスQAチームが掲げる究極の理想です。

最初に読んだときと比べて印象が変わっていれば、本エントリーでちゃんと当社QAチームのご紹介ができたということかなと思います。ご感想とともにSNSで拡散いただけると幸いです！

QAチームでは理想を一緒に追いかける仲間を募集中です！

品質をはじめとする数々の課題に対して、あまり類を見ないアプローチでトライしているQAチームだと思います。ここに書ききれなかったことも含めて包み隠さずお話しするカジュアル面談を随時行っておりますので、ご興味のある方は本エントリー執筆者のTwitterアカウント（@mkwrd）までお気軽にご連絡ください！