QA組織の立ち上げと価値あるテスト設計のために必要な3つのこと

QA（Quality Assurance）の考え方は昔からあるものの、近年になってQAエンジニアという役職が明確なかたちで登場しはじめ、大企業からスタートアップまで規模を問わずQA組織を立ち上げる企業が増えてきています。

一方で、どのようにQA組織を立ち上げたらいいのか、どのようにQAを開発チームに浸透させていくのかがわからず、試行錯誤を重ねる企業や組織が多いのも事実です。

そこでFindyでは、1/24(火)に「テスト自動化のススメとQAの海外_国内事例」と題してQAをテーマとしたイベントを開催。ローコードのテストツールを展開するmablのodashoさんとマネーフォワードでQAエンジニアをされているhonaminさんに登壇していただきました。

イベントでは、国内・海外の事例を元に、QA組織の立ち上げや価値あるテスト設計に向けて重要なことをお話いただきました。本記事では、重要な3つのポイント（1.目的の整理 2.開発組織 3.ツール）と具体的な事例をまとめさせていただきました。

■パネリスト
honamin / Honami Tatekawa@honamin
株式会社マネーフォワード
QAエンジニア
カスタマーサポート＞QAエンジニア＞カスタマーサクセス＞QAエンジニアをしています。テスト自動化スペシャリストを目指して奮闘中…！夢はうどんを作ることです。

odasho / Shohei Oda @odashoDotCom
mabl Inc.
Product Marketing Manager
国内SIerにてインフラやPaaS App開発まで幅広く経験。その後コミュニティ活動をきっかけにMicrosoftに入社し、EvangelistとしてAudience Marketingに従事。2022年10月にmablにJoinし、TestingやQAの啓蒙活動に取り組む。現在も DevRel Meetup in Tokyoを中心に複数のコミュニティを運営/支援。その他、書籍の執筆や大学講師等。Most DevRel Committer 2020, TechFeed Expert for DevRel, iPhone絶対並んで買うおじさん (2011 - 2022), リングフィットアドベンチャーで激やせおじさん (-16kg/2M)

テストの目的はユーザーにより良い体験を提供すること
”テストファースト”な開発によって目指す理想の開発組織
価値あるテスト設計に向けて使っているツール
世界的なDevOpsの流れとテスト自動化
- 今回ご紹介いただいたテスト自動化ツール “ mabl” についてはこちらから

テストの目的はユーザーにより良い体験を提供すること

そもそもQA組織とは、どのような立ち位置で、どのような役割を担っているのでしょうか？

odashoさん：QA組織の立ち位置ですが、組織全体を見るチームもあれば各チームの中に専任で置くケースもあるなど、会社によりさまざまです。自社のチームや組織に合った立ち位置を模索していくのが正しいのではないかと感じています。

立ち上げ後のQAエンジニアの役割として大切なのは、現状分析をすることです。具体的には、テストの必要性やテストの内容をディスカッションすることは最低限としてやるべきでしょう。どこに目標を置き、達成するためにどのようなテストが必要なのか、ちゃんとブレークダウンしていくことが重要です。

みなさんもご経験があるかもしれませんが、テストをパスすることが目的になっているケースがよく見られます。よくあるパターンではありますが、それはあくまで結果をお知らせするためであって、テストの本懐ではありません。そのテストは何のために行うのかというと、元を正せば品質を担保するためなのです。

そしてその先にあるのは、カスタマーエクスペリエンスです。重要なのはその先にいるお客さまにより良い体験を提供すること。どんな方でも使い勝手の良いサービスを提供することが本来の目的であり、そのためにテストがあります。そこからちゃんとブレークダウンして、一つひとつのテストが正しいか、本当に必要なのか、そういった棚卸からスタートすることがとても重要です。

”テストファースト”な開発によって目指す理想の開発組織

マネーフォワードではどのようにQAに取り組んでいらっしゃるのでしょうか？

honaminさん：マネーフォワードでは現在BtoB、BtoCに関わらずたくさんのプロダクトを提供させていただいています。私自身はビジネスかつバックオフィス向けの「マネーフォワードクラウド」製品の内、人事労務領域（HR）に関するプロダクトを作っているHRソリューション本部の開発部に在籍しています。

HRソリューション本部のQAグループは、開発部横断型の組織なので、QAエンジニア自体はそれぞれのプロダクト開発チームに担当制でついています。すべてのチームでQAエンジニアの役割が一貫しているかというと、実はそうではありません。プロダクトやチームの成熟度によって課題が異なるので、QAエンジニアは皆それぞれ異なる役割を持って活動しています。

開発組織全体として目指す姿は、「品質の最適化」に向けた取り組み自体が日々の開発フローに自然と組み込まれていること、また開発エンジニア自身がその品質を担保する方法を知っていること、それを実際に開発に組み込めている状態でリリースができる組織です。

私がQAを担当している人事管理チームでは、開発エンジニアが機能の実装前にテスト仕様書を作成する”テストファースト”な開発にチャレンジしています。先に作ってあるテストに通るように機能を実装していくので、「品質を作り込む」という本来やりたいことができるのがこの開発のメリットです。

テストはマンパワーさえかければ実施できるものですが、実際はそれが難しいという組織が多いでしょう。そのためどうやれば効率の良い最適なテストができるのか、最適な部分はどこにあるのかを探求することが必要になってきます。

そこで今は、そのチームに最も合っているテストプロセスを見つけることを課題として取り組んでいます。

価値あるテスト設計に向けて使っているツール

── マネーフォワードではどのようなツールを使用されているのですか？

honaminさん：会社全体でさまざまなツールを使っていますが、私がいるHRソリューション本部では「mabl」を利用しています。他の部署ではMagicPod、グループ会社ではAutify、あとはSaaSのツールを使わずにコードベースのE2Eテストフレームワークを使っている組織もあります。

── 具体的にどうやって調査して決めたのでしょうか？

honaminさん：入社したときに、まず社内調査をしました。E2Eテストを行っているエンジニアにインタビューして、どういったツールを使っていて、どのような価格感で、どういった課題があるのかを聞いて回りました。あとはWebで検索しましたね。見積もり依頼をして、実際に担当の方と話すなどして地道な調査を行いました。

導入の基準として開発エンジニアでなくてもテストが作れることが一番にあったので、コードベースのツールは候補から外しました。また、複数のプロダクトの存在を考えたときに最適なツールであることを基準としていました。

── 最初のツール選定はQA組織としてどのように始めるのがいいのでしょうか？

honaminさん：最初は、自分たちが実際にE2Eテスト自動化を運用できるのかという点を見極めるのが大事です。

具体的には、なぜテスト自動化をやるのか、それはなぜE2Eテストなのかといった目的や運用のイメージをステークホルダーの方々とすり合わせしておくことが大切です。E2Eテスト自動化を導入するととても楽になるというイメージを持たれる方がいますが、実際はそうではなく、「こういう運用が増えるんだよ」と具体的なイメージを持ってもらうようにしています。

テスト実装のフェーズでは1本でもいいので価値のあるテストから回していって、どんどんカバレッジを上げていくほうがいいと個人的には思っています。

ただし、どんどん実装していけばいいというわけではありません。どんなテストをどんな優先度で実装していくのか、そのテスト設計がとても重要であり、QAエンジニアとしては一番寄与できる腕の見せどころです。

odashoさん：mablでは「品質エンジニアリングジャーニー」を掲げています。一番下が開発後に手動でテストをする、かつてはウォーターフォールモデルでよく見られた手法です。上に行くにしたがって成熟していくので、いろいろなデータがたまってきます。

そのデータをもとに改善を進め、最終的にQAというよりQE＝品質エンジニアリングに変革していく必要があるというメッセージを発しています。

下から2番目のようにカバレッジを拡大したり、組み込みをしていくにあたっては、テスト管理できる状態や維持しやすい状態を作ることが必要です。あとはテストの内容を棚卸して要不要をちゃんと判断して、適切なタイミングで適切な範囲の適切なテストを行うことです。どうしたら最初に掲げた品質目標を達成できるのか、というところからブレークダウンして一歩一歩進んでいくことが大切だと考えています。

テスト自動化については、この品質エンジニアリングジャーニーをもとにスタートするべきだと考えています。繰り返しになりますが、管理がしやすい/維持しやすい実現方法は何かというところからディスカッションして、それを叶えるためにツールを選定するということです。

世界的なDevOpsの流れとテスト自動化

odashoさん：「Testing in DevOps 2022」というものを公開しましたので、ここでは重要なポイントだけを簡単に紹介します。

大企業ほどDevOpsの採用が進んでいる
DevOpsを妨げるのは技術でなく文化である
ほとんどの組織でデプロイ頻度が上がっている

DevOpsに注目が集まっています。テスト自動化についてはDevOpsやCI/CDパイプラインに統合する文脈で語られることが多く、実際にそうなっています。デプロイが自動化されるのもそれと一緒です。デプロイ頻度自体も昨年、一昨年と比べて向上している傾向です。

DevOpsの採用は、日本だとまだまだ3割ぐらいと言われています。しかし世界的なトレンドでもあるので、これからどんどん伸びていくでしょう。

この調査によって、テスト自動化やさまざまなツール、カルチャーの変革も結果的にカスタマーエクスペリエンスの向上に寄与している、ということが判明しました。

──海外におけるQAの事例について、教えていただけますか？

odashoさん：mablは、ノーコード/ローコードのUIテスト、APIテストのサービスを提供している会社です。CI/CDパイプラインに統合し仕組み化できるので、DevOpsとの親和性が高いのが特徴です。

海外拠点での事例として、日本でのユーザーも多いStack Overflow社の事例を紹介します。テストを手動で行っていると当然無理が来てしまいます。そこで、CI/CDパイプラインに乗せて自動でテストを実行できる環境を構築しました。これによって、早期でバグを発見し、早めに修正できるような環境づくりができたのです。