QAチーム立ち上げ期〜振り返りと今

hacomonoで開発チームに所属しております、塩濱です。（社内では、はまちゃんと呼ばれております。@hcmn_hama）
最近はQAエンジニアとしてQAチームの全体管理〜自動化までをメインに動いています。
（絶賛一緒に自動化に取り組んでいただける方を募集中です！）

本記事は22年の年末（12月）でエンジニア→QAエンジニアに軸を置き換え動き始めてから1年が経過したので、その際に振り返ってみた内容となります。

1年前と変えたこと、変わったこと

チーム構成

21年の12月、プロダクトの開発からQAエンジニアとして軸を置き換え、正社員のQAエンジニアが私1人、業務委託で参画していただいているQAエンジニアは3名で、チーム発足時は4名のチームでした。それが現在は、正社員のQAエンジニアが私含めて3名、業務委託で参画していただいている方は全部で8名で、総勢11名のチームとなりました。
（11名全員で一緒に動いていくというよりは、メンバーそれぞれが開発の4チームに入りこんで品質保証の向上に尽力しています）

リリースフロー

当時、スプリントリリースというサイクル自体は動いていましたがスクラム導入期ということもあり、どのタイミングで次スプリントを開始して、などプランニング含めあまりうまくは走っておらず、とにかく出したいものをなんでもQAに回すといった形だったのでQAチームとしての負荷は高かった印象です。

また、チケット管理自体も煩雑だったので、どれがいつのリリースの対象となるのかもJira上で管理しづらかったのが走り出し初期でした。

QAが必要なものがQAされずにリリースされるリスクをはらんだ状態でした。

今はQA対象のチケットがわかりづらい問題を解消すべく、リリースバージョンのラベル管理、QA実施が必要かのラベル管理などを改善しています。
当初はQAチーム主体でラベル管理を行なっていましたが、開発チーム全体のルールとして周知され管理されるようにもなりました。

また、xxdayリリースに向けたプランニングを各チームの代表者と実施し、どの程度の分量がxxdayリリースに乗ってくるのかを担当者以外も把握できるようになり
QAとしての工数がどうなるか、という点も出せるようになっています。
（最近はもっと定量的に測りたいので、QAチーム内でも別で見積もりのプランニング、ポイント付けなどを実施し、スクラムを取り入れて動き始めました）

設計レビューなどにもQAの担当者をアサインし、仕様検討段階から不明点を洗い出したり、UIの指摘や確認なども行いやすい状態となりました。