👨‍👩‍👦

3人で分担して1人分のQAチームを立ち上げた話

 
みなさんこんにちは、プロダクトチームのmoeです。
現在シェルフィーには各チームから集まった兼任のQAチームが存在します。その立ち上げから今までをお伝えできればと思います。

QA立ち上げの経緯

QAが立ち上がったのは2021年秋のことです。
当時はエンジニアもパワーアップし、リリースが非常に増えていました。 建設業界の複雑性によるサービスそのものの複雑度もあり影響範囲調査が難しく、またリリース頻度の増加も相まってデグレードの数も増加傾向にありました
デグレードの対応時間やプロダクト品質の低下が社内で問題となっており、 役員の石川が現実問題今あるリソースの中でプロダクト品質をできるだけ高く担保できる体制を整えたいと考えたことがきっかけです。
特にリグレッションテストに伸びしろがあり、導入されたのが「ソフトウェアテスト自動化プラットフォームのAutify」でした。
 
元々シェルフィーにはQA担当は存在せず、エンジニアが動作確認をした後にPdM(1名)がUIも含め最終確認をして本番リリース、という流れでした。 E2Eテストでは主に変更箇所に対するテストをしており、リグレッションテストは必要に応じて、という感じで明確には行われていませんでした。 デグレードの原因も影響範囲の考慮漏れで想定外の箇所が影響を受けたことによるものが多く、ここの対策を行うことでデグレードを減らせると考えました。
そこで、Autifyでリグレッションテストを自動化してリリース前に必ず実行できるように、またPdMが1人でやっていたテストもQA(複数人)で対応できるように組織化しようとQAチームが誕生しました。

実際にやったこと

まずは一番大事なメンバーです。
QAチームのメンバーはPdM、プロダクト推進(一般的にはCSの役割に近い)、エンジニアから3人が集まりました。 元々テストを主に担当していたPdMを筆頭に、ユーザーにより近い立場であるプロダクト推進、開発に近い立場のエンジニアという、各チームのノウハウが活かせるように横断的なチーム構成を意識しました。
また、AutifyのCSから「色々なチームを巻き込んで始めるほうが成功率が高い」というアドバイスもあってこのようなメンバーに落ち着きました。 (とても前向きに書きましたが、、実際はリソース的に専任をアサインする余裕がなかったため3人でなんとか1人分を生み出そうという気持ちもありました。)
実際の作業としては、Autifyを含めQAのやること、やらないこと、ロードマップの作成から始まりました。
これまでの議事録。当初は週1でMTGをして改善を回していました。
これまでの議事録。当初は週1でMTGをして改善を回していました。
 
やること、やらないことを決めた当時のまとめ
やること、やらないことを決めた当時のまとめ
 
決定したQAの大まかな作業項目としては以下です:
  • Autifyテスト作成(メイン導線)
  • リリース前手動テスト
  • リリースに伴うお知らせ、ヘルプ記事
 
メンバーそれぞれが兼任で専任のQAチームではなかったので、初回のAutifyテストを作り切るまでがQA、その後のメンテナンスは主にエンジニアが担当すると決めました。
Autifyは多少クセがあり、ある程度の慣れが必要ですが、QAで知見を溜めて共有することでエンジニアも修正しやすくなったと思います。最初の修正は一緒に見ながら進めたりしていました。
また、テスト担当者のつらみとして、リリースフロー(下記参照)の後工程ほどスケジュールが圧迫され、テスト期間が短くなってしまうことがありました。
シェルフィーではリリース日を曜日で固定せず、少しでも早く新たな価値を届けられるようにリリース可能な状態になった機能・修正からリリースしていました。 そのため、リリーススケジュールをエンジニアが握っていて「」というようなこともありました。
リリース日に追われて短期間でテストをしなければならず、プレッシャーがかかり負荷も高いので、エンジニア側でリリース日を決めることはせず、QAテスト中はQAボールにしてテストが終わり次第エンジニアに戻り、リリースするという流れにしていきました。
 
実装からリリースまでのフローの変化をまとめると以下のようになります:
🌿
実装完了 ↓ エンジニア動作確認 ↓ 手動テスト※PdMからQAチームへ変更 ↓ Autifyでのリリース前テスト(NGの場合は修正して再実行)※追加 ↓ リリース
 
このように、新たに追加するばかりでなく、これまでのヘイトポイントも合わせて改善していきました。

大変だったこと

足掛け1年ほどのチームですが、中でも大変だったのは下記2点です。
  • 兼任チームの定め
    • チーム全員が元々の業務と兼任だったため、途中でAutifyのテストづくりが止まってしまう、、ということもありました。
      それでも今はしょうがないと諦めてQA作業を一時ストップしたり、タスク調整をするなどして予定よりもだいぶ遅れながらも当初やりきると決めたところまでたどり着くことができました!
  • 大きめ機能のテスト
    • 不備チェック機能という大きな開発があり、そのテストの物量が過去最大と言っても過言でないくらいの量でした。
      通常はリリース日を事前に確定しないのですが、本機能に関してはユーザーへの影響も大きいことから事前にリリース日を決め、お知らせを出して周知していました。
      すなわち、決められたスケジュールと物量との戦い、、!となったのです。
      開発途中から並行してテスト計画を立て始め、QAチームだけではリソースが足らず、ヘルプもお願いし、なんとかテストを完了させリリースすることができました!
      仕様の考慮不足やテスト不足もあり、リリース後にいくつか修正する点もありましたが、チームみんなでやりきることができて本当に良かったです。

やってみてよかったこと

実際にリリース前にAutifyを実行するエンジニアからは
」 「
という声があり、リリースやデグレードに対する不安が減り、安心感につながっています。
QA視点からは、Autifyでは人間がやるにはつらい、難しくはないが手間なリグレッションテストを主に担っているため、QAはリリース機能部分に注力してテストできるようになったことも嬉しいポイントでした。
QAの立ち上げは1人が専任でやるイメージもあるかと思いますが、シェルフィーでは3人で分担して1人分として作業していきました。
この体制のおかげでお互いの知見をうまく活用できたり、誰かが作業できないときは他の人が代わりに多めに作業するなど協力もできたし、ときには励まし合って進められた点は良かったと思います。

今の課題

QAチームと言えども専任ではないため、Autify関連と手動テストがメイン作業になっており、バグ集計・分析については手が回っていません。 そのため、QAチーム発足後にどれだけ効果があったかが体感でしか測れていない、というのが現状です。
実際にAutifyのリリース前テストでバグが見つかったケースがいくつかあるので、一定の効果はあったのですが、結果を可視化することで、成果に対して適切に喜んだり、逆に改善点を見つけて対応したり、ということが今後できたらと思っています
他にもリソースの関係で断念している作業がたくさんあり、いわゆるQAが担っている作業で手つかずのものも多くあります。
将来的にQAが専任になったらこのあたりをどんどん進めていき、リリース時の安心感とプロダクト品質の向上を目指していきたいと思います!
 

シェルフィーメンバーと話してみたい方はこちら!👇