QAメンバーがQA以外の活動をやってみた
はじめに
GLOBISでQAエンジニアをしている小波津です。
2024年3月にGLOBISにQAエンジニアとして入社しましたが、現在は通常のQA業務であるテスト計画やテスト実行だけでなく、要件定義の段階からプロジェクトに携わらせていただいています。
近年、「シフトレフト」という考え方が注目されています。これまでは、開発設計の段階からQAが関与することはありましたが、要件定義の段階から関わるのは私にとって新しい挑戦です。このような経験を通じて得た知見や学びを共有したいと思い、今回初めてQiitaで記事を書くことにしました。
QA以外の活動に関わるきっかけ
現在私が所属しているチームでは、要件定義フェーズと開発フェーズのそれぞれでスクラムを回しています。私は現在、主に要件定義フェーズに関わるスクラムチームで活動しています。
実は、POから「要件定義段階でもQAやデザイナーの視点を積極的に取り入れることで、効率的かつ効果的なプロダクト開発が実現できるのではないか」という提案があり、要件定義フェーズ専用のスクラムチームが立ち上げられることになりました。現在、このチームはPO、QA（2名）、デザイナーの計4名で構成されています。
さらに、この取り組みが可能になった背景には、開発フェーズにおいて開発メンバーがテスト工程を主体的に担える体制が整っていることも大きな要因です。これにより、QAメンバーは「開発フェーズでのテスト」以外での活動にも注力できるようになっています。
具体的な活動内容
要件定義での活動
- ステークホルダーとのコミュニケーション
- 社内のステークホルダーとの定例会を通じて、要望の確認やヒアリング、仕様の提案・共有を行い、合意形成を図ります。
- 要求定義〜要件定義の検討・決定
- ユーザーの要求をヒアリングし、それを具体的な要件として定義します。
- 情報設計・画面設計
- デザイナーと協力して画面の構造や情報の配置を設計し、ユーザー体験を向上させるための提案を行います。QA視点から、使いやすさや矛盾のない設計、必要なパターンなどを検討しています。
- ユーザーストーリー作成
- ユーザーストーリーの作成では、要件の背景や意図と具体的な受け入れ条件を明記し、開発チームが仕様を誤解なく実装できるようサポートします。
- 開発チームとの連携
- 開発チームとの密な連携により、要件定義段階から技術的な課題や懸念を検討・共有してもらい、仕様に反映させています。
スクラムチームとしての活動
- スクラムイベントのファシリテーション（例：デイリー、スプリントプランニングやレトロスペクティヴ）
- デイリースクラムやスプリントプランニング、レトロスペクティブなどのイベントをファシリテートし、議論が円滑に進むようサポートしています。特に、レトロスペクティブでは改善点を引き出し、次のスプリントに向けた具体的なアクションを設定しています。
- スクラム運用の改善
- チームメンバーの声をもとに、スクラムプロセスの効率化や課題解決に取り組んでいます。例えば、負担軽減のため、各スクラムイベントのファシリテーションをローテーションできるようにしたり、ファシリテーションに慣れていない人のサポートなどを行なっています。
活動を通じて得られた成果と課題
成果
要件定義フェーズにQAメンバーが関与するようになったことで、以下のような成果が得られました：
-
要件定義フェーズのスピードアップ
以前はPO一人で進めていた要件定義にQAメンバーやデザイナーが加わったことで、複数のプロジェクトを同時並行で進められる体制が整いました。 -
テスト設計の効率向上
QAが初期段階から仕様検討に関わることで、リリース前の受け入れテストのテスト設計の際、仕様確認や対象分析にかかる時間を大幅に削減できました。これにより、より精緻なテスト計画・設計を短期間で立案できるようになりました。 -
POの負担軽減
スクラムイベントのファシリテーションやユーザーストーリー作成、開発メンバーとの連携といった業務をチームメンバーで分担したことで、POの業務負担が軽減され、POが本来注力すべき戦略的なタスクに時間を割けるようになりました。
課題
一方で、新しい領域に挑戦する中で、次のような課題にも直面しました：
-
要件定義を進める難しさ
ステークホルダーからの要求を正確に引き出し、要件を検討・仕様に落とし込むプロセスは、未経験の多い領域でした。特に、単に「仕様を評価する」のではなく、「仕様をゼロから検討する」という意識転換には時間がかかりました。 -
経験不足からの学び
初期の段階では、POのサポートを受けながら進めることが多く、進め方・考え方を学ぶ日々でした。背景まで説明し、チーム全体で認識を共有することの難しさに直面しました。 -
成長への模索
この課題を克服するために、POが要件定義における注意点や進め方を言語化してくれています。それを元に、どんどん新しいプロジェクトを担当していくなど、積極的に要件定義のフェーズの経験を積んでいます。
QAがQA以外の役割を担う意義
現時点では、「QAとして要件定義に関わる価値」を明確に定義する段階には至っていません。要件定義フェーズにおける業務に慣れ、さまざまな要素を考慮しながら仕様を確定し、それをスムーズに開発メンバーへ引き渡すことが、現在の大きな課題となっています。この課題を乗り越えるために、日々試行錯誤を重ねています。
一方で、これまでの経験とは異なる領域に挑戦する中で、今まで気づかなかった視点やプロセスが見えるようになったことは、私にとって非常に大きな意義を持っています。例えば、以下のような気づきがあります：
-
QA視点と要件定義視点の相互作用
QAが要件定義に関与することで、曖昧な仕様の明確化やテスト容易性を意識した仕様設計が可能になり、逆に要件定義で得た視点を開発フェーズやテスト設計に活かすことで、より全体最適なプロセスを実現できます。 -
スキルアップとキャリアの広がり
要件定義への関与を通じて、QAとしてのスキルが開発プロセス全般に拡張され、新しいキャリアパスが開ける感覚を得ています。この経験は、単なる「テスト担当」から脱却し、プロジェクト全体を俯瞰して改善に貢献できるエンジニアとしての成長に繋がっています。
また、スクラムマスター（とまではいかないかもしれないが）もできるQAメンバー！というのも新たなキャリアに繋がるのではないかと思います。
要件定義における役割を深めることは、私個人の成長だけでなく、チームやプロジェクトに対する新しい価値の創出にも寄与すると考えています。今後もこの挑戦を続けながら、QAとしての意義をさらに明確化していきたいと思います。
まとめ
2024年3月に入社してから1年も経たないうちに、新しいことに挑戦できる環境に恵まれ、日々刺激を受けながら取り組んでいます。もちろん大変なことも多いですが、その分「できた！」と実感したときの達成感は非常に大きく、転職活動時に自己分析した「できることが増えると楽しい」という自分の特性を再確認しています。
特に要件定義フェーズでの業務は、取り組み始めて数ヶ月が経ち、少しずつ理解が深まってきました。自分自身の成長を実感できる一方で、まだまだ学ぶべきことも多く、今後も経験を積みながらスキルを磨いていきたいと考えています。
また、「QAメンバーが要件定義に関わる意義」をもっと明確にできた際には、その気づきや成果を改めて共有できればと思っています。
最後に、挑戦をサポートしてくださるチームの存在には心から感謝しています。受け入れ態勢が整い、温かく迎え入れてくれたチームがあるからこそ、積極的に新しいことに挑戦できていると実感しています。
最後までお読みいただきありがとうございました！