こんにちは。決済プロダクトでQA兼スクラムマスターをしているbarusです。
本日はfreee QA Advent Calendar2023 7日目です。
今回は「スクラムマスターを兼任して見えてきた、シフトレフトのための立ち回りとやってきたQAの活動」と題してお話させていただきます。
freeeカードUnlimitedの立ち上げ期から現在に至るまで、各チームを転々としながら、いずれもスクラムチームの一員としてアジャイルQAを行ってきました。
今年の9月からスクラムマスターを兼任しながら、日々品質とスピードの両立に取り組んでいます。
本記事ではスクラムマスターを兼任して見えてきた視点を交えながら、より早期にシフトレフトをしていくためにQAがどのように立ち回るべきか、そして実際に自分たちのチームがやってきたことをお話しようと思います。
ここではQAプロセスの最適化としてではなく、プロジェクトに対してQAが上手くシフトレフトしていくためにどうコミットするかに焦点を当てていきます。
背景
前提のすり合わせとして、なぜ品質とスピードの両立を追求しているのか、私たちのプロダクトやチームのバックグラウンドを簡単に共有しようと思います。
私たちのQA像
企業に対して一人目QAではなく、プロダクトチームに専任で一人目、二人目QAがいる状況
本文で扱う内容はいわゆるソフトウェア業界における通例でのQAの立ち位置*1での話あり、いわゆる品質ゲートと表現されるような監査的立ち位置にある品証部門を想定していない
よって、テスト計画〜実行までのテストプロセスを行い、かつある程度プロジェクトやプロセス改善に対してハンドリングする権限のあるプレイヤー層の話を扱います。
もちろん、社内一人目QAであれ、品証部門であれ、マネジメント層であれ、何かしら共感いただける部分があれば幸いです！
プロダクト開発の背景
- 本文で扱う内容は全社的に行なっているアプローチというわけではないこと
スクラムチームとしてQAが一員であるケースは全社的な取り組みというわけではなく、プロダクトチームとしてまさに試している状況です。
(もっと言えば、QA兼スクラムマスターが社内で他にいないので.....)
数年後に結論が変わる場合もあると思いますので、freee内における絶対論ではないことをここに明記しておきます。
- プロダクトの市場として非常に競争の激しく、プロダクトを取り巻く環境の変化も速いという共通認識のもと、アジャイルQAを採用していること
なぜ品質とスピードを両立しようとしているかについての理由になります。
プロダクトの性質上、凌ぎを削る競合他社が存在することもさることながら、法制度の追加・改正やそれによるユーザーの利用ニーズも頻繁に変容します。
こうした背景を踏まえて、freeeカードUnlimitedチームの立ち上げ期よりアジャイルQAを実践してきました。
より詳しい話はymty(yumotsuyo)さんの記事にて触れられていますので、こちらも要チェックです👀
- チームで回しているスクラムにおける解釈はRed Journeyさんによるコーチをベースにしていること
私が所属するチームではスクラムガイドを読む会を設けてチームメンバーと意識合わせしています。
意識合わせした内容を踏まえて各イベントの定義や運用方法をまとめたdocを作成しており、現在はそれを元にスクラムを運用しています。
また、スクラムガイドの読み合わせや週1で行っているスクラムマスター相談会で、アジャイルコーチとしてyoh(中村 洋)さんをはじめとするRed Journey inc.の方々に入っていただいています。
docの内容を含めスクラムイベントで行っているプラクティスの多くは、アジャイルコーチの方々との議論で得た解釈がベースとなっています。
アジャイルコーチとして入っていただいてから現在に至るまでのスクラムとQAの関わり方については、「freeeここだけの話」にて語られているので、こちらもぜひチェックしてください！
www.youtube.com
QAがテスト以外のアプローチでシフトレフトに目を向ける必要性
ここでは、背景で扱ってきたような状況下において、どのようなシフトレフトを阻む問題が発生したのか、なぜテスト以外のシフトレフトにも目を向けようと考えるようになったかについて触れていきます。
私のチームで実際に発生した問題
実際に私が所属してきたチームではプロダクトの初期フェーズやメンバーの追加・異動を起因として度々共通して、以下のような現象が発生していました。
どうしても間に合わせたいリリース日が存在しており、それに対して開発Done*2自体がギリギリ
クリティカルな要求考慮漏れが後から判明し、開発対象が増えた
機能に対して多重並行で開発することによる認知負荷の増加
チームメンバー各人の作業の余裕が無くなることで、情報を追えなくなっていき、仕様の変更や開発Done予定日などの認識ズレが顕在化
テスト分析~設計をシフトレフトしても、テスト実行可能な単位での開発Doneがリリース日直前に集中してしまう
開発の手戻りによって、シフトレフトした分のテスト分析〜実施のやり直し、自動テストの修正を行うことになる
なぜこのような問題が起きるのか
例えば、仮説検証を発端とする問題(上記の図でいう価値探索→MVP特定)は、想定ユーザーのクリティカルなニーズの把握の遅れや、ユーザーストーリーレベルの確認不足による要求定義漏れが原因に挙げられます。
これはQAや他のロールがユーザーインタビューを行っている場合であっても、防ぐのが難しい場合があります。
なぜなら、ユーザーインタビューでの早期のニーズ捕捉は、ユーザーの気づきに依存しているため、後からユーザーが利用し始めて、そこで気づく視点もあるからです。
また、ユーザーの運用方法はユーザーの所属する組織内のルールや業種、それらを取り巻く法制度などにも左右されるため様々です。必ずしも共通項が見つかるわけではないので、すべてのユーザーの利用シーンを想像するのは困難です。
特にプロダクト立ち上げ初期だと、フィードバックをいただけるユーザーの獲得が難しく、ニーズ把握の難易度にさらに拍車をかけます。
実際、私たちのチームではプロダクト利用の合意を取れたユーザーのクリティカルなニーズをリリース2ヶ月前に発見しました。既に他の開発対象物も積んでしまっている中でしたが、間に合わせに行く決断をしました。
上記を起因として次に表出するのが開発体制の問題です。
例えば、これまで問題なく行えていた多重並行による開発を、より早いスパンで行わざるを得なくなりました。
多重並行による開発は、属人性の高まりや開発・QA双方の認知負荷増加を引き起こします。これにより開発効率はもちろん、質問のしやすさにも影響してテスト分析~設計のスピードが落ちるといった現象につながります。
また、追加の開発対象物をリリース日に間に合わせる判断をした結果、最低限の機能要件の実現のみをゴールとして開発することになりました。
後に非機能要件のバグとして発見され、この方針が手戻りをもたらす結果となりました。
さらに、余裕がなくなることでメンバーの情報を追う能力が奪われ、実装範囲やスケジュール感に対して認識ズレが生じ始めることで、よりミスを生みやすい環境になっていきます。
なぜテストプロセス以外にも目を向ける必要があるか
もちろん、テストを上手くなることによってリリースまでにかかる時間を短縮しようという動きは必要だと思います。
しかしながら、テストプロセスの最適化によるQA期間の圧縮は、いずれ限界を迎えます。
また、テストプロセス外の問題が起因でテストプロセスが上手くいかない場合、肝心の問題の発生源に対して対策を打てなければ、後で同じ状況が発生して苦しみ続けることになります。
QAであってもプロジェクトを取り巻く様々な領域に目を向けるべき
よって、開発プロセス全体でシフトレフトしていくためには、QAであっても開発や仮説検証段階の問題に対してアプローチしていく必要があります。
スクラムチームは、ゴールを達成し、お互いにサポートすることを確約する。
スクラムチームは、ゴールに向けて可能な限り進捗できるように、スプリントの作業に集中する。
スクラムチームとステークホルダーは、作業や課題を公開する。
スクラムチームのメンバーは、お互いに能⼒のある独⽴した個⼈として尊敬し、⼀緒に働く⼈たちからも同じように尊敬される。
スクラムチームのメンバーは、正しいことをする勇気や困難な問題に取り組む勇気を持つ。
スクラムガイドのスクラムの価値基準から引用すると、スクラムにおける正しい姿は「各人やチームの抱える問題に対し、チーム一丸で解決すべき」であると解釈できます。
スクラムチームは機能横断型で、各スプリントで価値を⽣み出すために必要なすべてのスキルを備えている。
また、スクラムチームの構成要件である機能横断型は、チーム自体が機能横断的であるだけでなく、各メンバーが複数の役割を果たせるという考え方を内包すると解釈できます。
スクラムにおいて、QAというロールに閉じた範囲で努力をするのではなく、開発や仮説検証段階のやり方にも精通できるよう目指すべきなのだと私は考えています。
(そうでなくとも、最終的に影響を受けるのはQA自身なので...)
まとめると、QAのプロセスに閉じた動きだけでは足りないので、スクラム論、開発・仮説検証プロセス、内部品質を含めたリーン思考*3などなど、「チーム一丸で問題に立ち向かうためにも、プロジェクトを取り巻く様々な領域に目を向けようぜ」という話ですね。
シフトレフトのためにQAでもやるべき立ち回りとやってきたこと
ここからは、チーム全体のプロセスをシフトレフトしていくために、私たちのチームでやっていることをいくつか挙げていきます。
それらを実践するにあたり、スクラムマスターの視点から気づいた、QAがやるべき立ち回りも紹介していきます。
大前提：ステークホルダーとカジュアルにコミュニケーションを取れる関係性を目指すこと
スクラムである以前にアジャイルソフトウェア開発宣言で「プロセスやツールよりも個人と対話を」と言われている通りです。
コミュニケーションの取りづらい関係性(特に対立関係)にあると、そもそもプロセス・ツール導入の時点で揉めるので...。
いかにチームと良好な関係性を築くかについて、アジャイルコーチからも重要性を説かれたことがあります。それは「雑談」です。
プロダクトやプロジェクト、さらにはチームや自身の特徴に関する雑談が、仕事上の相談や質問のハードルに効いてきます。
また、アイデア創出の確率を上げることによって問題解決の糸口を発見したり、個人間の認識やそのベースである価値観のすり合わせを頻繁に行うことによって認識齟齬が低減します。さらには認識合わせのためにしなければならなかった定量化すべき事象の減量につながります。
私個人がスクラムマスターになって意識したことで言うと、最近開発、UXデザイナー、PdMと1on1を組んで、あえて雑談のために時間を作り、そこで出た良いアイデアをあえ共*4するようになりました。
特にPdMとはカジュアルに仕様やチームの動き方について相互に壁打ちをしています。(同じチームのQAからPdMに移った方なのでやりやすいのはある)
特にQAはテストプロセスに関する相談をengやPdM、UXデザイナーなど他のロールとよく行うことになります。結果的に仕事のしやすさやテストプロセスの成果物の質、成果物作成のスピードにも影響することになります。 過去freeeカードUnlimitedチームでQAがengと相談しやすい関係にあったことで実現できた例として、DebugAPIを実装して、カード有効化した後のテストデータ作成にかかる時間を24時間→3分まで短縮できたことが挙げられます。
www.slideshare.net
ただし、雑談のために作業時間を削ってまで作れと言っているわけではなく、ペアオペ中の処理待ちタイミングやスクラムイベントで人が集まるまでの数分の何気ない隙間時間にこそ価値がある、という認識です。
私の所属するチームで実践している例としては、slackのハドルでカジュアルにペアオペを始めて雑談したり、隔週のスクラムイベントに合わせて出社して昼食に行ったり、KPTのkeepの半分以上がメンバーへの感謝を書く欄と化していたり...。
何はともあれ、QAの世界に閉じこもって解決策を模索するのではなく、「シフトレフトを目指すならコミュニケーションから始めよ」がプロジェクトを取り巻く様々な領域にも目を向けることのできるQAを生み出す源泉だと思っています。
SPゴールからユーザーの価値を意識しよう
スプリントゴールはスプリントの唯⼀の⽬的である。
スプリントゴールは開発者が確約するものだが、スプリントゴールを達成するために必要となる作業に対しては柔軟性をもたらす。
スプリントゴールはまた、⼀貫性と集中を⽣み出し、スクラムチームに⼀致団結した作業を促すものでもある。
スクラムが適切に運用されていれば、SP(スプリント)ゴールを設定しているのではないかと思います。
私たちのチームでは、「ユーザーはXX機能にてXXを選択してXXすることによって、XXすることができる」といったように、ユーザーストーリーをベースにSPゴールを設定するよう心がけています。
狙いはスプリント中にユーザーがどこまで操作できるようにするか明文化することで、機能開発で完了としてしまわずに、ユーザーの目的を達成できるかまで認識することです。
さらに、私たちのチームではユーザーストーリーチケットをベースにした受入基準駆動で開発を行っています。
これによって、SPゴール=目指すべき姿→ストーリーチケット=目指すべき姿やそのバリエーションのストーリー→タスクチケット=目指すべき姿にするために実装が必要なタスク、という構成になります。
この構成によりユーザーの目的を達成するために必要なタスクを認識しやすくなりました。 QAとしても、どのストーリーにどの実装が入るかが分かりやすくなったことで、何ができて何が出来るとまずいかを認識しやすくなり、受入基準の作成やテスト設計すべき範囲の把握がしやすくなりました。
Ready、Doneを明確に定義しよう
情報を追ったり、認識合わせの余裕がなくなってきた際に考慮が漏れるとマズいことの一つとして、ReadyやDoneの定義の認識ズレが挙げられます。
ReadyやDoneの定義とは、リリースや開発、QAの開始・終了に対する合意のことです。
例えば、開発DoneとQAReady(テスト実施可能単位になるのがいつか)の関係性が揺れてしまっている場合、開発Done予定日がいつの間にかリリース日にすり替わっているなんてことも...。(実際ありました)
開発DoneやQAReadyを明確に定義しておくことは、リリース直前の認識齟齬による事故を防ぎます。
スクラムにおいては、確約に対して進捗を検査する上でコスト低めで高い効果を発揮するのでオススメです。
ちなみに私たちのチームではスクラムの運用docで以下のように定義していますので、ここでは定義の一部を紹介します。
「開発が終わった(=midoriデプロイ待ちの状態)」完成の定義
インテグレーション環境デプロイ待ちの状態＝開発Done
インテグレーション環境にデプロイされている=QAReady
開発Done=QAReadyではないことに注意すること(特にスケジュール作る時に要注意！)「PBIが終わった(=リリースできる)」完成の定義
QAの定めたテストが完了している=QADone
ステークホルダーの確認が終わっている
ユーザー公開する開発内容であれば告知が完了しているリリース日から考えてスプリントゴールを定義、それに対してgreen, yellow, redを判断
今SPのゴール
🟩ユーザーはXXからXXを参照できる
リリース日：X/X(開発done：X日まで、QAdone:X日)
並行度を検査しよう
いわゆるフロー効率とリソース効率の話に関連します。
フロー効率性とリソース効率性について #xpjug | PPT
リソース効率の追求=必要な機能に対してengを一人で割り当てて並行開発を進める、フロー効率の追求=機能に対してチームで人員を集中して進める、と解釈した場合にどのようにバランスを取るかについてです。
スクラム的にはできるだけ一つの機能に集中するのが望ましいのですが、私が所属するチームでは、人数や実装の関係上、一つの機能に対して全員を割り当てるのはどうしても過剰になりがちです。
そのため、現在は並行で別機能を開発する際に2機能を目安に管理しています。
理由は発生した問題でも取り上げた、多重並行で開発することによる認知負荷の増加にアプローチするためです。
さらに、並行度と進捗の検査を兼ねて、進捗が詰まっていないかを確認する手法として、チケットの滞留日数に着目するようになりました。
具体的には、より優先度の高いチケットがストーリーポイントで設定した値に対して滞留している場合に、ペアオペなどで常時相談できる体制にする=フロー効率の強化によって解決しにいきます。
これにより、仕様把握や実装難易度等で認知負荷が高まりつつある状態を緩和したり、engとQA・PdMのやりとりの負担軽減、スクラム的に言えば、より集中しやすい状態にします。
QAとしては一度の仕様把握量を減らしたり、テスト実行可能になる機能をできるだけシフトレフトしたり分散させるといった効果につながり、開発Doneの集中を抑えられています。
QAであっても内部品質(設計方針)に対するリーンを考えよう
リリースに間に合わせようとして機能要件の範囲のみを考えた実装は、結局次のリリース以降にリファクタリングによる手戻り、最悪メテオフォール*5をもたらすことすらあります。
これはQAとしても既存の自動テストを使えなくなったり、全体的なリグレッションを必要とするので、結果的にコストが高くつきます。
テスト自動化とメテオフォール #TypeScript - Qiita
そのため、ビジネス上の仮説検証を早めに行いたい側面を理解しつつ、損益分岐点を考えてリーンに基づく意思決定していく必要があります。(これがまた難しい)
この判断をengに任せっきりにさせず、QAの視点からどのようにアプローチすべきかについては絶賛試行錯誤中です。その一つは意思決定できるよう材料(視点)を提供することだと考えています。
具体的には、運用・保守面で必要なDBのカラムが存在しているか、性能・信頼性の観点で本番環境と同等の利用数が想定されているかどうかをバックエンドの受入基準として作成したり、早期にバックエンドのテストを行っています。(私たちはこのような活動をバックエンドQAと呼んでいます)
これが上手く機能していくと、仮説検証や設計に対してフィードバックできる質・量ともに増え、手戻りへの対策や適切なリーンによる意思決定を促進できるようになるのではないかと思っています。
詳しくは11日目のrenさんが「決済プロダクトのマジ価値を最速で届けるためのバックエンドQAの事例」にて紹介します！お楽しみに👀
それらを実践しての現状と課題
これら取り組みを実践していった結果、開発の着手とQAの着手のタイミングにおいて、開発Done後すぐのテスト実行、もしくはほぼ並行でテスト実行することに成功しました。
下記記事でいうQAの関わり方その3、その4を達成するまでになりました。
Agile開発に入り込むQAの方法 #D3QA / Agile QA Night - Speaker Deck
直近2~3回のリリースにおいては、すべての機能の開発Doneからリグレッションを含めたQADoneはで平均2~3営業日で達成できています。
一方、根本原因であるユーザーのクリティカルなニーズの捕捉が遅れてしまう問題に対して、まだアプローチできていない点は課題感として持っています。
この点はUXデザイナーやPdMと相談しながら、PRDやモックを利用して、より早期の段階でユーザーにイメージしていただけるよう絶賛模索中です。
おわりに
実際のところはチームメンバーの方々が優秀かつ意識が高いから成り立っているような気がして感謝しかないです。
他にも書きたいアプローチが盛りだくさんですが、記事が長くなってしまったのでこのあたりにて...。
今回紹介したものはまだまだ発展途上です。より爆速でマジ価値を届けられるよう、そしてより早く精度の高いフィードバックを行える世界を目指して挑戦していきます！
最後まで読んでいただきありがとうございました！
明日はfreee会計QAのAkari Shimizuさんが「アジャイル開発にQAが入っていった話」について語ってくれます。お楽しみに！
それでは、よい品質を〜
*1:このQAのロールイメージは以下記事を参考にした筆者の認識です。 品質保証（QA）とは。定義の三大流派と定義揺れの弊害 - 千里霧中
*2:開発Done：スクラムガイドの完成(Done)の定義における、開発完了の定義の意味。
*3:リーン思考：ムダを最小限に抑えつつ、顧客価値を最大化すること。スクラムガイドでも「スクラムの理論」の章で触れられている。
*5:メテオフォール：仕様変更によって既存の仕様やテスト資産に大きな影響を与える変更の意味。@ta1m1kamさんの「テスト自動化とメテオフォール」より拝借
