アジャイル型QAの心構え

この記事は、CYBOZU SUMMER BLOG FES '24 (QA Engineer Stage) DAY 1の記事です。

こんにちは！kintoneでQAを担当しているMiyakeです。

みなさん、近年「アジャイル開発している会社やチームが増えてきたなー」と感じることが多くないでしょうか。

サイボウズでも、アジャイル開発（特にスクラムのことを指しています）をしているチームが多く存在します。

私はこれまでに、ウォーターフォール開発とアジャイル開発のQAをどちらも経験した結果、アジャイル開発のQAの方が好きだと感じています。

しかし、初めてアジャイル開発の中でQA活動を行ったときは、どういう心構えで行動すれば良いかわからず戸惑った記憶があります。

そこで本記事では、これからアジャイル開発のQAを始める方向けに、アジャイル型QAになるための心構えを書いていきたいと思います。

※ほぼ私の経験ベースになりますので、こういう考え方や開発現場もあるんだな程度に捉えていただけると嬉しいです。

自己紹介

私が何者なのか、経歴を簡単に紹介します。

まずは、私が経験したウォーターフォール開発とアジャイル開発について記載していきます。

開発フロー
- 開発ステップを一度の開発期間中に終わらせるもの
  - 要件定義 -> 設計 -> 実装 -> テスト -> リリース（完）
良いと感じた点
- 先に綿密な計画を行うのでプロジェクトの全体像が先にわかる
悪いと感じた点
- 一度ステップが完了するとミスに気づいたときにリカバリーしづらい
- ユーザーに価値が届くタイミングが遅くなりがち
- チームが肥大化し複数の協力会社が入り乱れるカオス空間になりがち（リソース足りない→外部に発注の流れが起きやすい）

開発フロー
- 開発ステップを一定の期間で区切り、これを何度も繰り返すもの
  - sprint1 要件定義 -> 設計 -> 実装 -> テスト -> リリース -> 振り返り＆次の計画
  - sprint2 要件定義 -> 設計 -> ...
良いと感じた点
- ユーザーのニーズの変化などに対応しやすい
- ユーザーに価値が届くタイミングが早い
- 少人数のチームに分かれて活動するので連携等を密に行うことが可能
悪いと感じた点
- リリース頻度が高くデグレが発生しやすい

上記をまとめると以下のイメージ図が出来上がりました。

次に、私が経験した2つの開発の中で特にQAにフォーカスして記載していこうと思います。

良いと感じた点
- 工数管理や顧客折衷専属のQAがいるので進捗管理がしやすい
- ドキュメントベースでテスト設計ができる
- チームが開発から独立している傾向にあり第三者的な目線でテストができる
悪いと感じた点
- 途中でメンバーが変わりすぎて人間関係の構築が大変
- エビデンスの取得に神経使いがち
- 他社のQAと仲良くできない謎の雰囲気
- 人が多すぎて仕事が無く虚無な時期がありがち
- 初期品質悪いことが多く工数膨れがち（最後の壁扱い）

良いと感じた点
- マイクロマネジメントの必要がない
- 見積もりとの乖離が比較的小さく抑えられる
- 密に連携可能なので関係良好なチームが比較的出来やすい
- 優先度を調整しつつ柔軟に仕事することが可能
- 各職能の認識合わせが出来ているので初期品質が良い
悪いと感じた点
- デグレが発生しやすいためリグレッションテストや自動テスト等の継続的なテストをする必要がある　※特に自動テストはハードルが高い
- 仕様の抽象度が高いのでQA側でテスト設計時に仕様を補完する必要がある