QAエンジニアのmachoです。
先日開催されたJaSST’25 Tokyoに弊社estie QAチームで参加してきました。
本イベントレポートはチームのバトンリレー形式で投稿しており本ブログはそのPart 2になります。
Part 1を担当したmurashiさんの記事はこちら
Part 3を担当する山本さんの記事も近々投稿予定なのでぜひチェックしてみてください！
私自身はJaSST初参加だったのですが、同じテーマ（ソフトウェアテスト）に関心を持つ参加者が大勢集まることもあり会場の熱量は高く、各社の事例発表・話題のAI活用・技術以外にもマインドセットなど様々なテーマのセッションがあり、楽しく参加することができました。
特に印象に残っているセッションをいくつかピックアップしてまとめてみます。
D5-1）開発者主導の自動テスト導入によるバグ早期発見
スライド：JaSST2025-D5-1開発者手動の自動テスト導入によるバグ早期発見.pdf
セッションの要約
発表者は開発チーム内でSETとして活動されている方で、当初の課題は仕様→開発→テストのような開発フローの後工程に位置するテストフェーズで発見されるバグが多く開発が遅延してしまうことでした。
そこでチームで現状の開発フローの見直し・課題の特定・解決策の検討・実施をされていました。
開発フローの見直しにより見つかった課題
- 仕様誤認による実装ミス
- 開発の後工程でのテストによるバグ発見の遅延
課題に対しての解決策
- Acceptance Criteriaをチーム全員で作成
- Acceptance Testを自動化しCIで実行
解決策を実施したことによる成果
- 開発の前工程でバグが発見できるようになった
- 仕様誤認による手戻りが減少した
Acceptance Criteriaの記法はQAエンジニアも理解しやすいようにGherkin記法で統一されていました。
感想と学び
QAやSETに閉じず、開発チーム全員で課題解決に向けて行動されているのがとてもよいなと感じました。
解決策として、従来取り組まれていたユニットテストやE2Eテストに加え、新たにAcceptance Testを導入されていた点が印象的でした。このテストは外部サービスをモックした状態で実施されており、興味深い内容でした。
登壇者の方はLINEヤフーに所属されており、大きなサービスだと外部サービス連携の数も多くE2EテストとAcceptance Testのテストスコープ・実装コスト・実行速度などの差分も大きくなるのかなと想像しながら聞かせていただきました。
estieでも現在進行形でテスト全体戦略を見直していたり、Acceptance Criteriaを各プロダクトで取り入れ始めていたりとかなりホットなテーマでした。
今回の発表で取り上げられていたAcceptance TestのようなE2Eより下位レベルのテストで品質を担保していく戦略はestieでも取り組み始めているところなので、参考にしながら戦略を練り実行していきたいと思います。
テスト自動化とは話が少し逸れるのですが、取り組み始めているAcceptance Criteriaについて高速な開発サイクルの中で
- Acceptance Criteriaを作成する開発チケットの基準
- 作成する際の適切な粒度やボリュームの目安
など模索している最中のため、組織やそれぞれの開発チームに適したいい塩梅を見極め改善していきたいと思っています。
C8-1）タイミーQAのリアルな挑戦：DevOps時代の開発生産性と品質文化を創造する
スライド：タイミーQAのリアルな挑戦
セッションの要約
こちらはタイミーさんでQA Enablingチームを立ち上げて1年間の取り組みと今後の挑戦についての内容でした。
組織体制は開発チームが16チームあるのに対してQAチームは6名と比較的少人数で構成されています。
QAチームの中にもQAコーチとSETの2ロールが存在しておりそれぞれが別の役割を担っているようです。
QAコーチ：直接テスト工程を請け負うのではなくスクラムチームの品質向上能力を引き出すスペシャリスト。
様々なアプローチで開発チームの自律的なQAケイパビリティの向上支援をされている中で、障害の重大度の判定基準に「Severity Level(SEV)」を導入されたお話をされていました。
当初、障害発生時に影響度が判断できない仕組みでエスカレーションに時間がかるなどの課題を抱えられており、その対策としてSEVで基準を明確化し、レベルに応じた対応強度のガイドラインを設計することでエスカレーションの迅速化と対応コストの最適化を図られていました。
SET：自動テストの作成だけでなくテストの実効環境の構築やテストデータ整備など継続して運用していける状態を構築するスペシャリスト。
SETが立ち上がる以前から自動テストは開発エンジニアが実施されていたようですが、チーム数が多いため取り組みにばらつきがあることが課題だったようです。そのため現在稼働しているテストをまとめ、テストの目的ややり方を整理し改善活動を実施されていました。
今後はCritical User Journey(CUJ)を基盤とした品質基準の策定に取り組まれる予定のようです。
感想と学び
QAコーチとSETにロールを分けて、プロセスやテストスキルと自動化推進の両軸からアプローチされているのがよいなと感じました。
またインシデント対応時は必ずQAも参加されていることや、テストは開発チーム全員で実施されていることなどから開発チームとの距離の近さが伺えました。
一方でQAコーチとSETにロールを分けてはいるものの、業務に強い境界があるわけではなくお互いに越境し合っているとの話もあり、あえてロールを分ける判断に至った背景や意思決定のプロセスもぜひ聞いてみたいポイントでした。
estieに当てはめてみると
開発チームが多いこと：未公開のプロダクトを含めると10ほど存在し、開発チームメンバーは50人以上在籍しています。
QAの割合が少ないこと：現在3名体制で、2024年末までは1名でした。
開発者全員でテストをしていること：QAが所属していないチームも多く存在し、開発者自身がテストを実施しています。
など、前提条件や組織文化も似ており参考にできそうな部分が多いなと感じました。
イネーブリング活動には限界があるので品質基準の策定を進められているという話も、うんうん頷きながら聞いていました。
弊社も同様で全てのチームにQAが常に関与することは現状難しいため、テスト戦略や品質アプローチの基準作りに取り組み始めています。
とはいえプロダクトごとにフェーズや特性、メンバー構成などもそれぞれ違うため一概に標準化して全てのチームに適用すればよいというものではなく、そこが難しいポイントだと感じています。
標準化できる部分は標準化しつつ、各プロダクトの現状に合ったものを取り入れていけるような基準作りをしていきたいと思っています。
まとめ
初めて参加したJaSSTでしたが様々なセッションでソフトウェアテストやAI活用などの潮流について触れることができとてもいい機会となりました。
また、SNS上でしかやり取りしたことのなかった方々に初めてお会いできたりと人との繋がりを作るにもいい場だと感じました。私は一人QA時代が長かったこともあり、もっと早く参加しておけばよかったと感じました。笑
各社の事例発表では、組織やプロダクトによってQAチームの在り方も様々で、現在のestieに当てはめて考え自分たちがどう価値を出していくのか、どんなスタンスで取り組んでいくべきかを改めて考える良いきっかけとなりました。
二日目の最終公演「A10）「真の学び」が未来を拓く～ 成長するエンジニアのマインドセット ～」では、実戦こそ全て 学んで実践を繰り返すことが大事である。という強いメッセージを受け取りました。
急に会社の話になりますが、estieにはPurposeとは別にValuesというメンバーの行動規範が定められています。
私はどちらかというと業務をスピーディーにこなすよりは、時間をかけてじっくり進めていくタイプの人間だと自認しています。それがいい方向に働く場合もあるのですが、この進め方がValuesの「今日変化を生もう」を体現する際のボトルネックになってしまっているのではないかと以前から考えていました。
本セッションを通し、学んだら早く実践し、反復する。ことの大切さを再認識しました。
このマインドセットを意識して個人としてもチームとしても成長し強くなっていきたいと思いました。
私のイベントレポートは以上となります。
ここまで読んでいただきありがとうございます。弊社estieやQAチームに興味を持っていただけましたら是非カジュアル面談しましょう！
気軽にお申し込みいただけますと幸いです。
次回、JaSST'25 Tokyo 参加レポート Part 3(ラスト) もお楽しみに！
