3倍成長したQAの話

1年ぶりの投稿です。テックタッチでQA Project Managerをしていますshuttyです。早いもので2021年10月に入社してから1年がたちました。体感ではまだ半年くらいだったのですが、今年もノーベル賞が発表されたので、本当に1年たったのだと実感しています。2021、2022年と2年連続で学生時代の研究テーマと近い分野で受賞されていたので思い出に残る年になりそうです。

この1年の振り返り

さて、せっかくの機会なのでテックタッチに入社してからの1年を振り返りたいと思います。

組織が大きくなった

本当に大きくなりました。この1年で2倍近くメンバーが増えました（約40名→80名）。なかなか新しく入社するメンバー全員と話す機会は少なく、とくにSalesやCSMのメンバーと関わる機会が少ない点は物足りないと思うことが増えてきました。そんな課題を感じ始めていた時、有志が集まって新メンバーの1on1を設計するなど、まさに「援護があるから」を体現しているなと感動しています。また、テックタッチのオンボーディングが非常にリッチになりはじめました。毎月3-5人のオンボーディングをしているので「組織が大きくなったんだなぁ」と思うことが増えました(QAのオンボーディングのコンテンツを考えるのは大変だと付け加えます)。
QAの組織としても大きくなりました。私の入社当初の正社員数は0→1人になったばかりでしたが、2022年9、10月に1名ずつ入社、さらにもう1名内定承諾いただいているため、合計4人という4倍成長を遂げました。協力会社の方を含めても4→9人と2倍以上の成長をしています。

テストの効率が上がった/テストプロセスに向き合った

2点改善したポイントがあります
1. テストデータの再利用
それまでは、リリース毎にほとんどすべてのデータを作成して検証していました。しかし、作成したデータは次の検証では活かせておらず、使い捨ての状態でした。テストデータの作成に時間がかかり、作成済みのデータがメンテナンスしづらい状態は少量のテストの場合には課題になりづらかったのですが、プロダクトの機能が増加するにつれて課題として顕在化してきました。そこで、頻繁に利用するデータは一か所にまとめて、みんなで共有できるようにラベルやIDを振るという活動を行いました。これによって、特定のテストケースで約2.3倍の生産性向上が達成されました※１

2. テスト設計とテストケース作成の工程を分割
テストケースを作成するためには、ユーザーストーリーや仕様書が必要なケースが多いです。ただ、テストケース自体はテスト実行の際に非常に優れているものの

• テスト全体像の見通しが悪くなりがち
• 細かい手順まで記載していたのに、そもそもの前提に認識齟齬があり、ケース再作成の手戻りが発生する

といった課題もあります。

そこでテスト設計という工程を設けました。テスト設計ではテストのスコープ（画面や機能、バージョンなど）や、ディシジョンテーブルや状態遷移図を用いて、ストーリーの全体像の認識合わせや詳細な仕様を詰めることができるようになりました。もちろん、テスト設計の工程がなかった時にもこういったディスカッションは発生していましたが、プロセスとして落とし込むことができたと同時に早い段階で仕様のすり合わせができるようになったことで手戻りが少なくなったように感じています（個人の感想です）。

マネージャー制度ができた

とてもユニークなマネージャー制度なので、是非この背景なんかも記事になるといいなと思っています。自分自身がここに書くには紙面が足りないので割愛します。この後、その制度についての記事が書かれたらリンクを追加しようと思います。2022年9月から制度が始動しました。この後、マネージャー向けの研修なども予定されているので、楽しみにしています。QAチームのマネージャーとしてはQAの役割やミッションを整理し、言語化＆全社へ宣言するよい機会でした。

プロダクトの難しさに直面する機会が増えた

「テックタッチ」というプロダクトは（理論上）どんなシステムの上でも動きます。1年前くらいでは「テックタッチ」を導入するシステムはある程度固定されていました。しかし、ここ半年は本当に多くのシステムで「テックタッチ」を導入いただいており、さまざまなシステムの上で動作することを保証する機会が増えています。これからも増えていくことを考えると「未知のプロダクト上で「テックタッチ」が正しく動作すること」を担保しなければならない点で「テックタッチ」ならではの難しさに直面しているなと感じています。※2

こうして振り返ると、組織やプロダクトの成長スピードに翻弄されながらもQAと短期的に必要なものを整理整頓してきたのだなと思います。

次の1年に向けて

入社後にやりたくてもできていないことはまだまだたくさんあります

メトリクスの集積・不具合分析

不具合やテストケースの増減、実施した時間を分析することがまだできていません。データを集めるためのルールをつくり、定着するように努めています。

テスト自動化

入社後一度取り組みましたが、「今はやらない」という意思決定をしたのが約半年前でした。「テックタッチ」はプロダクトの特性上、対象システムに依存することが多く、テストシナリオを十分に検討しなければなりません。また、技術検証の結果、SaaSで提供されているノーコード、ローコードのプロダクトでは一番検証したい範囲をカバーできないことがわかりました。これらの問題を解決するよりも、手動での検証精度を高めたり、より上流工程で不具合を混入しないようにする仕組みづくりのほうが優先されると考えたためです。テスト自動化を成功に導くためにはともに自動テストに立ち向かってくれるメンバーが必要だったのです。

いずれもQAのメンバーが増えたことで分担して取り組むことができるようになりつつあります。そしてできることが増えてくればまた別の壁にぶつかることになるでしょう。今まさに成長しているテックタッチという組織の一員としてプロダクトに携わることができて非常にやりがいを感じる1年でした。2年目も全力で取り組みます！

※1：1時間当たりの消化テストケース数で評価。不具合の検出件数などは加味していないことに注意
※2：「テックタッチ」導入時の本格導入前にそのシステム上で動作するかという技術検証を行っています