新卒QAが感じたスプリントプランニングのありがたさ - Cybozu Inside Out

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

こんにちは！24年に新卒で入社したQAの水谷です！

今回は、新卒でQAを始めた新人が感じた、スクラム開発におけるスプリントプランニングにQAが参加することのありがたさを

QAにとって
チームにとって
スプリントプランニングによってQAが製品の品質にできる貢献

の3つの観点からお伝えできればなと思います。

そもそもスプリントプランニングってなに？

ざっくりといえば、スプリントプランニングとは実際に製品を作る開発者が集まって製品をどうやって作るのか打ち合わせをすることです。

少し掘り下げて説明すると、スプリントプランニングはスクラム開発の用語で、実際に製品を作り始める前に行う会議のことを指します。
そのため、スクラム開発に馴染みがない場合はイメージが湧きにくいかもしれません。

そこで、まず初めにこの記事におけるスプリントプランニングの定義を簡単に説明します。

一般的に、スクラムを採用したアジャイル開発では、スプリント(一回の開発の周期)を使って動くものを作ります。動くものを作るためには仕様やテスト、デザインなどが必要です。

それらについてPO(プロダクトオーナー)や実際に製品を作るメンバーなどが相談しながら、製品の仕様やテスト、デザインなどを詰めていく作業がスプリントプランニングです。

具体的には、「ここの仕様はこうだよね？」「テストはこういうところを確認したいです」「文言、デザインの意図はこうです」などのやり取りがなされ、
みんなで話し合いながら製品の理解を詰めて、仕様や製品の情報を共有します。1)

自分の所属しているチームではスプリントプランニングで各バックログの認識合わせを行う際に、QAからテストの内容について質問して認識合わせしたり、事前に設計済みテストの内容を共有して、他職種の方にレビューしてもらっています。
スプリントプランニングでQAの側から試験の認識合わせの話をすることは、一般的にはあまり多くないかと思います。

そこでQAがスプリントプランニングに積極的に参加する開発を経験した新卒QAとして、
QAがスプリントプランニングに参加できることが、QAにとって、チームにとって、製品の品質にとってどういうメリットがあるかをお話しできればと思います。

それでは、ここから実際に、新卒QAが感じたスプリントプランニングのメリットについて話を進めていきたいと思います。
スクラム開発を採用していない方には、スプリントプランニングを開発前の情報共有ミーティングと読み替えながら読んでいただけるとわかりやすいかと思います。

QAにとってのスプリントプランニングの価値

QAの仕事が難しい時って？

QAが仕事をしにくくなるのは、仕様の理解が浅く、他の開発メンバーと仕様理解が共有できない状態でテストをする時だと思います。

そういう状態では以下のような懸念点があります。

製品や仕様の理解が不十分な状態では受け入れ条件を網羅していないテストを設計してしまう可能性がある
QAだけで作ったテストでは、観点が偏っていてテストの品質が高めきれない可能性がある
仕様なのか判断しにくい実装で、正確な期待結果がわからない

これらの懸念点が、QAのテスト活動において問題となるのは想像に難くありません。
特に、正確な期待結果がわからない場合はテスト自体が正しく行えず、バグだったものを仕様と思ってテストをパスさせたり、仕様をバグとして報告したりするリスクがあります。

QAの目指すところは品質を保証することで、その一環としてテスト活動があります。
しかし、上述したような懸念点があるままでは、品質を保証するに足るテストができない場合があります。
卑近なことを言えば、バグを見逃してリリースしてしまうリスクが上がってしまうことにもつながりかねません。

スプリントプランニングによる解決

上述したような課題は、スプリントプランニングによって(全てではないものの)解決することができます。

テスト設計前に仕様を把握しておくことで、テストの観点や受け入れ条件のテストもれを防ぐことができる
他の職種の方にテスト内容のレビューをもらうことで、違う専門性の観点をテストに反映でき、テストの質を高めやすくなる
実装や仕様の懸念点を事前に共有することで、正常な挙動なのかバグなのかの判断をQAだけでつけられる場面が増える

もちろん、すべての課題が解決するわけではありません。ですが、情報共有をしないでテストをするよりもずっと建設的な開発プロセスになります。

チームにとってのスプリントプランニングの価値

スプリントプランニングがない場合の課題

チーム開発で課題となりやすいのは情報共有が少ないために起こる時間/工数のロスです。

もう少し掘り下げると、情報共有がうまくいっていない時のチーム開発では以下のようなことが起きやすいと思います。

手戻りが起こりやすい
質問の回答待ちの時間が生じやすく仕事が止まりやすい

チームメンバー同士での情報共有がないと、仕様に対する認識が各人でずれてしまい、
作ったものが仕様とずれていて手戻りが生じやすくなります。
手戻りの時間ロスや辟易とした感覚はみなさん感じたことがあるのではないかと思います。

また、仕様や製品に関する質問が実装途中で飛ぶ回数が多くなり、仕事に思ったより時間がかかることもあります。
質問をする側が質問の回答待ちで仕事が止まるだけでなく、質問に答える側も、いちいち飛んでくる質問に対応する必要があります。
同じような質問が別の人からも飛んできて、二度手間になることもあります。
大小様々なものでメンバー同士の情報共有のための時間/工数が発生し、見積もっていたよりも実装にコストがかかる場面が出てきます。

このように、情報共有がうまくいっていない場合、手戻り、質問対応など大小様々なタスクが割り込みで入ってきたり、回答待ちで作業が進まなかったりする場合があります。