チーム全体アプローチで、楽しみながら品質を高める：Quality Engineer体験談
はじめに
ソフトウェア開発に関わる全てのステークホルダーが「品質の高いプロダクトをできるだけ早く市場にリリースしたい！」と願っているのではないでしょうか？
この記事では、「アジャイルマインドセット」を持つチームが、プロダクトオーナー（クライアント）を含む「全員参加型アプローチ」で、楽しみながら高品質なプロダクトをデリバリーし、ステークホルダーから高い評価を得た実際のプロジェクトの成功事例を紹介します。また、Quality Engineerとしてプロジェクトに関わった私自身の経験から、Quality Engineerがどのようにしてこのプロセスに貢献できるかも説明します。
チームからの反応
まず、私が参加したプロジェクトの最後に行ったチーム全体での最終レトロスペクティブ（振り返り）の様子を紹介します。このボードには、開発チームだけでなく、プロダクトオーナーとして参画したクライアントチームメンバーも参加しています。
こちらのボードを見ていただければ、プロダクトオーナー（クライアント）を含むチーム全体が協力して、楽しみながらプロジェクトに取り組んでいた雰囲気が伝わるのではないかと思います。以下はチームからのフィードバックで、チームが協力して、品質に関連する活動のみならずプロジェクト全体の活動に取り組んだことを示しています。Quality Engineerが主導したBug Bashに対しても、チームからポジティブな反応がありました。
チームワークが素晴らしく、皆が協力し合い、建設的なフィードバックだけで争いはなかった。
コードレビューをチーム全体で行えた。
チーム内で素晴らしい協力があり、多くの作業を完了することができた
自分が困っているときや不具合があったときなど、皆が協力してくれて大抵は1日で解決できたと思う。
Bug bashとUATが素晴らしかった。
パフォーマンス、品質、UXにチームとして真剣に向き合うことができてよかった。
いつも受入条件を超えて追加の価値が生み出され、プロアクティブで自己管理されたスクラムチームだった。
Bug Bashなどの品質活動に対してもチームからポジティブな反応があるのが見られます！ウォーターフォール開発では、プロジェクトの最後のテストフェーズで多くのバグが見つかり、再テストやバグの修正でチームが疲弊することがよくあります。そのため、テストなどの品質活動に対してこのようなポジティブな反応が返ってくることは珍しいのではないでしょうか？読者の皆さまも、どんな役割でソフトウェアの開発プロジェクトに関わっていたとしても、このようにポジティブな形でプロジェクトを終えたいですよね。チームがどのようなアプローチを取ったことで、このような振り返りにつながったのか、紐解いていきましょう。
なぜポジティブな反応が得られたか
このプロジェクトを良い形で終えることができたのには、以下の要素が影響していると考えています。
良いスクラムチーム
様々な品質活動を支援するQuality Engineerが初期段階から参加
一つずつ解説していきます！
良いスクラムチーム
品質活動に限らず、いいプロダクト開発には良いスクラムチームが必要です。ここでいう「良いスクラムチーム」というのは、以下に記した大半または全てを理解・共感し、体現しているチームのことを指しています。
アジャイルソフトウェア開発宣言に記載されている価値
スクラム三本柱、スクラムの価値基準
チーム全体アプローチ
良いスクラムチームがあれば、検査と適応により正しい方向に向かっていく確率が高まります。今回、Quality EngineerがBug Bash、UAT、パフォーマンステストなどの品質活動をスムーズに実施できたのも、良いスクラムチームがあったからこそだと考えています。
チーム全体アプローチやアジャイルマインドセット（アジャイルやスクラムの価値観に共感し、実践しようとする姿勢）が浸透しているチームと、このアプローチに理解のあるプロダクトオーナーがすでに存在していたので、上記のような品質活動をスムーズに導入できました。このような文化がまだないチームでは、まず品質活動にチームとして取り組める土壌を作るところから始める必要があります。そして、この文化の醸成には時間がかかることが多いです。
Quality Engineerと Quality Engineering Core Principles (*1)
そして忘れてはならないのが、Quality Engineerの存在です。SlalomにはQuality Engineer というロールがあり、プロジェクト初期から開発チームに参加します。Quality Engineerは Quality Engineering Core Principles (以下： QE Core Principles) をもとに、チームとしてより品質の高いプロダクトを開発するのを支援します。QE Core Principles は、Slalomにおける品質へのアプローチを定義したもので、チームにアジャイルの概念を促進するための行動を促します。そして、これらを実行するにはチーム全体のコラボレーションが必要です。
Quality Engineerが正のフィードバックループを強化する
このようにQuality EngineerはチームがコラボレーションしながらQE Core Principlesに基づいた開発活動・品質活動を行うことを支援することで、チームがより良いスクラムチームになることを促進します。そしてチーム全体で品質活動に取り組むことで、より高い品質のプロダクトを開発できるようになります。今回の事例では、Quality EngineerがBug Bashのような取り組みをドライブすることで、チーム全体でテストに取り組み、品質に向き合う姿勢を強化しました。Quality Engineerは「スクラムチーム」と「品質」の正のフィードバックループをより強化し、チームとプロダクトにいい影響を与えることができます。
Bug Bash
今回のフェーズではQuality Engineer はスプリント内で実施する各プロダクトバックログアイテムに対するテストに加えて、Bug Bash, UAT, performance testなどを行いました。特にチーム全員で実施したBug BashはQuality Engineerがチーム全体アプローチを強化した好例なので紹介します！
Bug Bash は Quality Engineer が計画を立てて、エンジニアのみならずデザイナーやソリューションオーナー(*2)含む全チームメンバーで実施しました。3つのチームに分かれ、2時間のセッション内で探索的に各機能をテストしていきました。各チームはそれぞれビデオ会議を繋いでワイワイとテストを実施し、機能バグやユーザビリティ観点で気になる点など大小さまざまなチケットを miro にリアルタイムで起票していきました。
https://note.com/haruka_slalom/n/n9c23fe8746c0
特定されたバグは、Bug Bash実施後にプロダクトオーナーと相談して優先順位付けし、リリース前に修正が必要と判断されたクリティカルなものは、実際のリリースまでに全て修正されました。これらの一連の活動は、Quality Engineerがドライブし、チームとしてコラボレーションしながら実行することにより、チーム全体で品質に向き合う姿勢がより強化されました。
Bug Bashに対するチームのフィードバックも好評でした！
初めてバグを見つけるのが楽しいと思えた！（ソフトウェアエンジニア）
バグバッシュを初めてして、とてもよかった。他のプロジェクトでもしたい（ソフトウェアエンジニア）
社内に共有して他のプロジェクトでもやってみたい！（プロダクトオーナー）
まとめ
今回の記事を通して、品質の高いソフトウェアをデリバリーするためには「良いスクラムチーム」が必要で、Quality Engineerがいかに貢献できるか、ということをお伝えしてきました。SlalomにおけるQuality Engineering についてもっと詳しく知りたい方は以下の記事を読んでみてください。
今すぐにQuality Engineerを採用することが難しいチームも多いと思います。そういった場合、まずは振り返りから始めてみてはいかがでしょうか。
良い振り返りを行う努力をすることで、「アジャイルマインドセット」や「チーム全体アプローチ」のカルチャーが自然にチームにインストールされ、良いスクラムチームに近づいていくことができます。それにより自分達で品質活動を推進しやすくなる土壌ができますし、Quality Engineerの採用に成功した場合でも品質活動の取り組みがよりパワフルでスピーディなものになるでしょう。
振り返りを通して良いスクラムチームにしていきたい方はぜひ下記の書籍も読んでみてください。
記事の内容についてコメントや質問がある方は是非コメント欄にてコメントお願いします！また記事の内容や、Quality Engineeringについてディスカッションしたい方も工藤までお気軽にご連絡ください！
この記事が気に入ったらサポートをしてみませんか？