「QAをチームではなく、活動に」アペルザのQAへの取り組み

こんにちは！ アペルザのコミュニティマネージャーをしています、松本（社内での呼び名は「まつも」）です。

今回の記事では、アペルザのエンジニアチームのEMである染谷さん、QAエンジニアの佐々木さんに話を聞いてきました。

（EM染谷さんの紹介記事はこちら）

アペルザがこれまでどのようにQAに取り組んできたのか？アペルザにとってのQAとは何か？についてお伝えしたいと思います！

QA（品質保証）とは

ーまずはじめにQAとは何か、簡単に教えていただけますか？

染谷：QA（Quality Assurance ）とは製造業から生まれた言葉で「品質保証」と訳されます。この言葉は現在IT業界でも広く使われていて、ソフトウェアなどの品質が所定のレベルに到達しているか事前に確認する手続きを効率的に構築することで、お客様へ価値の高いサービスを届けるために必要不可欠なものです。

佐々木：不具合のない安定した品質のサービスを届けることはサービスの根底とも言えると思います。

ーいまどのようなQA組織を作っているのですか？

佐々木：現在、QAに取り組んでいるのは社員2名とオフショアチームの4名、総勢6名のメンバーです。
オフショアチームが主にマニュアルテストの設計と実施を担当し、 社員の私が各環境へのリリース作業を兼務しながらE2Eテスト(※)の自動化を進めてリグレッションテストを中心に担当し、もう一人の社員がスクラムマスターやリリース/スコープの管理を兼務しながら、QAに参加しています。

※E2Eとは、End to End Testと呼ばれ、単体テストとは違いシステム全体を実稼働時に近い状況で動かしつつテストする手法です。 例：商品購入ができるサイトで、注文するために会員登録→商品を検索→商品をカートに入れ→注文→注文メールを受け取り内容を確認する…といったユーザ操作を全体的にテストすることです。

アペルザにとってQAは「守り」と「進化」を担う存在

ーQA組織というと『プロダクトの品質を守る最後の砦』のように表現されることも多いですが、アペルザにとっての QA とはどのようなものでしょうか？

佐々木：そうですね。わたしたちが提供する「アペルザクラウド」はお客様の日々の業務に使われるものなので、頻繁にサービス停止が起こる事態は許されません。お客様に安定したサービスと利用体験をお届けし、「プロダクトの品質を担保する」ことは非常に重要です。アペルザのQAでは起こった不具合を改修するだけでなく、発生しそうな不具合を未然に防ぐ役割も担って行きたいと考えています。

染谷：それに、もうひとつ。アペルザにとってQAはサービス開発とPMF（Product/market fit）達成のために、欠かすことができないものでもあります。世の中にこれまでなかった価値を提供することが使命であるスタートアップが、初めから顧客に受け入れられる完璧なプロダクトをリリースすることは不可能です。逆にいえば最小限の必要な機能を含めたプロダクトを継続的に改善し続けていくこと(※)こそが正しい「作り方」であると私は考えています。

※「小さく作る」ことの有益性はMVP（Minimum Viable Product＝顧客価値があり、利益を生み出せる最小限のもの）の考え方に詳しく解説されています。（MVPについて詳しくはこちら）

私が共感している「MVPが実際に実行可能かどうかをテストする10の方法」という記事の中では、MVPであるために重要な要素として「不具合がない」ことが条件として挙げられています。

引用リンク：https://readwrite.com/2015/08/03/minimum-viable-product-mvp-test/

染谷：品質が欠けているということは、お客様から正しい評価やフィードバックが得られない…つまり仮説検証が正しくできないことを意味します。私たちが提供している「アペルザクラウド」も製造業に特化したSaaSとして誕生した、これまでにないプロダクトです。現在ローンチから1年半を迎えていますが、全てのお客様の全てのご要望を機能化することはせず、PMFに向けて一つ一つ機能を追加し、それをお客様の改善フィードバックを受け入れてサービスをアップデートし続けています。私たちにとってこうした改善活動の土台になるのがQAです。

これまでの取り組み

ーアペルザはこれまでどんなQAの取り組みをしてきたのですか？

佐々木：QAがチームとして組織化する前は新機能や機能改善ごとにマニュアルテストを実施していましたが、「この画面は修正していないから」という理由でテストされずに意図せずレンダリングに失敗するページが出るなど、本番環境での不具合を目に見えて減らすことができない状態が続いていました。

そこで、2019年にQAがチーム化し自分がリーダーとして取り組むことになったタイミングで、これまでの不具合の原因や傾向を徹底的に分析しようと、過去1年分の不具合チケットをすべて見直しました。その結果、「要件・仕様・設計」に関する不具合よりも、「UI/UXや実装ミス」に関する不具合が多いことがわかりました。

フロントの部分に問題があるのなら、プログラムを一部修正した時に、修正がほかの部分に影響や不具合を与えていないかチェックするのが有効と判断し、E2Eによるリグレッションテスト(※)自動化に本腰入れて取り組むことになりました。

※リグレッションテストとは、ソフトウェアテストの一つで、プログラムの一部を変更・修正した際に、その変更によって予想外の影響が現れていないかテストする手法です。

染谷：テストの自動化は理想的でメリットも大きいですが、継続的なメンテナンスが必要で、足元の開発作業とのバランスを維持するには組織的な取り組みも必要で、なかなかそのメリットを享受するところまでたどり着けないケースは多そうですよね。

佐々木：はい。アペルザでは2017年からE2Eに取り組んでいます。サービスを一気通貫でテストするE2Eの自動化にはテストシナリオの設計やテストデータの設計・作成からテストの実装と失敗した時のメンテナンスなど工数がかかります。テスト自動化については、たとえば、以下のような意見が現場では多く出てくるのではないかと思います。
ありそうな心の声だと、

などでしょうか。

染谷：E2E、MVPなど…手法論は世間にあふれていますが、それを自分たちで実践し続けるのは大変で、やりきれないことも多いと思います。実際に取り組んだ人の話を聞けばキチンとやりきるまでの道のりは苦労はもちろん多いし、忍耐が必要な茨の道だとは思います。

佐々木：そんなE2Eを私たちがなぜ運用するようになったかと聞かれると、2019年にSaaSの開発に注力する決断をきっかけに、テストを遂行できる組織を整えて役割を分担したのが第一歩だったと思います。染谷さんの言う通り、E2Eは組織的に取り組めないと膨大なタスクに忙殺されてたちまち機能しなくなります。

チーム化によりマニュアルテストは4名いるオフショアのQAチームを中心に取り組み、私はそのテストのレビューやE2Eテストに取り組みます。 また今年入社したスクラムマスターと2人で役割を分担し、不具合チケットやリリース内容の管理はスクラムマスターが中心となって担当します。このようにしてチーム化することで、これまでマニュアルテストやリリース管理にも分散していた私の時間がE2Eテストの自動化に傾けられるようになっていきました。

いまは規定された障害レベルに併せてE2Eテストの実施頻度を変えて設定し、例えば会員登録時やパスワードリセット時に発生するメール内容操作のテストなど、不具合が発生するとよりレベルの高い障害になる機能については頻度を高く実行するようにし、、本番環境で実際にお客様が利用する際の不具合を減らすことができていると思います。

E2E自動テストのフレームワークについても、3年間試行錯誤してテストケースを増やし運用を続けながら、この3年間で2度の変更を行っています。Javaが書けないとテストケースが増やせない問題や、 実行時間の短縮、ブラウザの制限(IEでテストできない)など、様々な課題を一つずつ解決し、現在は「mabl」という自動テストフレームワークの利用を推進して新しい機能のE2E自動テストがかなり充実してきました。

染谷：仰るとおり、こうして振り返るとE2Eによる品質への取り組みは「組織を整える」と「環境を整える」ことの2つを小さく始め、改善し続けた3年間だったんですね。サービス開発の考え方と一緒ですね！

佐々木：そうですね、アペルザでは「小さく作る（始める・改善する）」という考えをとても大切にしていて、テストコードを作ったり新しいツールを検証する際も「まずはやってみよう」という意思決定を行うことから始めることが多いです。ガチガチに作り込んで一気に変えるのではなく、試して検証しながら少しずつ改善を積み上げて形にしていく、初めから全てのことを予測することはできないので、アペルザの事業フェーズにあっていると思います。

これらの取り組みの詳細は、先日佐々木が登壇した mablコミュニティウェビナーでの発表「アペルザの品質を支えるE2Eのグレートジャーニー」の発表資料にも詳しく記載されています。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
登壇資料URL　　アペルザの品質を支えるE2Eグレートジャーニー

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

mablコミュニティはアペルザの開発支援アドバイザーでもある藤原大さん（@daipresents）が主催しています。

mablコミュニティについて

テスト自動化サービスmablは、ソフトウェアチームが開発ライフサイクル全体にわたって信頼性の高いテストを実施できる最先端のインテリジェントテスト自動化ソリューションです。
mabl Japan コミュニティウェビナーでは、テスト自動化のエキスパートやmablを導入・実践するユーザー企業さまによる、テスト自動化のナレッジ・経験、実践的な手段を提供させていただいています。

藤原大さんプロフィール

エンジニアリングマネージャ、アジャイルコーチ、『リーン開発の現場』の翻訳者。
創造的、継続的、持続的なソフトウェア開発の実現に向けて奮闘中。
週末に娘と息子とお昼寝しながら世界のビーチや離島を旅する夢を見る。

「QAをチームではなく、活動に」

ーこれからどんなチームを作っていきたいですか？

佐々木：先ほど話したように、これまで行ってきた取り組みによって、運用を仕組み化することができ、その成果が品質に現れてきています。同時に、この3年の間に少しずつアプリが増えてきて、デプロイパイプラインが複雑になり、自動化テストに組み込みづらいという課題が出てきています。（例えば、アプリAを操作した後に、アプリBを操作するテストシナリオがあった時に、アプリAとアプリBのデプロイパイプラインが別れていると、デプロイパイプラインに組込みずらい…等）

今後はこのパイプラインを整理して、本番リリース前に必ずQAの目をパスするように変えていきたいと考えています。染谷さんが言っていたように「品質」という土台がなければ、サービスの改善は成り立たない。そうした誇りをもって、これからも高い品質を守っていきたいですね。

染谷：私はEMという立場で技術メンバーと関わっているので、技術部のこれからについて回答したいと思います。この1年で開発に関わるメンバーは12→28人と倍以上になっています。こうした組織の変化にも柔軟に対応していきたいです。例えば、ますますQAの活動量を上げるような改善をしていくこともそうだし、QAにメンバー全員が参加するような啓蒙も必要かもしれません。

佐々木：いまはQAはチームとして独立していますが、QAを「チームではなく、活動に」していくことで、テスト段階だけではなく、もっと前の工程までQAチームと開発チームが全員一丸となって開発・品質保証の両方に関わっていく環境を作りたいですね。

染谷：これまでアペルザクラウドはお客様からフィードバックを頂きながら改善してきました。そして特に最近では実際にプロダクトを操作してみて、「使いやすい・わかりやすい」とサービスを評価いただくことが増えてきたことは大きな喜びです。新しい価値をもたらすスタートアップの「小さく作る取り組み」をこれからも推進していきたいと思います。

アペルザでは幅広いポジションで積極的に採用中！ 現在募集中の職種は以下から確認できます。