見出し画像

QAシフトレフトの取り組み

Kenji Serizawa

ごあいさつ

こんにちは。カラクリ株式会社の芹沢です。
日々忙しく活動しており、しばらく記事が書けていませんでした…。

今回は、当社のプロダクト開発で行っている「QAシフトレフト」の取り組みについてご紹介します。なるべく具体的なイメージが掴めるように意識しながら書いてみました。

また、この記事を書いた背景は以下のとおりです。

  • 品質保証・品質管理の業務に携わる方へ共有したいと思ったこと

  • お客様が当社のプロダクトを安心してご利用いただくために、当社のプロダクト開発における品質改善活動のことを知っていただきたいと思ったこと

ぜひご一読いただけたら幸いです。

QAシフトレフトとは？

プロダクト開発の背景

複雑な新規機能の開発や、既存への影響が大きめの開発（既存への考慮が多く必要なもの）が増えてくる中で、開発時の抜け漏れも増えていました。例えば、リリース前のQAテストでの不具合検知の増加や、条件別での機能不備などがあります。

また、これによりリリース前のQAテストの負荷が増えたり、機能リリースの遅延も発生し始めていました。一般的によく起き得るお話と同じなので詳細は割愛します。

改善活動

そこで、不具合事例から問題提起し、改善を皆で考えることにしました。少し大きめの「開発活動の振り返り」です。振り返りは、各メンバーから課題の募集を事前に行い、集まった課題一覧を基に開催することにしました。各自から様々なものが上がりました。

（課題の事例）

  • 既存機能を修正した際、周辺機能のデグレを考慮しきれていない。

  • 顧客指摘の不具合が他チケットに埋もれてわかりにくい。

  • 顧客影響の大きさが定量的に判断しづらい。

  • 本番DBのデータに不整合がある場合がある。

  • テストを一つのファイルに書きすぎて見にくい。

  • {とある内部機能}ではテストコードが書けていないものが多い気がする。

  • QAテストの負荷増加を感じている。今後のQAコスト負荷の懸念あり。

  • ユニットテスト、E2Eの自動テストでもっと早期にデグレ検知したい。

  • 既存バグ対応のリリースに混ざって、機能仕様や画面仕様に変更が生じているものがリリースされていることがある。
    ︙
    etc.

振り返り

振り返りMTGでは、miroを使ってグルーピングを行い課題を整理しました。小さくて見えないと思いますが、イメージを貼っておきます。

纏められた課題から、「品質の早期作り込みは重要だよね」「問題が生まれないように、早めに潰していくことが必要だよね」という共通認識がとれました。

そして、そのために必要なことをブラッシュアップし、それぞれの課題に対する具体的な改善計画を立てました。決まった改善計画は以下のとおりです。
※文字が少し小さくてすみません。

上述のうち、「PRDを中心に据えた仕様の可視化」において、QAチームとして２つのネクストアクションに取り組むことにしました。そしてこれを「QAシフトレフト」の活動と呼ぶことにしました。現在も進行中です。

QAシフトレフト

  1. PRDの作成補助

  2. QAテスト観点の早期導出＆開発担当者への早期提供

※QAシフトレフト以外の取り組みとして、開発チームが行うことになった「ユニットテストの強化」「1ファイルあたりのコード量を制限する」はとても良い取り組みだと思っています。

QAチームの取り組み

PRDの作成補助

この取り組みを行う以前は、PdMが作成したPRD(※)を開発チームが受け取り、そのまま開発を進めていました。普通の流れのお話です。
※Product Requirements Document（プロダクト要求仕様書）

しかし、前述の背景説明のとおり、リリース前のQAテストでの不具合検知の増加や、条件別での機能不備などが増え始めていました。

そこで、PdMから開発チームへ受け渡すPRDの質を上げて、これらの発生を未然に防ぐために、開発着手前にPRDのレビュープロセスを設けることにしました。そして、このレビュープロセスにQAチームも加わることにしました。

レビュープロセスにおける各自の主な役割は以下です。

PdMの役割

  • 情報が十分かを改めて確認する（提供すべき情報に漏れがないか？など）

  • 各所からの質問に回答する（認識齟齬の埋め合わせに努める）

開発チームの役割

  • PRDを理解する（背景・要求・要件など）

  • 不明点があれば質問する（開発者の視点で）

  • 仕様を可視化する（特に外部仕様は可能な限り対応）

QAチームの役割

  • PRDを理解する（背景・要求・要件など）

  • 仕様を把握する（実装仕様をイメージする、理解する、深掘りする）

  • 不明点があれば質問する（プロダクト利用者の視点で）

PRDのレビュープロセスは、開発規模の大小にもよりますが、基本的にはMTG形式で行います。これを行うことで、開発着手前からの早期品質の作り込み、認識合わせの強化、開発時の抜け漏れ防止に努めています。

QAテスト観点の早期導出＆開発担当者への早期提供

これは、PRDレビューのタイミングで、QAチームが持っている過去テストノウハウから、大枠のテスト観点を導出して開発チームに提供する活動です。ざっくりイメージは「こんなことをQAテストする」「こういった条件やこういった動作も見るので開発時に考慮すべき」といったことがわかる情報を、開発前または開発中のタイミングで提供します。これにより、開発時の抜け漏れを未然に防止できるようにするというものです。

その他の取り組み

上述以外にも、E2Eの自動テストの取り組みとして「Playwrightを活用したE2EテストのCI化（E2Eテストの自動化）」も進めています。

こちらもご紹介したいのですが、以前にご紹介させていただいた「Datadogを活用したテスト自動化の取り組み」とは別に、新たに始めたテスト自動化のお話のため、ここで書くと長くなるため今回は割愛します。また次回以降で紹介していきたいと思います。

皆様に知っていただきたいこと

今回は「QAシフトレフト」に焦点を当てて紹介していますが、「皆で協力して品質改善活動を進めていること」これに尽きます。

例えば、品質改善活動をQAチームだけが独自に行っていたとしても、それは本質的ではないと思っています。リリース前のテストで多くの不具合や抜け漏れを見つけ、問題を未然に防げたとしても、それは根本的な解決ではなく、「QA→開発へ」という多くの手戻り工数が発生し、リリースの遅延やQAチームの負荷増加につながり、開発組織の体制としても良い状態とは言えません。一般的によく見るような問題と思われる組織体制に直面してしまいます。（主観込みですみません。分かる人には分かってもらえそうな気がしています。）

そしてこの問題に直面することを防ぐためにも、課題を感じたタイミングで、早めにこの改善の取り組みを始めました。

最後に

このようにして当社では、各チームが協力し合い、皆で上述の活動を進めています。各自がプロダクトの品質向上に努めています。これは、カラクリ社プロダクト開発の良い文化だと思っています。

カラクリQAチームでは、こんな感じで今後も引き続き、品質保証・品質管理を行い、開発を沢山支援していきたいと思います。


以上

この記事が気に入ったらサポートをしてみませんか？