こんにちは。ニーリーQAチームの関井祐介です。
前回の開発組織の紹介の記事を受けて、今回はQAチームについてお話ししたいと思います。

QAチームのこれまでの歩み　

私の入社エントリでも少しお話しましたが、ニーリーでは、2022年3月に1人目のQAが参画し、そこから約1年間1名QA体制の時代が続きました。2023年2月にQAチームが発足し3名体制になり、2023年8月から5名体制になっています。それぞれのタイミングでどのような取り組みを行ったか簡単にお話しします。

1人目QA時代

まず、1人目QAがジョインすることになった経緯ですが、それまではテスト担当者がいたものの、手動テストがメインになっており、なかなかデプロイ頻度が上がらないという課題がありました。また、テスト担当者が別のチームに移ることになり、新たにQAを募集する必要が出てきました。そこで、手動テストスキルに加え、E2Eテスト自動化を行えるQAエンジニアを募集し、1人目のQAエンジニアがジョインすることになりました。

1人目QA体制時代に行われたことは下記の3つです。

• 開発チケットごとのテスト

• リグレッションテストの刷新

• Autifyの導入

まず、開発チケットごとのテストですが、この時代はQAは1名しかいなかったので、各チケットのテストは基本的に開発者が実施し、QAは探索的にテストを行うことで開発者が自身で見つけづらい不具合を検出することを目的としてテストを実施していました。

また、1人目QAがジョインする以前からリグレッションテストは実施されていたのですが、シナリオが不十分だったため、拡張を行いました。Autifyを導入するまでは全て手動でリグレッションテストを実施していたため、開発者含め5-6人で半日かけてテストを行っていました。

Autifyは、先述したテストの自動化が進まないとデプロイ頻度が上がらないという課題感から導入されました。まず、なぜ自動テストの内製化ではなくSaaSを使う判断をしたのかというと、テスト自動化することで開発者のQAコストを下げ、デリバリーまでのリードタイムを短くすることで、デプロイ頻度をあげることを早期に達成したかったからです。そのために、内製ではなくSaaSを積極的に利用する判断にしました。また、なぜAutifyなのかという点については、当時一番勢いがありそうだったからということでトライアル検証をし、完全ノーコードとはいかないものの、JSステップを実装できる体制も整っており、リグレッションテストの自動化や拡充ができる目処も立ったので本導入に至りました。

最初はトライアルも兼ねてPark Directで使えるものなのかを検証し、やりたいことができることが確認でき次第、約半年かけてリグレッションテストのシナリオを自動実行できるよう進めました。ある程度テストが自動化できたタイミングで、手動のリグレッションテストはQA1人で実施しても半日で終わるくらいまで自動化できました。

QAチーム発足

9ヶ月くらい1人でQAをやっていたわけですが、1人でできることには限界があり、日々のテストとAutifyのメンテナンス以外のことは何もできない状況になっていました。テストだけでなく、シフトレフトのようなプロセス改善や仕組みづくりなど、体系的なQAをやっていきたいという思いで採用活動を進めていくなかで、2人目のQA（これが私です）がジョインし、これをきっかけにQAチームの立ち上げが決まりました。

QAチーム発足後、まず現状の課題について議論し、何を優先的に取り組むか決めました。全体としては属人化が大きな問題であり、バグの修正判断やテスト設計の精度が人によって異なることやルール面もあまり整備できていないこともあり、まずはそれらの課題を中心に解決していくことにしました。

挙がった課題の例

そして、以下が主に行ったことです。

• バグレベル定義と変更障害率計測

• テスト管理ツールの導入

• テストプロセスの整備

チーム体制になってまず行ったことはバグレベルの定義です。それまでは感覚的に重大なバグなのか、軽度のバグなのかを判断していましたが、判断する人によって差が発生するのは良くないので、バグレベルの判断基準を明確にしました。また、その上で、バグレベルが一定以上のものをインシデント（障害）として、Four Keysの変更障害率の計測を開始しました。
※バグレベルと変更障害率については近日別の記事で詳しく紹介する予定です。

次に、テスト管理ツール導入を行いました。それまではJIRAの開発チケットにテストケースを記載するという運用をしていたのですが、それでは資産にならないという課題感からテスト管理ツールの検討を進めました。結果として、ツールを導入したものの2ヶ月くらいで使用するのを中止しました。理由としては、次にお話するテストプロセスの変更により、QAではなく開発者がメインでテストを設計・実施するようになったためです。ただ、ダラダラ使い続けず状況に応じてスピード感のある決断を行えたのは良かったと思います。

テストプロセスの整備では、テストプロセスを白紙から考え、今の開発体制でどんなプロセスがベストであるかを考えました。テストプロセスを見直す前は、開発者が実施するテストとQAが実施するテストで被っているテストケースが多くありました。また、テストの環境差分（開発者はローカル環境、QAは検証環境でそれぞれテストを実施）による不具合はほとんどなかったため、新しいテストプロセスの方針としては、網羅的なテストはE2E含め開発者が行い、QAはそのレビューと探索的テストを行うといったプロセスになりました。

現在の体制

QAチームが5名体制になってからは、QAと開発との関わり方で様々な選択肢を考えられるようになりました。特に、各チーム専属のQA（以下、インプロセスQA）をアサインできるようになったのは大きな変化です。これまではQAチームとして各開発チームの開発案件に対応していたため、チーム一律に同じテストプロセスになっていたのですが、インプロセスQAをアサインする（開発チームのメンバーになってもらう）ことで、より各チームに合ったテストプロセスの導入ができるようになりました。

同じプロダクトを開発していても、チームごとにミッションが異なるので、そのミッションに合わせたQA活動を行うことで、より品質やアジリティの高い開発が行えるのではないかと思います。

また、チームに属さない横断的なQAのポジションのメンバーもアサインすることができ、Autifyのカバレッジ向上やドメイン知識のドキュメンテーションなどもこの体制になったことで進めやすくなりました。
現在の体制になってからの取り組みはこちらの記事でも語られているので、読んでいただけると嬉しいです！

チームミッション

QAチームのミッションは下記の2点です。

• 品質とアジリティの両立

• 品質の担保に加え、品質に関わる開発プロセスの改善にも取り組んでいく

それぞれ簡単に解説します。

品質とアジリティの両立

今でこそ品質とアジリティがトレードオフではなく、ともに高め合えるものであるというのが一般認識になりましたが、それでも両立するのが簡単ではないことは間違いありません。スタートアップで事業が急激に伸びているフェーズでは、どちらかというと品質よりもアジリティを上げていくことに重きが置かれる傾向にあると思います。しかしPark Directはビジネスロジックが複雑なためバグが混入したときの影響範囲が広くなりがちで、また決済機能も有しているというのもあり、品質面で手を抜くことはできません。決して品質に妥協せず、かつアジリティも向上させていくことがQAの重要なミッションだと考えています。

品質の担保に加え、品質に関わる開発プロセスの改善にも取り組んでいく

テスト活動はもちろん重要ですが、“QA”という役割であるからには、テストに限らず品質に関係することであれば何でもやる必要があると考えています。
テストプロセスに留まらず、開発プロセス全体で品質を向上できるようなプロセスを検討し、かつアジリティも向上させられるようなプロセスを開発メンバーと一緒に考え、実践していくこともQAチームのミッションとしています。

現在、取り組んでいること

現在QAチームとして注力していることは4つあります。

• リードタイムの計測と改善

• ドメイン知識のドキュメンテーション

• シフトレフト

リードタイムの計測と改善

QAのミッションとして「品質とアジリティの両立」があるという話をしましたが、これまではQAチームとしてアジリティの指標は決まっていませんでした（開発組織全体のアジリティ指標としてはリリースサイクルを計測しています）。

今年の後半から、開発組織全体でアジリティの指標として新たに開発サイクルタイム（開発着手からデプロイまで）を計測する方針となり、QAでもQA活動の影響が及びやすい開発リードタイム（開発着手から検証環境へのマージまで）とQAリードタイム（検証環境でのテスト）をそれぞれ計測し始めました。

現状はざっくりとした粒度で計測を開始したばかりで、様々な施策を実行した結果、アジリティが全体的に改善したかどうかの粒度でしか測れない状況ですが、将来的にはどの工程がボトルネックになっているかを判断できるような粒度で取りたいと考えています。

ドメイン知識のドキュメンテーション

以前から開発組織の中で、エンジニアがドメイン知識をキャッチアップしづらいというのが課題になっていました。開発時にドキュメントは作成しているもののそれが更新されておらず、どこに最新情報があるのかもわからない状況だったりと、ドキュメントからドメイン知識をキャッチアップするのが難しい状況でした。

そこで、開発メンバーがドメイン知識のキャッチアップをしやすくなるよう、ドキュメンテーションを行う活動を始めました。
これは誰がやるかという問題もありましたが、ドメイン知識に詳しい（また詳しくなければいけない）QAチームで行うのがベストだと思い、これまでの機能を整理し、重要度の高いものから順にドキュメンテーションを行っています。

これからジョインするメンバーには、以前と比べるとドメイン知識がキャッチアップしやすい環境で入っていただけると思います。

シフトレフト

シフトレフトはQAチームが発足した当時から少しずつ取り組んでいることではありますが、最近では検証環境（Staging環境）にデプロイされる前に開発と並行してQAのテストを行うような取り組み（パラレルテストと呼んでいます）をしています。

これにより、検証環境へのデプロイ後にはAutifyによるリグレッションテストを実行するだけでリリースできる状態にし、デプロイからリリースまでのリードタイムを短縮することができています。
また、上流工程からのアプローチも強化しており、Design Docsが書かれた際はQAもレビューに入るようにしており、上流から品質を作り込めるようサポートしています。

今後やりたいこと

品質を担保しつつアジリティを上げていくためには、開発前半で品質を作り込み、開発後半では品質が高い状態でテストに臨むことが重要だと思っています。そのためにはシフトレフトが鍵となるのは間違いありません。

先述の通り、検証環境でのテストはほぼ自動テストだけで済むようなプロセスになっているチームもあり、今後はそれを他のチームに展開したり、さらに品質やアジリティを向上させられるよう取り組みを加速させていきたいです。

現在、あまり取り組めていないこととしては、システムテスト以外のテストレベルにおけるテスト（単体テストや結合／APIテストなど）を考慮したテスト戦略の検討です。システムテスト（E2Eテスト）の比重が大きくなってしまうとアジリティがなかなか上げられないと思うので、そうならないようテストピラミッドを最適化していきたいです。

また、テストで検出した不具合のデータは取っているものの、レビューで指摘した不具合についてはほとんど管理できていないため、何かしら管理できる仕組みづくりが必要だと思っています。不具合データもまだ上手く活用できていないため、不具合分析の取り組みも加速させていきたいです。

最後に

ニーリーでQAエンジニアとして働く魅力は大きく2つあります。

• 開発者とQAの関係性が良い

• QAチームの未来を一緒に作っていける

開発者とQAの仲が悪い組織の話もたまに聞きますが、ニーリーでは開発者とQAがお互いにリスペクトしており、良いプロダクトを作っていくという同じ方向を見ています。そのため、QAの提案も受け入れてくれますし、多少開発の負荷が高くなるとしても、開発全体やプロダクトにとって良いことであれば受け入れて実践してもらえています。このような文化があるので、QAとしては非常に働きやすい環境なのではないかと思います。

また、QAチームが発足してから約1年経ちますが、1年前に今のような状況になっているとは思っていませんでしたし、半年前でも今のような体制になることは想定していませんでした。これから先3ヶ月後、半年後にどのような体制や取り組みをしているかも正直わかりません。明確に半年後や1年後のゴールを決めて活動するのではなく、刻々と変化する状況に対応し、今、さらにその先の未来にとってどういうQAが良いのかをチームメンバー全員で作っていけるのは大きな魅力だと思います。

QAチームにはまだまだ課題がたくさんあります。
特に、QAにおける自動テストの取り組みはAutifyの運用以外はできていないので、今後はそこに注力していきたいと考えています。それを加速させるためにも、自動テスト（単体テストからE2Eまでどこでも）に知見のある方（SET）を積極的に募集しています。これからも開発組織は拡大していきますので、QAエンジニアも絶賛募集中です。品質とアジリティの両立を追い求めている方、プロダクトとチームともに成長している組織で自身も成長していきたいと考えている方はぜひ一緒に働きましょう！

株式会社ニーリー　プロダクト開発本部　プラットフォーム開発グループ
関井 祐介　Yusuke Sekii
2017年に半導体メーカーに新卒入社。車載カメラや測距センサーの信号処理SWなど、組み込み系製品を中心に品質保証を担当。また、2020年よりQA業務と並行して、UX改善やAI製品の品質保証にも従事。2023年1月に株式会社ニーリーにQAエンジニアとして入社。

herp.careers O01【エンジニア】オープンポジション

株式会社ニーリー

募集要項をみる

■開発メンバーとのカジュアル面談はこちら

・三宅 克英（取締役CTO）
モビリティSaaSのプロダクトグロースについてお話しましょう

・菊地 弘晃
Mobility SaaSを一緒に開発しませんか？